Hacker's paradise

Best ways to Deny Computer Hackers ! 3 Effective Methods !

noreply@blogger.com (aashu) — Thu, 20 Nov 2008 13:34:00 +0000

Hello Folks, After long time, Got some time so I decided to write a new paper. Today I’m going to write about how to deny access to the most 3 important elements of data in a computer to a hacker. these three methods use free/commercial applications. its highly effective and focuses on a defensive strategy than a proactive strategy.

1.Denying access to files to an hacker

As we all know its very easy to get yourself infected with a trojan. Once a hacker gains access to your system he can basically go through all your drives & files and will have the ability to modify/delete data. in order to protect your files you can use a application called ‘Folder Lock’ its an revolutionary application that can deny access to the files you locked to any of the trojan available to the hackers. I have tested with the most widely used and popular Trojans such as Poison Ivy, Bifrost, Bandook, Nuclear RAT, Pain RAT, Shark, etc.. I infected my computer with a Trojan and tested it out. here is the results

Creat an unbreakable password?

noreply@blogger.com (aashu) — Thu, 20 Nov 2008 13:26:00 +0000

This tutorial will follow each way of hacking you password and eliminate it
1-Brute Force
solution:
use a random password generator with a combination of letters and Numbers and symbols if available with a min length of 8 Char can generate this password on:
http://www.goodpassword.com
Note: Avoid writing this password on a paper or storing it on the pc
2-Key Loggers:
solution:
first of all give no access to someone that could install a key logger
second check your computer ruing tasks and services each time you login your computer for any suspected keyloger names (this method may not be very effective)
third scan your computer for key loggers using Spy Bot you can download it from:
http://www.safer-networking.org/en/spybotsd/index.html
3-Password Recovery:
most people store their face book msn gmail ...... passwords on their computer saving time typing them every time you login well thats the easiest way of reaching your password so stop being lazy and memorize your password and type them in also make sure to keep an antivirus like Avira always on the run so if you antecedently left a password and someone tries to recover it you can download Avira From:
http://www.avira.com/
AND MOST IMPORTANT
4-ONE PASSWORD RULES THEM ALL:
LOL never set one password from all your accounts on the internet i know its hard to memorize a lot of passwords but it makes it easier to recover your hacked passwords for example if your facebook password is hacked you can recover it by using your email but if they are both the same password you lost your facebook and email

wish you all good luck and i hope i helped on something

Basic HTML Tags

noreply@blogger.com (aashu) — Tue, 18 Nov 2008 08:43:00 +0000

--------------------------------------------------------------------------------

The most important tags in HTML are tags that define headings, paragraphs and line breaks.

The best way to learn HTML is to work with examples. We have created a very nice HTML editor for you. With this editor, you can edit the HTML source code if you like, and click on a test button to view the result.

--------------------------------------------------------------------------------

Headings
Headings are defined with the < h1 > to < h6 > tags. < h1 > defines the largest heading. < h6 > defines the smallest heading.

< h1 >This is a heading< /h1 >
< h2 >This is a heading< /h2 >
< h3 >This is a heading< /h3 >
< h4 >This is a heading< /h4 >
< h5 >This is a heading< /h5 >
< h6 >This is a heading< /h6 >

HTML automatically adds an extra blank line before and after a heading.

Paragraphs
Paragraphs are defined with the

tag.

< p >This is a paragraph< /p >
< p >This is another paragraph< /p >

HTML automatically adds an extra blank line before and after a paragraph.

Don't Forget the Closing Tag
You might have noticed that paragraphs can be written without end tags < /p >:

< p >This is a paragraph
< p >This is another paragraph

The example above will work in most browsers, but don't rely on it. Future version of HTML will not allow you to skip ANY end tags.

Closing all HTML elements with an end tag is a future-proof way of writing HTML. It also makes the code easier to understand (read and browse) when you mark both where an element starts and where it ends.

Line Breaks
The < br > tag is used when you want to break a line, but don't want to start a new paragraph. The < br > tag forces a line break wherever you place it.

< p >This < br > is a para< br >graph with line breaks< /p >

The < br > tag is an empty tag. It has no end tag like < /br >, since a closing tag doesn't make any sense.

--------------------------------------------------------------------------------

< br > or < br />
More and more often you will see the
tag written like this:

Because the < br > tag has no end tag (or closing tag), it breaks one of the rules for future HTML (the XML based XHTML), namely that all elements must be closed.

Writing it like < br / > is a future proof way of closing (or ending) the tag inside the opening tag, accepted by both HTML and XML.

Comments in HTML
The comment tag is used to insert a comment in the HTML source code. A comment will be ignored by the browser. You can use comments to explain your code, which can help you when you edit the source code at a later date.

< !-- This is a comment -- >

Note that you need an exclamation point after the opening bracket, but not before the closing bracket.

--------------------------------------------------------------------------------

Recap on HTML Elements
Each HTML element has an element name (body, h1, p, br)
The start tag is the name surrounded by angle brackets:

The end tag is a slash and the name surrounded by angle brackets

The element content occurs between the start tag and the end tag
Some HTML elements have no content
Some HTML elements have no end tag

--------------------------------------------------------------------------------

Basic Notes - Useful Tips
When you write HTML text, you can never be sure how the text is displayed in another browser. Some people have large computer displays, some have small. The text will be reformatted every time the user resizes his window. Never try to format the text in your editor by adding empty lines and spaces to the text.

HTML will truncate the spaces in your text. Any number of spaces count as one. Some extra information: In HTML a new line counts as one space.

Using empty paragraphs < p > to insert blank lines is a bad habit. Use the < br > tag instead. (But don't use the < br > tag to create lists. Wait until you have learned about HTML lists.)

HTML automatically adds an extra blank line before and after some elements, like before and after a paragraph, and before and after a heading.

We use a horizontal rule (the < hr > tag), to separate the sections in our tutorials.

--------------------------------------------------------------------------------

Basic HTML Tags
If you lookup the basic HTML tags in the reference below, you will see that the reference contains additional information about tag attributes.

You will learn more about HTML tag attributes in the next chapter of this tutorial.

Tag Description
< html > Defines an HTML document
< body > Defines the document's body
< h1 > to < h6 > Defines header 1 to header 6
< p > Defines a paragraph
< br > Inserts a single line break
< hr > Defines a horizontal rule
< !-- > Defines a comment

--------------------------------------------------------------------------------

HTML Elements

noreply@blogger.com (aashu) — Tue, 18 Nov 2008 08:34:00 +0000

--------------------------------------------------------------------------------

HTML documents are text files made up of HTML elements.

HTML elements are defined using HTML tags.
--------------------------------------------------------------------------------

HTML Tags
HTML tags are used to mark-up HTML elements
HTML tags are surrounded by the two characters < and > The surrounding characters are called angle brackets
HTML tags normally come in pairs like and
The first tag in a pair is the start tag, the second tag is the < strong >end tag < /strong >The text between the start and end tags is the element content HTML tags are not case sensitive, < b > means the same as < B >

--------------------------------------------------------------------------------

HTML Elements
Remember the HTML example from the previous page:

< html >
< head >
< title >Title of page< /title >
< /head >
< body >
This is my first homepage. < b >This text is bold< /b >
< /body >
< /html >

This is an HTML element:

< b >This text is bold< /b >

The HTML element starts with a start tag: < b >
The content of the HTML element is: This text is bold
The HTML element ends with an end tag: < /b >

The purpose of the < b > tag is to define an HTML element that should be displayed as bold.

This is also an HTML element:

< body >
This is my first homepage. < b >This text is bold< /b >
< /body >

This HTML element starts with the start tag < body >, and ends with the end tag < /body >.

The purpose of the < body > tag is to define the HTML element that contains the body of the HTML document.

--------------------------------------------------------------------------------

Why do We Use Lowercase Tags?
We have just said that HTML tags are not case sensitive: < B > means the same as < b >. If you surf the Web, you will notice that plenty of web sites use uppercase HTML tags in their source code. We always use lowercase tags. Why?

If you want to follow the latest web standards, you should always use lowercase tags. The World Wide Web Consortium (W3C) recommends lowercase tags in their HTML 4 recommendation, and XHTML (the next generation HTML) demands lowercase tags.

--------------------------------------------------------------------------------

Introduction to HTML

noreply@blogger.com (aashu) — Tue, 18 Nov 2008 08:26:00 +0000

--------------------------------------------------------------------------------

What is an HTML File?
HTML stands for Hyper Text Markup Language
An HTML file is a text file containing small markup tags
The markup tags tell the Web browser how to display the page
An HTML file must have an htm or html file extension
An HTML file can be created using a simple text editor

--------------------------------------------------------------------------------

Do You Want to Try It?
If you are running Windows, start Notepad.

If you are on a Mac, start SimpleText.

In OSX start TextEdit and change the following preferences: Open the "Format" menu and select "Plain text" instead of "Rich text". Then open the "Preferences" window under the "Text Edit" menu and select "Ignore rich text commands in HTML files". Your HTML code will probably not work if you do not change the preferences above!

Type in the following text:

< html >
< head >
< title >Title of page< /title >
< /head >
< body >
This is my first homepage. This text is bold
< /body >
< /html >

Save the file as "mypage.htm".

Start your Internet browser. Select "Open" (or "Open Page") in the File menu of your browser. A dialog box will appear. Select "Browse" (or "Choose File") and locate the HTML file you just created - "mypage.htm" - select it and click "Open". Now you should see an address in the dialog box, for example "C:\MyDocuments\mypage.htm". Click OK, and the browser will display the page.

--------------------------------------------------------------------------------

Example Explained
The first tag in your HTML document is < html >. This tag tells your browser that this is the start of an HTML document. The last tag in your document is < /html >. This tag tells your browser that this is the end of the HTML document.

The text between the < head > tag and the < /head > tag is header information. Header information is not displayed in the browser window.

The text between the < title > tags is the title of your document. The title is displayed in your browser's caption.

The text between the < body > tags is the text that will be displayed in your browser.

The text between the < b > and < /b > tags will be displayed in a bold font.

--------------------------------------------------------------------------------

HTM or HTML Extension?
When you save an HTML file, you can use either the .htm or the .html extension. We have used .htm in our examples. It might be a bad habit inherited from the past when some of the commonly used software only allowed three letter extensions.

With newer software we think it will be perfectly safe to use .html.

--------------------------------------------------------------------------------

Note on HTML Editors:
You can easily edit HTML files using a WYSIWYG (what you see is what you get) editor like FrontPage or Dreamweaver, instead of writing your markup tags in a plain text file.

However, if you want to be a skillful Web developer, we strongly recommend that you use a plain text editor to learn your primer HTML.

--------------------------------------------------------------------------------

Frequently Asked Questions
Q: After I have edited an HTML file, I cannot view the result in my browser. Why?
A: Make sure that you have saved the file with a proper name and extension like "c:\mypage.htm". Also make sure that you use the same name when you open the file in your browser.

Q: I have edited an HTML file, but the changes don't show in the browser. Why?A: A browser caches pages so it doesn't have to read the same page twice. When you have modified a page, the browser doesn't know that. Use the browser's refresh/reload button to force the browser to reload the page.

Q: What browser should I use?A: You can do all the training with all of the well-known browsers, like Internet Explorer, Firefox, Netscape, or Opera. However, some of the examples in our advanced classes require the latest versions of the browsers.

Q: Does my computer have to run Windows? What about a Mac?A: You can do all your training on a non-Windows computer like a Mac.

--------------------------------------------------------------------------------

Best Tips for choosing strong passwords

noreply@blogger.com (aashu) — Tue, 18 Nov 2008 07:59:00 +0000

Password cracking software uses one of three approaches: intelligent guessing, dictionary attacks, and automation that tries every possible combination of characters. Given enough time, the automated method can crack any password.

However, even when password cracking tools continue to improve, it still can take months to crack a strong password. Here is one of the best tip on creating strong secure passwords:

Instead of using the same password for everything you access, choose a root password, then take the name of the service or application you’re accessing, replace a few letters with numbers (or jumble it up), and append it to the end of your root password.
OfZenAndComputing.com has some more strong password tips:1. Do not use names, nor words found in the dictionary.

2. Your password’s length should be at least 8 characters long.

3. Select an alphanumeric password, meaning that it contains both letters and numbers. Try appending a random number to the end of the password, or replacing one or two letters with numbers.

Source: Create a strong, secure password | Passwords: The weakest link

BLUETOOTH TECHNOLOGY

noreply@blogger.com (aashu) — Mon, 17 Nov 2008 08:36:00 +0000

"BLUETOOTH represents a single chip, low cost, low power radio based network technology for Wireless Personal Area Networks (WPAN)"
>
Bluetooth wireless technology is a short-range communications system intended to replace the cables connecting portable and/or fixed electronic devices. It provides Wireless interconnections between low power, short range, small mobile devices (Palmtops, Laptops, PDAs, phones, etc) in close proximity (within a room, car, cabin, elevator…) Bluetooth technology
Provides freedom from wires
Supports creation of Adhoc piconets and Personal Area Networks(PAN) with limited coverage (within the range of 10 ms)
Doesnot require Infrastructure support like Switches, Access Points, hubs, routers, etc. for establishing interconnectivity
Connects Keyboard, mouse, printers, headphones, head sets with speakers etc. to PC without wires.
To Interconnects hand held, portable, battery operated devices like mobile phones, hands free equipment with mobile phones, PDAs, mobile computers, communicators,, microphones, wireless speakers to home theatre systems
The Bluetooth core system consists of an RF transceiver and follows IEEE 802.15 standards. The system offers services that enable the connection of mobile devices and exchange of a variety of data (voice, music, graphics, text) between these devices.
Bluetooth consortium was formed by 5 companies in 1998 i.e. Ericsson, Intel, IBM, Nokia and Toshiba. Blue-tooth standard is adopted by over 1000 manufacturers of electronics appliances (Akai, Motorola, LG, Samsung, Nokia, for music, video, data, fax m/c ……)

Features of Bluetooth
1. Power consumption is very low due to battery operated devices.
2. Freq. Band (2400-2483.5 MHz) 83.5MHz. B.W.
3. Fast Freq. Hopping TDD scheme at a rate of 1600 hops/sec.
4. Within a Pico net all devices use the same hopping sequence
5. Transmitter Power upto 100mW.
6. Range 10m-100m with special transceivers.

The Bluetooth RF (physical layer) operates in the unlicensed ISM band at 2.4GHz. The datarate is 1 Megabits per second (Mbps). A group of devices interconnected using RF link form a piconet. Devices in a piconet use a specific frequency hopping pattern which is algorithmically determined by certain fields in the Bluetooth specification address and clock of the master.

Security Issues

Today's wireless world means that data is being sent, among us, invisibly from device to device, country to country, person to person. This data, in the form of e-mails, photos, contacts and addresses are precious and private to each of us. This private information, no longer making its way along wires in plain sight, needs to be sent securely to its intended recipient without interception. Wireless standards the world over are evolving and have various formats for dealing with the security issues of its users. Bluetooth wireless technology is no exception.

Bluetooth wireless technology has, from its inception, put great emphasis on wireless security so that users of this global standard can feel secure while making their connections. The Bluetooth Special Interest Group (SIG), has a Bluetooth security experts group made up of engineers from its member companies who provide critical security information and feedback that is taken into account as the Bluetooth wireless specification evolves.

Product developers that use Bluetooth wireless technology in their products have several options for implementing security. There are three modes of security for Bluetooth access between two devices.

Security Mode 1: non-secure
Security Mode 2: service level enforced security
Security Mode 3: link level enforced security

The manufacturer of each product determines these security modes. Devices and services also have different security levels. Three security levels are defined:
services that require authorization and authentication (mode 3)
services that require authentication only and (mode 2)
services that are open to all devices. (mode 1)

Lately, confusion and misinformation surrounding security and Bluetooth wireless technology has increased. The current security issues typically involve mobile phones. The encryption algorithm in the Bluetooth specifications is secure.

Cases where data has been compromised on mobile phones are the result of implementation issues on that platform. The recently reported issues of advanced "hackers" gaining access to information stored on select mobile phones using Bluetooth functionality are due to incorrect implementation. The names bluesnarfing, bluejacking and bluebugging have been given to these methods of illegal and improper access to information. The following sections provide users with more information about these current issues and will address their concerns for dealing with these security risks.

What is bluejacking?

Bluejacking allows phone users to send business cards anonymously using Bluetooth wireless technology. Bluejacking does NOT involve the removal or alteration of any data from the device. These business cards often have a clever or flirtatious message rather than the typical name and phone number. Bluejackers often look for the receiving phone to ping or the user to react. They then send another, more personal message to that device. Once again, in order to carry out a bluejacking, the sending and receiving devices must be within 10 meters of one another. Phone owners who receive bluejack messages should refuse to add the contacts to their address book. Devices that are set in non-discoverable mode are not susceptible to bluejacking.

What is bluebugging?

Bluebugging allows skilled individuals to access the mobile phone commands using Bluetooth wireless technology without notifying or alerting the phone's user. This vulnerability allows the hacker to initiate phone calls, send and receive text messages, read and write phonebook contacts, eavesdrop on phone conversations, and connect to the Internet. As with all the attacks, without specialized equipment, the hacker must be within a 10 meter range of the phone.

What is bluesnarfing?

Bluesnarfing allows hackers to gain access to data stored on a Bluetooth enabled phone using Bluetooth wireless technology without alerting the phone's user of the connection made to the device. The information that can be accessed in this manner includes the phonebook and associated images, calendar, and IMEI (international mobile equipment identity). By setting the device in non-discoverable, it becomes significantly more difficult to find and attack the device. Without specialized equipment the hacker must be within a 10 meter range of the device while running a device with specialized software. Only specific older Bluetooth enabled phones are susceptible to bluesnarfing.

Keeping an Open Mind

noreply@blogger.com (aashu) — Sun, 16 Nov 2008 14:49:00 +0000

A lightly edited version of this essay appeared in the March/April 1999 "Cyberian Express", a publication of Barnes & Noble booksellers. Translations into: Dutch, Hungarian, and Japanese are available.

The advent of the Internet is driving some drastic changes in the software industry. We usually think of dramatically lower communications and transaction costs as the Internet's major value (and challenge!). That's the noisy, well-hyped part of the Internet revolution.

But there's something else going on, as well. The Internet's engineering tradition, its native culture, and even its folklore are turning out to hold lessons that are going to be critical for the creativity-and software-intensive economy of the coming century.

The shot heard 'round the world in this quieter revolution was the source release of Netscape's `Mozilla' browser at midnight of April Fool's Day, 1998. This brought to widespread press and public attention a face-off between two dramatically different and fundamentally opposed styles of software development — a confrontation that had been building for thirty years, but became inevitable after the the advent of the World Wide Web and the popular Internet explosion of 1993-94.

One of these styles is what we've now learned to call `closed source' — the traditional factory-production model of proprietary software, in which the customer gets a sealed block of bits which cannot be examined, modified, or evolved. The standard-bearer of this approach is Microsoft.

The other is `open source', the Internet engineering tradition, in which source code is generally available for inspection, independent peer review and rapid evolution. The standard-bearer of this approach is the Linux operating system.

The now-notorious Halloween Documents ratified in Microsoft's own words what has become increasingly clear in the last nine months — that the open-source model is well on its way to obsolescing the closed-source one. But to understand why, and to think clearly about what this means for the future, we need to step back from the particularities of Microsoft and Linux and consider some qualitative, general issues about three things: reliability, total cost of ownership, and software risks.

Historically, the way we get high reliability of results in engineering and the sciences is by institutionalizing peer review. Physicists don't hide their experimental plans from each other; instead, they skeptically check each others' work. Engineers don't build dams or suspension bridges without having the blueprints vetted first by other engineers independent of the original design group.

In the software industry, our reliability has historically been terrible. Crashes, hangs, and lost data are still commonplace. Also, we don't as a rule do peer review. You might think these facts are unconnected, until you look at the infrastructure of the Internet. All of the Internet's core software is open-source — and its reliability is extremely good. This is an even stronger demonstration because the Internet is multi-platform, heterogenous, international, and has remained essentially backward-compatible through thirty years and several generations of technology.

The pattern is simple and compelling. Where we have open-source software, we have peer review and high reliability. Where we don't, reliability suffers terribly. This fact in itself is probably sufficient to marginalize closed-source development in the future.

Total cost of ownership is also drastically affected by open source. In a closed-source world, the software producer can charge for the bits and has an effective monopoly lock on service. Accordingly, major closed-source packages cost thousands of dollars up front and thousands of dollars a year in continuing service and upgrade costs.

In the open-source world, the bits are free and the provider doesn't have a lock on your service and upgrade business. Accordingly, both up-front and annual service/support costs are low. Quite shockingly and threateningly low, by Microsoft's standards.

The indirect effect of open-source on total cost of ownership is even stronger. Cash-strapped educational institutions love inexpensive software; they love open-source software especially, because it lets students examine and experiment in ways extremely valuable for learning. Universities and technical schools are now beginning to turn out an increasing flood of Linux-aware graduates, each one far more knowledgeable about the operating system than any MCSE can possibly be about closed-source Windows. The potential impact of this on personnel and training costs should not be hard to imagine.

But the most important long-term effect of open source will be on software risks. To see why, we need to focus again on the supplier-monopoly aspect of closed source. Let's say you're a CTO at a Fortune 500 company and you've just spent millions of dollars on strategic business system with software you can't see inside, can't modify, and depend on a single vendor to service.

Now...are those systems going to change to serve your business plan — or your vendor's business plan?

When being locked into an unhealthy dependency on your vendor was the only alternative anybody could see, it was hard to evaluate closed source as a risk. But open-source software puts the software consumer back in control of his destiny. It creates a buyer's market for enhancements, service, and support; it allows a mix of options including in-house development or contracting to any one of multiple competing service groups.

To be concrete: if your OS is Windows, Microsoft is the only choice you have — you're locked in, trapped. If it's Linux, Red Hat has to do its service job well or watch its business go to Caldera or S.u.S.E. And if Red Hat and Caldera and S.u.S.E fail, ten thousand Internet developers will cheerfully launch new distributions using the same free, common, exhaustively debugged code base.

We've seen that open source puts the software customer in the driver's seat, dramatically lowers total cost of ownership, and is the only recipe that works for high reliability. For these good reasons, it probably won't be long before buying closed-source software for any system that must be truly reliable is considered outright irresponsible.

Yes, after the quiet revolution you could be fired for buying Microsoft — and, if you keep it up, maybe you should be.

A Brief History of Hackerdom

noreply@blogger.com (aashu) — Sun, 16 Nov 2008 14:44:00 +0000

Prologue: The Real Programmers
In the beginning, there were Real Programmers.

That's not what they called themselves. They didn't call themselves `hackers', either, or anything in particular; the sobriquet `Real Programmer' wasn't coined until after 1980, retrospectively by one of their own. But from 1945 onward, the technology of computing attracted many of the world's brightest and most creative minds. From Eckert and Mauchly's first ENIAC computer onward there was a more or less continuous and self-conscious technical culture of enthusiast programmers, people who built and played with software for fun.

The Real Programmers typically came out of engineering or physics backgrounds. They were often amateur-radio hobbyists. They wore white socks and polyester shirts and ties and thick glasses and coded in machine language and assembler and FORTRAN and half a dozen ancient languages now forgotten.

From the end of World War II to the early 1970s, in the great days of batch processing and the ``big iron'' mainframes, the Real Programmers were the dominant technical culture in computing. A few pieces of revered hacker folklore date from this era, including various lists of Murphy's Laws and the mock-German ``Blinkenlights'' poster that still graces many computer rooms.

Some people who grew up in the `Real Programmer' culture remained active into the 1990s and even past the turn of the 21st century. Seymour Cray, designer of the Cray line of supercomputers, was among the greatest. He is said once to have toggled an entire operating system of his own design into a computer of his own design through its front-panel switches. In octal. Without an error. And it worked. Real Programmer macho supremo.

The `Real Programmer' culture, though, was heavily associated with batch (and especially batch scientific) computing. It was eventually eclipsed by the rise of interactive computing, the universities, and the networks. These gave birth to another engineering tradition that, eventually, would evolve into today's open-source hacker culture.

The Early Hackers
The beginnings of the hacker culture as we know it today can be conveniently dated to 1961, the year MIT acquired the first PDP-1. The Signals and Power Committee of MIT's Tech Model Railroad Club adopted the machine as their favorite tech-toy and invented programming tools, slang, and an entire surrounding culture that is still recognizably with us today. These early years have been examined in the first part of Steven Levy's book Hackers [Levy].

MIT's computer culture seems to have been the first to adopt the term `hacker'. The Tech Model Railroad Club's hackers became the nucleus of MIT's Artificial Intelligence Laboratory, the world's leading center of AI research into the early 1980s. Their influence was spread far wider after 1969, the first year of the ARPAnet.

The ARPAnet was the first transcontinental, high-speed computer network. It was built by the Defense Department as an experiment in digital communications, but grew to link together hundreds of universities and defense contractors and research laboratories. It enabled researchers everywhere to exchange information with unprecedented speed and flexibility, giving a huge boost to collaborative work and tremendously increasing both the pace and intensity of technological advance.

But the ARPAnet did something else as well. Its electronic highways brought together hackers all over the U.S. in a critical mass; instead of remaining in isolated small groups each developing their own ephemeral local cultures, they discovered (or re-invented) themselves as a networked tribe.

The first intentional artifacts of the hacker culture—the first slang lists, the first satires, the first self-conscious discussions of the hacker ethic—all propagated on the ARPAnet in its early years. In particular, the first version of the Jargon File developed as a cross-net collaboration during 1973–1975. This slang dictionary became one of the culture's defining documents. It was eventually published as "The Hacker's Dictionary" in 1983; that first version is out of print, but a revised and expanded version is New Hacker's Dictionary [Raymond].

Hackerdom flowered at the universities connected to the net, especially (though not exclusively) in their computer science departments. MIT's AI and LCS labs made it first among equals from the late 1960s. But Stanford University's Artificial Intelligence Laboratory (SAIL) and Carnegie-Mellon University (CMU) became nearly as important. All were thriving centers of computer science and AI research. All attracted bright people who contributed great things to the hacker culture, on both the technical and folkloric levels.

To understand what came later, though, we need to take another look at the computers themselves; because the AI Lab's rise and its eventual fall were both driven by waves of change in computing technology.

Since the days of the PDP-1, hackerdom's fortunes had been woven together with Digital Equipment Corporation's PDP series of minicomputers. DEC pioneered commercial interactive computing and time-sharing operating systems. Because their machines were flexible, powerful, and relatively cheap for the era, lots of universities bought them.

Cheap time-sharing was the medium the hacker culture grew in, and for most of its lifespan the ARPAnet was primarily a network of DEC machines. The most important of these was the PDP-10, first released in 1967. The 10 remained hackerdom's favorite machine for almost fifteen years; TOPS-10 (DEC's operating system for the machine) and MACRO-10 (its assembler) are still remembered with nostalgic fondness in a great deal of slang and folklore.

MIT, though it used the same PDP-10s as everyone else, took a slightly different path; they rejected DEC's software for the PDP-10 entirely and built their own operating system, the fabled ITS.

ITS stood for `Incompatible Time-sharing System' which gives one a pretty good fix on the MIT hackers' attitude (technically, the name was a play on its predecessor, the Compatible Time-Sharing System CTSS). They wanted it their way. Fortunately for all, MIT's people had the intelligence to match their arrogance. ITS, quirky and eccentric and occasionally buggy though it always was, hosted a brilliant series of technical innovations and still arguably holds the record as the single time-sharing system in longest continuous use.

ITS itself was written in assembler, but many ITS projects were written in the AI language LISP. LISP was far more powerful and flexible than any other language of its day; in fact, it is still a better design than most languages of today, twenty-five years later. LISP freed ITS's hackers to think in unusual and creative ways. It was a major factor in their successes, and remains one of hackerdom's favorite languages.

Many of the ITS culture's technical creations are still alive today; the EMACS program editor is perhaps the best-known. And much of ITS's folklore is still `live' to hackers, as one can see in the Jargon File.

SAIL and CMU weren't asleep, either. Many of the cadre of hackers that grew up around SAIL's PDP-10 later became key figures in the development of the personal computer and today's window/icon/mouse software interfaces. Meanwhile hackers at CMU were doing the work that would lead to the first practical large-scale applications of expert systems and industrial robotics.

Another important node of the culture was XEROX PARC, the famed Palo Alto Research Center. For more than a decade, from the early 1970s into the mid-1980s, PARC yielded an astonishing volume of groundbreaking hardware and software innovations. The modern mice, windows, and icons style of software interface was invented there. So was the laser printer, and the local-area network; and PARC's series of D machines anticipated the powerful personal computers of the 1980s by a decade. Sadly, these prophets were without honor in their own company; so much so that it became a standard joke to describe PARC as a place characterized by developing brilliant ideas for everyone else. Their influence on hackerdom was pervasive.

The ARPAnet and the PDP-10 cultures grew in strength and variety throughout the 1970s. The facilities for electronic mailing lists that had been used to foster cooperation among continent-wide special-interest groups were increasingly also used for more social and recreational purposes. DARPA deliberately turned a blind eye to all the technically `unauthorized' activity; it understood that the extra overhead was a small price to pay for attracting an entire generation of bright young people into the computing field.

Perhaps the best-known of the `social' ARPAnet mailing lists was the SF-LOVERS list for science-fiction fans; it is still very much alive today, in fact, on the larger `Internet' that ARPAnet evolved into. But there were many others, pioneering a style of communication that would later be commercialized by for-profit time-sharing services like CompuServe, GEnie and Prodigy (and later still dominated by AOL).

Your historian first became involved with the hacker culture in 1977 through the early ARPAnet and science-fiction fandom. From then onward, I personally witnessed and participated in many of the changes described here.

The Rise of Unix
Far from the bright lights of the ARPAnet, off in the wilds of New Jersey, something else had been going on since 1969 that would eventually overshadow the PDP-10 tradition. The year of ARPAnet's birth was also the year that a Bell Labs hacker named Ken Thompson invented Unix.

Thompson had been involved with the development work on a time-sharing OS called Multics, which shared common ancestry with ITS. Multics was a test-bed for some important ideas about how the complexity of an operating system could be hidden inside it, invisible to the user, and even to most programmers. The idea was to make using Multics from the outside (and programming for it!) much simpler, so that more real work could get done.

Bell Labs pulled out of the project when Multics displayed signs of bloating into an unusable white elephant (the system was later marketed commercially by Honeywell but never became a success). Ken Thompson missed the Multics environment, and began to play at implementing a mixture of its ideas and some of his own on a scavenged DEC PDP-7.

Another hacker named Dennis Ritchie invented a new language called `C' for use under Thompson's embryonic Unix. Like Unix, C was designed to be pleasant, unconstraining, and flexible. Interest in these tools spread at Bell Labs, and they got a boost in 1971 when Thompson and Ritchie won a bid to produce what we'd now call an office automation system for internal use there. But Thompson & Ritchie had their eye on a bigger prize.

Traditionally, operating systems had been written in tight assembler to extract the absolute highest efficiency possible out of their host machines. Thompson and Ritchie were among the first to realize that hardware and compiler technology had become good enough that an entire operating system could be written in C, and by 1978 the whole environment had been successfully ported to several machines of different types.

This had never been done before, and the implications were enormous. If Unix could present the same face, the same capabilities, on machines of many different types, it could serve as a common software environment for all of them. No longer would users have to pay for complete new designs of software every time a machine went obsolete. Hackers could carry around software toolkits between different machines, rather than having to re-invent the equivalents of fire and the wheel every time.

Besides portability, Unix and C had some other important strengths. Both were constructed from a ``Keep It Simple, Stupid'' philosophy. A programmer could easily hold the entire logical structure of C in his head (unlike most other languages before or since) rather than needing to refer constantly to manuals; and Unix was structured as a flexible toolkit of simple programs designed to combine with each other in useful ways.

The combination proved to be adaptable to a very wide range of computing tasks, including many completely unanticipated by the designers. It spread very rapidly within AT&T, in spite of the lack of any formal support program for it. By 1980 it had spread to a large number of university and research computing sites, and thousands of hackers considered it home.

The workhorse machines of the early Unix culture were the PDP-11 and its descendant, the VAX. But because of Unix's portability, it ran essentially unaltered on a wider range of machines than one could find on the entire ARPAnet. And nobody used assembler; C programs were readily portable among all these machines.

Unix even had its own networking, of sorts—UUCP: low-speed and unreliable, but cheap. Any two Unix machines could exchange point-to-point electronic mail over ordinary phone lines; this capability was built into the system, not an optional extra. In 1980 the first Usenet sites began exchanging broadcast news, forming a gigantic distributed bulletin board that would quickly grow bigger than ARPAnet. Unix sites began to form a network nation of their own around Usenet.

A few Unix sites were on the ARPAnet themselves. The PDP-10 and Unix/Usenet cultures began to meet and mingle at the edges, but they didn't mix very well at first. The PDP-10 hackers tended to consider the Unix crowd a bunch of upstarts, using tools that looked ridiculously primitive when set against the baroque, lovely complexities of LISP and ITS. ``Stone knives and bearskins!'' they muttered.

And there was yet a third current flowing. The first personal computer had been marketed in 1975; Apple was founded in 1977, and advances came with almost unbelievable rapidity in the years that followed. The potential of microcomputers was clear, and attracted yet another generation of bright young hackers. Their language was BASIC, so primitive that PDP-10 partisans and Unix aficionados both considered it beneath contempt.

The End of Elder Days
So matters stood in 1980; three cultures, overlapping at the edges but clustered around very different technologies. The ARPAnet/PDP-10 culture, wedded to LISP and MACRO and TOPS-10 and ITS and SAIL. The Unix and C crowd with their PDP-11s and VAXen and pokey telephone connections. And an anarchic horde of early microcomputer enthusiasts bent on taking computer power to the people.

Among these, the ITS culture could still claim pride of place. But stormclouds were gathering over the Lab. The PDP-10 technology ITS depended on was aging, and the Lab itself was split into factions by the first attempts to commercialize artificial intelligence. Some of the Lab's (and SAIL's and CMU's) best were lured away to high-paying jobs at startup companies.

The death blow came in 1983, when DEC cancelled its `Jupiter' followon to the PDP-10 in order to concentrate on the PDP-11 and VAX lines. ITS no longer had a future. Because it wasn't portable, it was more effort than anyone could afford to move ITS to new hardware. The Berkeley variant of Unix running on a VAX became the hacking system par excellence, and anyone with an eye on the future could see that microcomputers were growing in power so rapidly that they were likely to sweep all before them.

It's around this time that Levy wrote Hackers. One of his prime informants was Richard M. Stallman (inventor of Emacs), a leading figure at the Lab and its most fanatical holdout against the commercialization of Lab technology.

Stallman (who is usually known by his initials and login name, RMS) went on to form the Free Software Foundation and dedicate himself to producing high-quality free software. Levy eulogized him as ``the last true hacker'', a description which happily proved incorrect.

Stallman's grandest scheme neatly epitomized the transition hackerdom underwent in the early eighties—in 1982 he began the construction of an entire clone of Unix, written in C and available for free. His project was known as the GNU (Gnu's Not Unix) operating system, in a kind of recursive acronym. GNU quickly became a major focus for hacker activity. Thus, the spirit and tradition of ITS was preserved as an important part of the newer, Unix and VAX-centered hacker culture. Stallman's design finished what Berkeley had started, fusing the remains of the PDP-10 hacker culture with the Unix crowd.

Indeed, for more than a decade after its founding RMS's Free Software Foundation would largely define the public ideology of the hacker culture, and Stallman himself would be the only credible claimant to leadership of the tribe.

It was also around 1982–83 that microchip and local-area network technology began to have a serious impact on hackerdom. Ethernet and the Motorola 68000 microchip made a potentially potent combination, and several different startups had been formed to build the first generation of what we now call workstations.

In 1982, a group of Unix hackers from Stanford and Berkeley founded Sun Microsystems on the belief that Unix running on relatively inexpensive 68000-based hardware would prove a winning combination for a wide variety of applications. They were right, and their vision set the pattern for an entire industry. While still priced out of reach of most individuals, workstations were cheap for corporations and universities; networks of them (one to a user) rapidly replaced the older VAXes and other time-sharing systems.

The Proprietary-Unix Era
By 1984, when Ma Bell divested and Unix became a supported AT&T product for the first time, the most important fault line in hackerdom was between a relatively cohesive ``network nation'' centered around the Internet and Usenet (and mostly using minicomputer- or workstation-class machines running Unix), and a vast disconnected hinterland of microcomputer enthusiasts.

It was also around this time that serious cracking episodes were first covered in the mainstream press—and journalists began to misapply the term ``hacker'' to refer to computer vandals, an abuse which sadly continues to this day.

The workstation-class machines built by Sun and others opened up new worlds for hackers. They were built to do high-performance graphics and pass around shared data over a network. During the 1980s hackerdom was preoccupied by the software and tool-building challenges of getting the most use out of these features. Berkeley Unix developed built-in support for the ARPAnet protocols, which offered a solution to the networking problems associated with UUCP's slow point-to-point links and encouraged further growth of the Internet.

There were several attempts to tame workstation graphics. The one that prevailed was the X window system, developed at MIT with contributions from hundreds of individuals at dozens of companies. A critical factor in its success was that the X developers were willing to give the sources away for free in accordance with the hacker ethic, and able to distribute them over the Internet. X's victory over proprietary graphics systems (including one offered by Sun itself) was an important harbinger of changes which, a few years later, would profoundly affect Unix as a whole.

There was a bit of factional spleen still vented occasionally in the ITS/Unix rivalry (mostly from the ex-ITSers' side). But the last ITS machine shut down for good in 1990; the zealots no longer had a place to stand and mostly assimilated to the Unix culture with various degrees of grumbling.

Within networked hackerdom itself, the big rivalry of the 1980s was between fans of Berkeley Unix and the AT&T versions. Occasionally you can still find copies of a poster from that period, showing a cartoony X-wing fighter out of the ``Star Wars'' movies streaking away from an exploding Death Star patterned on the AT&T logo. Berkeley hackers liked to see themselves as rebels against soulless corporate empires. AT&T Unix never caught up with BSD/Sun in the marketplace, but it won the standards wars. By 1990, AT&T and BSD versions were becoming harder to tell apart, having adopted many of each other's innovations.

After 1987, the workstation technology of the previous decade began to look distinctly threatened by newer, low-cost and high-performance personal computers based on the Intel 386 chip and its descendants. For the first time, individual hackers could afford to have home machines comparable in power and storage capacity to the minicomputers of ten years earlier—Unix engines capable of supporting a full development environment and talking to the Internet.

The MS-DOS world remained blissfully ignorant of all this. Though those early microcomputer enthusiasts quickly expanded to a population of DOS and Mac hackers orders an magnitude greater than that of the ``network nation'' culture, they never become a self-aware culture themselves. The pace of change was so fast that fifty different technical cultures grew and died as rapidly as mayflies, never achieving quite the stability necessary to develop a common tradition of jargon, folklore, and mythic history. The absence of a really pervasive network comparable to UUCP or Internet prevented them from becoming a network nation themselves.

Widespread access to commercial online services like CompuServe and GEnie was beginning to take hold, but the fact that non-Unix operating systems don't come bundled with development tools meant that very little source was passed over them. Thus, no tradition of collaborative hacking developed.

The mainstream of hackerdom, (dis)organized around the Internet and by now largely identified with the Unix technical culture, didn't care about the commercial services. These hackers wanted better tools and more Internet, and cheap 32-bit PCs promised to put both in everyone's reach.

But where was the software? Commercial Unixes remained expensive, in the multiple-kilobuck range. In the early 1990s several companies made a go at selling AT&T or BSD Unix ports for PC-class machines. Success was elusive, prices didn't come down much, and (worst of all) you didn't get modifiable and redistributable sources with your operating system. The traditional software-business model wasn't giving hackers what they wanted.

Neither was the Free Software Foundation. The development of HURD, RMS's long-promised free Unix kernel for hackers, got stalled for years and failed to produce anything like a usable kernel until 1996 (though by 1990 FSF supplied almost all the other difficult parts of a Unix-like operating system).

Worse, by the early 1990s it was becoming clear that ten years of effort to commercialize proprietary Unix was ending in failure. Unix's promise of cross-platform portability got lost in bickering among half a dozen proprietary Unix versions. The proprietary-Unix players proved so ponderous, so blind, and so inept at marketing that Microsoft was able to grab away a large part of their market with the shockingly inferior technology of its Windows operating system.

In early 1993, a hostile observer might have had grounds for thinking that the Unix story was almost played out, and with it the fortunes of the hacker tribe. And there was no shortage of hostile observers in the computer trade press, many of whom had been ritually predicting the imminent death of Unix at six-month intervals ever since the late 1970s.

In those days it was conventional wisdom that the era of individual techno-heroism was over, that the software industry and the nascent Internet would increasingly be dominated by colossi like Microsoft. The first generation of Unix hackers seemed to be getting old and tired (Berkeley's Computer Science Research group ran out of steam and would lose its funding in 1994). It was a depressing time.

Fortunately, there had been things going on out of sight of the trade press, and out of sight even of most hackers, that would produce startlingly positive developments in later 1993 and 1994. Eventually, these would take the hacker culture in a whole new direction and to undreamed-of successes.

The Early Free Unixes
Into the gap left by the Free Software Foundation's uncompleted HURD had stepped a Helsinki University student named Linus Torvalds. In 1991 he began developing a free Unix kernel for 386 machines using the Free Software Foundation's toolkit. His initial, rapid success attracted many Internet hackers to help him develop Linux, a full-featured Unix with entirely free and re-distributable sources.

Linux was not without competitors. In 1991, contemporaneously with Linus Torvalds's early experiments, William and Lynne Jolitz were experimentally porting the BSD Unix sources to the 386. Most observers comparing BSD technology with Linus's crude early efforts expected that BSD ports would become the most important free Unixes on the PC.

The most important feature of Linux, however, was not technical but sociological. Until the Linux development, everyone believed that any software as complex as an operating system had to be developed in a carefully coordinated way by a relatively small, tightly-knit group of people. This model was and still is typical of both commercial software and the great free-software cathedrals built by the Free Software Foundation in the 1980s; also of the freeBSD/netBSD/OpenBSD projects that spun off from the Jolitzes' original 386BSD port.

Linux evolved in a completely different way. From nearly the beginning, it was rather casually hacked on by huge numbers of volunteers coordinating only through the Internet. Quality was maintained not by rigid standards or autocracy but by the naively simple strategy of releasing every week and getting feedback from hundreds of users within days, creating a sort of rapid Darwinian selection on the mutations introduced by developers. To the amazement of almost everyone, this worked quite well.

By late 1993 Linux could compete on stability and reliability with many commercial Unixes, and hosted vastly more software. It was even beginning to attract ports of commercial applications software. One indirect effect of this development was to kill off most of the smaller proprietary Unix vendors—without developers and hackers to sell to, they folded. One of the few survivors, BSDI (Berkeley Systems Design, Incorporated), flourished by offering full sources with its BSD-based Unix and cultivating close ties with the hacker community.

These developments were not much remarked on at the time even within the hacker culture, and not at all outside it. The hacker culture, defying repeated predictions of its demise, was just beginning to remake the commercial-software world in its own image. It would be five more years, however, before this trend became obvious

The Great Web Explosion
The early growth of Linux synergized with another phenomenon: the public discovery of the Internet. The early 1990s also saw the beginnings of a flourishing Internet-provider industry, selling connectivity to the public for a few dollars a month. Following the invention of the World Wide Web, the Internet's already rapid growth accelerated to a breakneck pace.

By 1994, the year Berkeley's Unix development group formally shut down, several different free Unix versions (Linux and the descendants of 386BSD) served as the major focal points of hacking activity. Linux was being distributed commercially on CD-ROM and selling like hotcakes. By the end of 1995, major computer companies were beginning to take out glossy advertisements celebrating the Internet-friendliness of their software and hardware!

In the late 1990s the central activities of hackerdom became Linux development and the mainstreaming of the Internet. The World Wide Web has at last made the Internet into a mass medium, and many of the hackers of the 1980s and early 1990s launched Internet Service Providers selling or giving access to the masses.

The mainstreaming of the Internet even brought the hacker culture the beginnings of respectability and political clout. In 1994 and 1995 hacker activism scuppered the Clipper proposal which would have put strong encryption under government control. In 1996 hackers mobilized a broad coalition to defeat the misnamed ``Communications Decency Act'' and prevent censorship of the Internet.

With the CDA victory, we pass out of history into current events. We also pass into a period in which your historian (rather to his own surprise) became an actor rather than just an observer. This narrative will continue in Revenge of the Hackers.

Goodbye, "free software"; hello, "open source

noreply@blogger.com (aashu) — Sun, 16 Nov 2008 14:41:00 +0000

Goodbye, "free software"; hello, "open source"

This is the original call to the community to start using the term ‘open source‘ that I issued on 8 February 1998. The event referred to in the first paragraph is the 23 January announcement of the Mozilla source code release. Because this is a historic document, I haven't re-styled it to match the rest of my site. Though it has been converted to XHTML rather than HTML classic, except for this gray box and the RCS date at the bottom it looks pretty much exactly as it did then. There are Spanish and Indonesian translations of this document.

After the Netscape announcement broke in January I did a lot of thinking about the next phase -- the serious push to get "free software" accepted in the mainstream corporate world. And I realized we have a serious problem with "free software" itself.

Specifically, we have a problem with the term "free software", itself, not the concept. I've become convinced that the term has to go.

The problem with it is twofold. First, it's confusing; the term "free" is very ambiguous (something the Free Software Foundation's propaganda has to wrestle with constantly). Does "free" mean "no money charged?" or does it mean "free to be modified by anyone", or something else?

Second, the term makes a lot of corporate types nervous. While this does not intrinsically bother me in the least, we now have a pragmatic interest in converting these people rather than thumbing our noses at them. There's now a chance we can make serious gains in the mainstream business world without compromising our ideals and commitment to technical excellence -- so it's time to reposition. We need a new and better label.

I brainstormed this with some Silicon Valley fans of Linux (including Larry Augustin of the Linux International board of directors) the day after my meeting with Netscape (Feb 5th). We kicked around and discarded several alternatives, and we came up with a replacement label we all liked: "open source".

We suggest that everywhere we as a culture have previously talked about "free software", the label should be changed to "open source". Open-source software. The open-source model. The open source culture. The Debian Open Source Guidelines. (In pitching this to the corporate world I'm also going to be invoking the idea of "peer review" a lot.)

And, we should explain publicly the reason for the change. Linus Torvalds has been saying in "World Domination 101" that the open-source culture needs to make a serious effort to take the desktop and engage the corporate mainstream. Of course he's right -- and this re-labeling, as Linus agrees, is part of the process. It says we're willing to work with and co-opt the market for our own purposes, rather than remaining stuck in a marginal, adversarial position.

This re-labeling has since attracted a lot of support (and some opposition) in the hacker culture. Supporters include Linus himself, John "maddog" Hall, Larry Augustin, Bruce Perens of Debian, Phil Hughes of Linux Journal. Opposers include Richard Stallman, who initially flirted with the idea but now thinks the term "open source" isn't pure enough.

Bruce Perens has applied to register "open source" as a trademark and hold it through Software in the Public Interest. The trademark conditions will be known as the ``Open Source Definition'', essentially the same as the Debian Free Software Guidelines.

It's crunch time, people. The Netscape announcement changes everything. We've broken out of the little corner we've been in for twenty years. We're in a whole new game now, a bigger and more exciting one -- and one I think we can win.

(A note about usage. In accordance with normal English practice, the term is "open source" standing alone, but "open-source" used as an adjective or in compounds; thus, "open-source software".)

(Yes, we're aware of the specialized meaning "open source" has in the intelligence community. This is a feature, not a bug.)

--------------------------------------------------------------------------------

basic & Brief history of Hacking.

noreply@blogger.com (aashu) — Sat, 15 Nov 2008 07:38:00 +0000

1st off all i just wanna clear the picture about hacking ,for every
one who heard this word he just feel curious about this word , his
imagination can go so far about hacking process think that the
hacker is avaliable to hack anything

but 4 sure that's not true , may be you have to be miracle to do
this through years and years of experience in the security field
knowing how those solid wires work and how to interfere them

i want also to tell you that there is big difference between hacker
and cracker
hacker don't do harm things , cracker exploite his experience to do
damage to what he is attacking

hacking process at the past was so compilicated as u must know every
protocol working in the layer you attack and how to deal with this
one and what is it's vulnerabilities

i mean it was just so amazing to hack something in the past , but
for now ....

the hacking process became so easy and require know experience to
attack a target ... for example

you google for attack programm,you put the ip ,then click connect

so simply you may connect the victim's pc

so here some hint's about hacking

Categories of hacker
This section does not cite its references or sources.
You can help Wikipedia by introducing appropriate citations.
The hacker community, the set of people who would describe
themselves as hackers or described by others as hackers, falls into
at least four partially overlapping categories. Sometimes alternate
terms such as "cracker" are used in an attempt to more exactly
distinguish which category of hacker is intended, or when attempting
to put a contextual distance between the categories due to the
Hacker definition controversy.

[edit] Hacker: Highly skilled programmer
The positive usage of hacker is one who knows a (sometimes
specified) set of programming interfaces well enough to program
rapidly and expertly. This type of hacker is well-respected
(although the term still carries some of the meaning of hack), and
is capable of developing programs without adequate planning or where
pre-planning is difficult or impossible to achieve. This zugzwang
gives freedom and the ability to be creative against methodical
careful progress. At their best, hackers can be very productive. The
technical downside of hacker productivity is often in
maintainability, documentation, and completion. Very talented
hackers may become bored with a project once they have figured out
all of the hard parts, and be unwilling to finish off the "details".
This attitude can cause friction in environments where other
programmers are expected to pick up the half finished work, decipher
the structures and ideas, and bullet-proof the code. In other cases,
where a hacker is willing to maintain their own code, a company may
be unable to find anyone else who is capable or willing to dig
through code to maintain the program if the original programmer
moves on to a new job.

Additionally, there is sometimes a social downside associated with
hacking. The stereotype of a hacker as having gained technical
ability at a cost in social ability has historical basis in an
uncomfortable amount of factual foundation in many individuals.
While not universal, nor even restricted to hackers, the difficulty
in relating to others and the often abrasive personalities of some
hackers makes some of them difficult to work with or to organize
into teams. On the other hand, it is not uncommon for hackers to
thrive on social interaction.

[edit] Hacker: Computer and network security expert
Main article: Hacker (computer security)
In the networking sense, a hacker is one who specializes in work
with the access control mechanisms for computer and network systems.
This includes individuals who work toward maintaining and improving
the integrity of such mechanisms. However, the most common usage of
hacker in this respect refers to someone who exploits systems or
gains unauthorized access by means of clever tactics and detailed
knowledge, while taking advantage of any carelessness or ignorance
on the part of system operators. This use of hacker as intruder
(frequent in the media) generally has a strong negative connotation,
and is disparaged and discouraged within the computer community,
resulting in the modern Hacker definition controversy.

For such hackers specializing in intrusion, the highly derogatory
term script kiddies is often used to indicate those who either claim
to have far more skill than they actually have, or who exclusively
use programs developed by others to achieve a successful security
exploit.

[edit] Hacker: Hardware modifier
Main article: Hardware hacker
Another type of hacker is one who creates novel hardware
modifications. At the most basic end of this spectrum are those who
make frequent changes to the hardware in their computers using
standard components, or make semi-cosmetic themed modifications to
the appearance of the machine. This type of Hacker modifes his/her
computer for performance needs and/or aesthetics. These changes
often include adding memory, storage or LEDs and cold cathode tubes
for light effects. These people often show off their talents in
contests, and many enjoy LAN parties. At the more advanced end of
the hardware hackers are those who modify hardware (not limited to
computers) to expand capabilities; this group blurs into the culture
of hobbyist inventors and professional electronics engineering. An
example of such modification includes the addition of TCP/IP
Internet capabilities to a number of vending machines and coffee
makers during the late 1980s and early 1990s.

Hackers who have the ability to write circuit-level code, device
drivers, firmware, low-level networking, (and even more
impressively, using these techniques to make devices do things
outside of their spec sheets), are typically in very high regard
among hacker communities. This is primarily due to the enormous
difficulty, complexity and specialized domain knowledge required for
this type of work, as well as the electrical engineering expertise
that plays a large role. Such hackers are rare, and almost always
considered to be wizards or gurus of a very high degree.

[edit] Hacker stereotypes
This section does not cite its references or sources.
You can help Wikipedia by introducing appropriate citations.
There are theoretical types of hackers who are considered to possess
an atypical level of skill beyond that of other meanings of the
positive form of "hacker", which include the Guru and the Wizard.

In some portions of the computer community, a Wizard is one who can
do anything a hacker can, but elegantly; while a Guru not only can
do so elegantly, but instruct those who do not know how. In other
sub-communities, a Guru is one with a very broad degree of
expertise, while a Wizard is expert in a very narrow field. In
practice, such exact distinction are usually more at home in a RPG
world, and not often heard in actual conversation.

Within the mainstream media, hackers are often characterised as
strange, mysterious, reclusive, and especially tricky. This may be
seen as an extension of the human tendency to stigmatise what is ill-
understood, which used often to be applied to natural philosophers
who were often thought by superstitious neighbours to be wizards or
mystics. One such example was Leonardo da Vinci, who was thought to
be a necromancer due to his extensive (and extraordinary at that
time) knowledge of human anatomy and his study of dead bodies.

[edit] Recognized hackers
Due to the overlapping nature of the hacker concept space, many of
these individuals could be included in more than one category. See
also Hacker (computer security), which has a list of people in that
category, including criminal or unethical hackers.

[edit] Skilled programmers
Tim Berners-Lee, inventor of the world wide web, while a student in
the 1970s, was banned from access to the Oxford University computer
for hacking access.[1]
Dan Bernstein, the author of qmail and djbdns, also a mathematician
and cryptographer.
John Carmack, a widely recognized and influential game programmer.
Through his work, he has made significant contributions to the field
of 3D computer graphics and his games have sold in the millions. In
1999, Carmack appeared as number 10 in TIME's list of the 50 most
influential people in technology.
Bill Gosper, mathematician and programmer, and contemporary of
Richard Greenblatt.
Richard Greenblatt, primary designer of the MIT Lisp machine and
pioneer of computerized chess.
Grace Hopper, the first programmer of the Mark I Calculator, also
developed the first compiler for a computer programming language.[2]
[3]
Bill Joy, the co-founder of Sun Microsystems and author of many
fundamental UNIX utilities.
Mel Kaye, the archetypal Real Programmer[4], was credited with
doing "the bulk of the programming" for the Royal McBee LGP-30 drum-
memory computer in the 1950s. Ed Nather, another hacker, published
the widely acclaimed "Story of Mel" in the 1980s.
Donald Knuth, best known for practically creating the field of
algorithm analysis, coding the TeX typesetting system, and writing
The Art of Computer Programming - one of the most respected
references in the field.
Rasmus Lerdorf, the creator of the PHP scripting language.
John McCarthy, the inventor of the Lisp programming language. Also
coined the term "Artificial Intelligence."
Rob Pike, a software engineer and author. He is best known for his
work at Bell Labs, where he was a member of the Unix team and was
involved in the creation of the Plan 9 and Inferno operating
systems.
Dennis Ritchie and Ken Thompson, who created Unix in 1969. Ritchie
is also notable for having created the C programming language, from
Ken Thompson's B programming language.
Guido van Rossum, the creator of the Python programming language.
Randal Schwartz, Perl programming language pioneer, billed himself
as "Just another Perl hacker (but not what the media
calls "'hacker'!)" This was in reference to characterizations made
during his criminal prosecution for unauthorized computer access.
Richard Stallman, the founder of the free software movement and the
GNU project, and original author of the GPL, Emacs, GDB, and the GNU
Compiler Collection. Acclaimed in Steven Levy's Hackers: Heroes of
the Computer Revolution as "The Last True Hacker."
Bjarne Stroustrup, the creator of the C++ programming language.
Theo de Raadt, the founder of the OpenBSD project.
Michael Tiemann, a co-founder of Cygnus Solutions, president of the
Open Source Initiative. Made many contributions to the GNU C
compiler, GNU debugger, and many other GNU development tools. Author
of the GNU C++ compiler.
Linus Torvalds, who was a computer science student at the University
of Helsinki when he began writing the Linux kernel in 1991.
Wietse Venema, best known for writing the Postfix mail system and co-
creating (with Dan Farmer) the Security Administrator Tool for
Analyzing Networks (SATAN), a remote vulnerability scanner.
Larry Wall, the creator of the Perl programming language.[5]
Steve Wozniak, a co-founder of Apple Computer (with Steve Jobs). Got
his start making devices for phone phreaking, working with John
Draper.

[edit] Security experts
Fyodor — Author of the open source Nmap Security Scanner, web site
Insecure.Org, co-author of hacking novel How to Own a Continent, and
founding member of the Honeynet Project.
Johan "Julf" Helsingius — Operated the world's most popular
anonymous remailer, the Penet remailer (called penet.fi), until he
closed up shop in September 1996.
Adrian Lamo - American hacker who gained notoriety by hacking high-
profile websites using common flaws in their webpages. Hacks include
The New York Times, AOL, MCI Worldcom, Cingular, Google, and the
NSA.
Mark Russinovich - Expert on Windows architecture and programming;
noted for identifying the limited differences between Windows NT
Server and Workstation, and discovering the 2005 Sony Rootkit
software
Bruce Schneier - Founder and CTO of Counterpane Internet Security,
Inc.[6]
Phil Zimmermann - Designer and developer of PGP that brought public-
key cryptography to the masses, and inadvertently upset the US
government which at the time considered cryptography to be a non-
exportable munition.
Solar Designer — Founder of the Openwall Project.

[edit] Hacker media personalities
Listed below are individuals who, while fitting in one or more of
the above categories, are currently more widely famous (especially
among the general public) for their media presence than their
technical accomplishments.

Loyd Blankenship (also known as The Mentor) — Former LOD member.
Author of The Conscience of a Hacker (Hacker's Manifesto).
Eric Corley (also known as Emmanuel Goldstein) — Long standing
publisher of 2600: The Hacker Quarterly and founder of the H.O.P.E.
conferences. He has been part of the hacker community since the
late '70s.
William Henry Gates III (Bill Gates) — is the co-founder and
chairman of Microsoft Corporation. Although he personally
demonstrated considerable personal coding skill early in his
company's history, he is most widely recognizable today as the
world's richest individual. Formerly CEO, in June 2006 he also
stepped down as chief software architect, with the intention of
stepping down as chairman in July 2008. [1]
Patrick K. Kroupa (also known as Lord Digital) — Former LOD member,
co-founder of MindVox, author of Phantom Access programs, and
MindVox: The Overture. Appears in over 20 books and hundreds of
media and press articles.
Kevin Mitnick — A former computer criminal who now (since his
release from prison in 2000) speaks, consults, and authors books
about social engineering and network security.
CULT OF THE DEAD COW — A high profile hacker group that has both
made news and been consulted by the media on numerous occasions.
Eric S. Raymond — One of the founders of the Open Source Initiative.
He wrote the famous text The Cathedral and the Bazaar and many other
essays. He also maintains the Jargon File for the Hacker culture,
which was previously maintained by Guy L. Steele, Jr..
Bruce Perens — Also one of the founders of the Open Source
Initiative. He was the former Debian GNU/Linux Project Leader, and
is the primary author of the Open Source Definition.
The 414s and Neal Patrick &mdash teenage hackers who gained brief
but widespread media coverage in 1983
Gary McKinnon &mdash accused of hacking into 97 United States
military and NASA computers in 2001 and 2002. [2]

noreply@blogger.com (aashu) — Sat, 15 Nov 2008 07:29:00 +0000

The Unix and Internet Fundamentals HOWTO --------------------------------------------------------------------------------12. How does the Internet work?To help you understand how the Internet works, we'll look at the things that happen when you do a typical Internet operation — pointing a browser at the front page of this document at its home on the Web at the Linux Documentation Project. This document ishttp://www.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/index.html which means it lives in the file HOWTO/Unix-and-Internet-Fundamentals-HOWTO/index.html under the World Wide Web export directory of the host www.tldp.org.12.1. Names and locationsThe first thing your browser has to do is to establish a network connection to the machine where the document lives. To do that, it first has to find the network location of the host www.tldp.org (‘host’ is short for ‘host machine’ or ‘network host'; www.tldp.org is a typical hostname). The corresponding location is actually a number called an IP address (we'll explain the ‘IP’ part of this term later).To do this, your browser queries a program called a name server. The name server may live on your machine, but it's more likely to run on a service machine that yours talks to. When you sign up with an ISP, part of your setup procedure will almost certainly involve telling your Internet software the IP address of a nameserver on the ISP's network.The name servers on different machines talk to each other, exchanging and keeping up to date all the information needed to resolve hostnames (map them to IP addresses). Your nameserver may query three or four different sites across the network in the process of resolving www.tldp.org, but this usually happens very quickly (as in less than a second). We'll look at how nameservers detail in the next section.The nameserver will tell your browser that www.tldp.org's IP address is 152.19.254.81; knowing this, your machine will be able to exchange bits with www.tldp.org directly.12.2. The Domain Name SystemThe whole network of programs and databases that cooperates to translate hostnames to IP addresses is called ‘DNS’ (Domain Name System). When you see references to a ‘DNS server’, that means what we just called a nameserver. Now I'll explain how the overall system works.Internet hostnames are composed of parts separated by dots. A domain is a collection of machines that share a common name suffix. Domains can live inside other domains. For example, the machine www.tldp.org lives in the .tldp.org subdomain of the .org domain.Each domain is defined by an authoritative name server that knows the IP addresses of the other machines in the domain. The authoritative (or ‘primary') name server may have backups in case it goes down; if you see references to a secondary name server or (‘secondary DNS') it's talking about one of those. These secondaries typically refresh their information from their primaries every few hours, so a change made to the hostname-to-IP mapping on the primary will automatically be propagated.Now here's the important part. The nameservers for a domain do not have to know the locations of all the machines in other domains (including their own subdomains); they only have to know the location of the nameservers. In our example, the authoritative name server for the .org domain knows the IP address of the nameserver for .tldp.org but not the address of all the other machines in .tldp.org. The domains in the DNS system are arranged like a big inverted tree. At the top are the root servers. Everybody knows the IP addresses of the root servers; they're wired into your DNS software. The root servers know the IP addresses of the nameservers for the top-level domains like .com and .org, but not the addresses of machines inside those domains. Each top-level domain server knows where the nameservers for the domains directly beneath it are, and so forth.DNS is carefully designed so that each machine can get away with the minimum amount of knowledge it needs to have about the shape of the tree, and local changes to subtrees can be made simply by changing one authoritative server's database of name-to-IP-address mappings.When you query for the IP address of www.tldp.org, what actually happens is this: First, your nameserver asks a root server to tell it where it can find a nameserver for .org. Once it knows that, it then asks the .org server to tell it the IP address of a .tldp.org nameserver. Once it has that, it asks the .tldp.org nameserver to tell it the address of the host www.tldp.org.Most of the time, your nameserver doesn't actually have to work that hard. Nameservers do a lot of cacheing; when yours resolves a hostname, it keeps the association with the resulting IP address around in memory for a while. This is why, when you surf to a new website, you'll usually only see a message from your browser about "Looking up" the host for the first page you fetch. Eventually the name-to-address mapping expires and your DNS has to re-query — this is important so you don't have invalid information hanging around forever when a hostname changes addresses. Your cached IP address for a site is also thrown out if the host is unreachable. 12.3. Packets and routersWhat the browser wants to do is send a command to the Web server on www.tldp.org that looks like this:GET /LDP/HOWTO/Fundamentals.html HTTP/1.0 Here's how that happens. The command is made into a packet, a block of bits like a telegram that is wrapped with three important things; the source address (the IP address of your machine), the destination address (152.19.254.81), and a service number or port number (80, in this case) that indicates that it's a World Wide Web request.Your machine then ships the packet down the wire (your connection to your ISP, or local network) until it gets to a specialized machine called a router. The router has a map of the Internet in its memory — not always a complete one, but one that completely describes your network neighborhood and knows how to get to the routers for other neighborhoods on the Internet.Your packet may pass through several routers on the way to its destination. Routers are smart. They watch how long it takes for other routers to acknowledge having received a packet. They also use that information to direct traffic over fast links. They use it to notice when another router (or a cable) have dropped off the network, and compensate if possible by finding another route.There's an urban legend that the Internet was designed to survive nuclear war. This is not true, but the Internet's design is extremely good at getting reliable performance out of flaky hardware in an uncertain world. This is directly due to the fact that its intelligence is distributed through thousands of routers rather than concentrated in a few massive and vulnerable switches (like the phone network). This means that failures tend to be well localized and the network can route around them.Once your packet gets to its destination machine, that machine uses the service number to feed the packet to the web server. The web server can tell where to reply to by looking at the command packet's source IP address. When the web server returns this document, it will be broken up into a number of packets. The size of the packets will vary according to the transmission media in the network and the type of service.12.4. TCP and IPTo understand how multiple-packet transmissions are handled, you need to know that the Internet actually uses two protocols, stacked one on top of the other.The lower level, IP (Internet Protocol), is responsible for labeling individual packets with the source address and destination address of two computers exchanging information over a network. For example, when you access http://www.tldp.org, the packets you send will have your computer's IP address, such as 192.168.1.101, and the IP address of the www.tldp.org computer, 152.2.210.81. These addresses work in much the same way that your home address works when someone sends you a letter. The post office can read the address and determine where you are and how best to route the letter to you, much like a router does for Internet traffic.The upper level, TCP (Transmission Control Protocol), gives you reliability. When two machines negotiate a TCP connection (which they do using IP), the receiver knows to send acknowledgements of the packets it sees back to the sender. If the sender doesn't see an acknowledgement for a packet within some timeout period, it resends that packet. Furthermore, the sender gives each TCP packet a sequence number, which the receiver can use to reassemble packets in case they show up out of order. (This can easily happen if network links go up or down during a connection.)TCP/IP packets also contain a checksum to enable detection of data corrupted by bad links. (The checksum is computed from the rest of the packet in such a way that if either the rest of the packet or the checksum is corrupted, redoing the computation and comparing is very likely to indicate an error.) So, from the point of view of anyone using TCP/IP and nameservers, it looks like a reliable way to pass streams of bytes between hostname/service-number pairs. People who write network protocols almost never have to think about all the packetizing, packet reassembly, error checking, checksumming, and retransmission that goes on below that level.12.5. HTTP, an application protocolNow let's get back to our example. Web browsers and servers speak an application protocol that runs on top of TCP/IP, using it simply as a way to pass strings of bytes back and forth. This protocol is called HTTP (Hyper-Text Transfer Protocol) and we've already seen one command in it — the GET shown above.When the GET command goes to www.tldp.org's webserver with service number 80, it will be dispatched to a server daemon listening on port 80. Most Internet services are implemented by server daemons that do nothing but wait on ports, watching for and executing incoming commands.If the design of the Internet has one overall rule, it's that all the parts should be as simple and human-accessible as possible. HTTP, and its relatives (like the Simple Mail Transfer Protocol, SMTP, that is used to move electronic mail between hosts) tend to use simple printable-text commands that end with a carriage-return/line feed.This is marginally inefficient; in some circumstances you could get more speed by using a tightly-coded binary protocol. But experience has shown that the benefits of having commands be easy for human beings to describe and understand outweigh any marginal gain in efficiency that you might get at the cost of making things tricky and opaque.Therefore, what the server daemon ships back to you via TCP/IP is also text. The beginning of the response will look something like this (a few headers have been suppressed):HTTP/1.1 200 OKDate: Sat, 10 Oct 1998 18:43:35 GMTServer: Apache/1.2.6 Red HatLast-Modified: Thu, 27 Aug 1998 17:55:15 GMTContent-Length: 2982Content-Type: text/html These headers will be followed by a blank line and the text of the web page (after which the connection is dropped). Your browser just displays that page. The headers tell it how (in particular, the Content-Type header tells it the returned data is really HTML).--------------------------------------------------------------------------------

Basic Of Unix.

noreply@blogger.com (aashu) — Sat, 15 Nov 2008 07:19:00 +0000

--------------------------------------------------------------------------------

1. Introduction
1.1. Purpose of this documentThis document is intended to help Linux and Internet users who are learning by doing. While this is a great way to acquire specific skills, sometimes it leaves peculiar gaps in one's knowledge of the basics — gaps which can make it hard to think creatively or troubleshoot effectively, from lack of a good mental model of what is really going on.
I'll try to describe in clear, simple language how it all works. The presentation will be tuned for people using Unix or Linux on PC-class machines. Nevertheless, I'll usually refer simply to ‘Unix’ here, as most of what I will describe is constant across different machines and across Unix variants.
I'm going to assume you're using an Intel PC. The details differ slightly if you're running an PowerPC or some other kind of computer, but the basic concepts are the same.
I won't repeat things, so you'll have to pay attention, but that also means you'll learn from every word you read. It's a good idea to just skim when you first read this; you should come back and reread it a few times after you've digested what you have learned.
This is an evolving document. I intend to keep adding sections in response to user feedback, so you should come back and review it periodically.
1.2. New versions of this document
New versions of the Unix and Internet Fundamentals HOWTO will be periodically posted to comp.os..linux.help and comp.os.linux.announce and news.answers. They will also be uploaded to various websites, including the Linux Documentation Project home page.
You can view the latest version of this on the World Wide Web via the URL http:http://www.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/index.html.
This document has been translated into: PolishSpanish.
1.3. Feedback and corrections
If you have questions or comments about this document, please feel free to mail Eric S. Raymond, at esr@thyrsus.com. I welcome any suggestions or criticisms. I especially welcome hyperlinks to more detailed explanations of individual concepts.. If you find a mistake with this document, please let me know so I can correct it in the next version. Thanks.
1.4. Related resources
If you're reading this in order to learn how to hack, you should also read the How To Become A Hacker FAQ. It has links to some other useful resources.

The Unix and Internet Fundamentals HOWTO
Prev Next

--------------------------------------------------------------------------------

2. Basic anatomy of your computer

Your computer has a processor chip inside it that does the actual computing. It has internal memory (what DOS/Windows people call "RAM" and Unix people often call "core"; the Unix term is a folk memory from when RAM consisted of ferrite-core donuts). The processor and memory live on the motherboard, which is the heart of your computer.
Your computer has a screen and keyboard. It has hard drives and a CD-ROM and maybe a floppy disk. Some of these devices are run by controller cards that plug into the motherboard and help the computer drive them; others are run by specialized chipsets directly on the motherboard that fulfill the same function as a controller card. Your keyboard is too simple to need a separate card; the controller is built into the keyboard chassis itself.
We'll go into some of the details of how these devices work later. For now, here are a few basic things to keep in mind about how they work together:
All the parts of your computer inside the case are connected by a bus. Physically, the bus is what you plug your controller cards into (the video card, the disk controller, a sound card if you have one). The bus is the data highway between your processor, your screen, your disk, and everything else.
(If you've seen references to ‘ISA’, ‘PCI’, and ‘PCMCIA’ in connection with PCs and have not understood them, these are bus types. ISA is, except in minor details, the same bus that was used on IBM's original PCs in 1980; it is passing out of use now. PCI, for Peripheral Component Interconnection, is the bus used on most modern PCs, and on modern Macintoshes as well. PCMCIA is a variant of ISA with smaller physical connectors used on laptop computers.)
The processor, which makes everything else go, can't actually see any of the other pieces directly; it has to talk to them over the bus. The only other subsystem that it has really fast, immediate access to is memory (the core). In order for programs to run, then, they have to be in core (in memory).
When your computer reads a program or data off the disk, what actually happens is that the processor uses the bus to send a disk read request to your disk controller. Some time later the disk controller uses the bus to signal the processor that it has read the data and put it in a certain location in memory. The processor can then use the bus to look at that data.
Your keyboard and screen also communicate with the processor via the bus, but in simpler ways. We'll discuss those later on. For now, you know enough to understand what happens when you turn on your computer.

The Unix and Internet Fundamentals HOWTO
Prev Next

--------------------------------------------------------------------------------

3. What happens when you switch on a computer?

A computer without a program running is just an inert hunk of electronics. The first thing a computer has to do when it is turned on is start up a special program called an operating system. The operating system's job is to help other computer programs to work by handling the messy details of controlling the computer's hardware.
The process of bringing up the operating system is called booting (originally this was bootstrapping and alluded to the process of pulling yourself up "by your bootstraps"). Your computer knows how to boot because instructions for booting are built into one of its chips, the BIOS (or Basic Input/Output System) chip.
The BIOS chip tells it to look in a fixed place, usually on the lowest-numbered hard disk (the boot disk) for a special program called a boot loader (under Linux the boot loader is called Grub or LILO). The boot loader is pulled into memory and started. The boot loader's job is to start the real operating system.
The loader does this by looking for a kernel, loading it into memory, and starting it. When you boot Linux and see "LILO" on the screen followed by a bunch of dots, it is loading the kernel. (Each dot means it has loaded another disk block of kernel code.)
(You may wonder why the BIOS doesn't load the kernel directly — why the two-step process with the boot loader? Well, the BIOS isn't very smart. In fact it's very stupid, and Linux doesn't use it at all after boot time. It was originally written for primitive 8-bit PCs with tiny disks, and literally can't access enough of the disk to load the kernel directly. The boot loader step also lets you start one of several operating systems off different places on your disk, in the unlikely event that Unix isn't good enough for you.)
Once the kernel starts, it has to look around, find the rest of the hardware, and get ready to run programs. It does this by poking not at ordinary memory locations but rather at I/O ports — special bus addresses that are likely to have device controller cards listening at them for commands. The kernel doesn't poke at random; it has a lot of built-in knowledge about what it's likely to find where, and how controllers will respond if they're present. This process is called autoprobing.
Most of the messages you see at boot time are the kernel autoprobing your hardware through the I/O ports, figuring out what it has available to it and adapting itself to your machine. The Linux kernel is extremely good at this, better than most other Unixes and much better than DOS or Windows. In fact, many Linux old-timers think the cleverness of Linux's boot-time probes (which made it relatively easy to install) was a major reason it broke out of the pack of free-Unix experiments to attract a critical mass of users.
But getting the kernel fully loaded and running isn't the end of the boot process; it's just the first stage (sometimes called run level 1). After this first stage, the kernel hands control to a special process called ‘init’ which spawns several housekeeping processes.
The init process's first job is usually to check to make sure your disks are OK. Disk file systems are fragile things; if they've been damaged by a hardware failure or a sudden power outage, there are good reasons to take recovery steps before your Unix is all the way up. We'll go into some of this later on when we talk about how file systems can go wrong.
Init's next step is to start several daemons. A daemon is a program like a print spooler, a mail listener or a WWW server that lurks in the background, waiting for things to do. These special programs often have to coordinate several requests that could conflict. They are daemons because it's often easier to write one program that runs constantly and knows about all requests than it would be to try to make sure that a flock of copies (each processing one request and all running at the same time) don't step on each other. The particular collection of daemons your system starts may vary, but will almost always include a print spooler (a gatekeeper daemon for your printer).
The next step is to prepare for users. Init starts a copy of a program called getty to watch your console (and maybe more copies to watch dial-in serial ports). This program is what issues the login prompt to your console. Once all daemons and getty processes for each terminal are started, we're at run level 2. At this level, you can log in and run programs.
But we're not done yet. The next step is to start up various daemons that support networking and other services. Once that's done, we're at run level 3 and the system is fully ready for use.

--------------------------------------------------------------------------------

The Unix and Internet Fundamentals HOWTO
Prev Next

--------------------------------------------------------------------------------

4. What happens when you log in?

When you log in (give a name to getty) you identify yourself to the computer. It then runs a program called (naturally enough) login, which takes your password and checks to see if you are authorized to be using the machine. If you aren't, your login attempt will be rejected. If you are, login does a few housekeeping things and then starts up a command interpreter, the shell. (Yes, getty and login could be one program. They're separate for historical reasons not worth going into here.)
Here's a bit more about what the system does before giving you a shell (you'll need to know this later when we talk about file permissions). You identify yourself with a login name and password. That login name is looked up in a file called /etc/passwd, which is a sequence of lines each describing a user account.
One of these fields is an encrypted version of the account password (sometimes the encrypted fields are actually kept in a second /etc/shadow file with tighter permissions; this makes password cracking harder). What you enter as an account password is encrypted in exactly the same way, and the login program checks to see if they match. The security of this method depends on the fact that, while it's easy to go from your clear password to the encrypted version, the reverse is very hard. Thus, even if someone can see the encrypted version of your password, they can't use your account. (It also means that if you forget your password, there's no way to recover it, only to change it to something else you choose.)
Once you have successfully logged in, you get all the privileges associated with the individual account you are using. You may also be recognized as part of a group. A group is a named collection of users set up by the system administrator. Groups can have privileges independently of their members’ privileges. A user can be a member of multiple groups. (For details about how Unix privileges work, see the section below on permissions.)
(Note that although you will normally refer to users and groups by name, they are actually stored internally as numeric IDs. The password file maps your account name to a user ID; the /etc/group file maps group names to numeric group IDs. Commands that deal with accounts and groups do the translation automatically.)
Your account entry also contains your home directory, the place in the Unix file system where your personal files will live. Finally, your account entry also sets your shell, the command interpreter that login will start up to accept your commmands.

--------------------------------------------------------------------------------

The Unix and Internet Fundamentals HOWTO
Prev Next

--------------------------------------------------------------------------------

5. What happens when you run programs from the shell?

The shell is Unix's interpreter for the commands you type in; it's called a shell because it wraps around and hides the operating system kernel. It's an important feature of Unix that the shell and kernel are separate programs communicating through a small set of system calls. This makes it possible for there to be multiple shells, suiting different tastes in interfaces.
The normal shell gives you the ‘$’ prompt that you see after logging in (unless you've customized it to be something else). We won't talk about shell syntax and the easy things you can see on the screen here; instead we'll take a look behind the scenes at what's happening from the computer's point of view.
After boot time and before you run a program, you can think of your computer as containing a zoo of processes that are all waiting for something to do. They're all waiting on events. An event can be you pressing a key or moving a mouse. Or, if your machine is hooked to a network, an event can be a data packet coming in over that network.
The kernel is one of these processes. It's a special one, because it controls when the other user processes can run, and it is normally the only process with direct access to the machine's hardware. In fact, user processes have to make requests to the kernel when they want to get keyboard input, write to your screen, read from or write to disk, or do just about anything other than crunching bits in memory. These requests are known as system calls.
Normally all I/O goes through the kernel so it can schedule the operations and prevent processes from stepping on each other. A few special user processes are allowed to slide around the kernel, usually by being given direct access to I/O ports. X servers (the programs that handle other programs’ requests to do screen graphics on most Unix boxes) are the most common example of this. But we haven't gotten to an X server yet; you're looking at a shell prompt on a character console.
The shell is just a user process, and not a particularly special one. It waits on your keystrokes, listening (through the kernel) to the keyboard I/O port. As the kernel sees them, it echoes them to your screen. When the kernel sees an ‘Enter’ it passes your line of text to the shell. The shell tries to interpret those keystrokes as commands.
Let's say you type ‘ls’ and Enter to invoke the Unix directory lister. The shell applies its built-in rules to figure out that you want to run the executable command in the file /bin/ls. It makes a system call asking the kernel to start /bin/ls as a new child process and give it access to the screen and keyboard through the kernel. Then the shell goes to sleep, waiting for ls to finish.
When /bin/ls is done, it tells the kernel it's finished by issuing an exit system call. The kernel then wakes up the shell and tells it it can continue running. The shell issues another prompt and waits for another line of input.
Other things may be going on while your ‘ls’ is executing, however (we'll have to suppose that you're listing a very long directory). You might switch to another virtual console, log in there, and start a game of Quake, for example. Or, suppose you're hooked up to the Internet. Your machine might be sending or receiving mail while /bin/Is runs.

The Unix and Internet Fundamentals HOWTO
Prev Next

--------------------------------------------------------------------------------

6. How do input devices and interrupts work?

Your keyboard is a very simple input device; simple because it generates small amounts of data very slowly (by a computer's standards). When you press or release a key, that event is signalled up the keyboard cable to raise a hardware interrupt.
It's the operating system's job to watch for such interrupts. For each possible kind of interrupt, there will be an interrupt handler, a part of the operating system that stashes away any data associated with them (like your keypress/keyrelease value) until it can be processed.
What the interrupt handler for your keyboard actually does is post the key value into a system area near the bottom of memory. There, it will be available for inspection when the operating system passes control to whichever program is currently supposed to be reading from the keyboard.
More complex input devices like disk or network cards work in a similar way. Earlier, I referred to a disk controller using the bus to signal that a disk request has been fulfilled. What actually happens is that the disk raises an interrupt. The disk interrupt handler then copies the retrieved data into memory, for later use by the program that made the request.
Every kind of interrupt has an associated priority level. Lower-priority interrupts (like keyboard events) have to wait on higher-priority interrupts (like clock ticks or disk events). Unix is designed to give high priority to the kinds of events that need to be processed rapidly in order to keep the machine's response smooth.
In your operating system's boot-time messages, you may see references to IRQ numbers. You may be aware that one of the common ways to misconfigure hardware is to have two different devices try to use the same IRQ, without understanding exactly why.
Here's the answer. IRQ is short for "Interrupt Request". The operating system needs to know at startup time which numbered interrupts each hardware device will use, so it can associate the proper handlers with each one. If two different devices try use the same IRQ, interrupts will sometimes get dispatched to the wrong handler. This will usually at least lock up the device, and can sometimes confuse the OS badly enough that it will flake out or crash.

The Unix and Internet Fundamentals HOWTO
Prev Next

--------------------------------------------------------------------------------

7. How does my computer do several things at once?

It doesn't, actually. Computers can only do one task (or process) at a time. But a computer can change tasks very rapidly, and fool slow human beings into thinking it's doing several things at once. This is called timesharing.
One of the kernel's jobs is to manage timesharing. It has a part called the scheduler which keeps information inside itself about all the other (non-kernel) processes in your zoo. Every 1/60th of a second, a timer goes off in the kernel, generating a clock interrupt. The scheduler stops whatever process is currently running, suspends it in place, and hands control to another process.
1/60th of a second may not sound like a lot of time. But on today's microprocessors it's enough to run tens of thousands of machine instructions, which can do a great deal of work. So even if you have many processes, each one can accomplish quite a bit in each of its timeslices.
In practice, a program may not get its entire timeslice. If an interrupt comes in from an I/O device, the kernel effectively stops the current task, runs the interrupt handler, and then returns to the current task. A storm of high-priority interrupts can squeeze out normal processing; this misbehavior is called thrashing and is fortunately very hard to induce under modern Unixes.
In fact, the speed of programs is only very seldom limited by the amount of machine time they can get (there are a few exceptions to this rule, such as sound or 3-D graphics generation). Much more often, delays are caused when the program has to wait on data from a disk drive or network connection.
An operating system that can routinely support many simultaneous processes is called "multitasking". The Unix family of operating systems was designed from the ground up for multitasking and is very good at it — much more effective than Windows or the old Mac OS, which had multitasking bolted into them as an afterthought and do it rather poorly. Efficient, reliable multitasking is a large part of what makes Linux superior for networking, communications, and Web service.

The Unix and Internet Fundamentals HOWTO
Prev Next

--------------------------------------------------------------------------------

8. How does my computer keep processes from stepping on each other?

The kernel's scheduler takes care of dividing processes in time. Your operating system also has to divide them in space, so that processes can't step on each others'; working memory. Even if you assume that all programs are trying to be cooperative, you don't want a bug in one of them to be able to corrupt others. The things your operating system does to solve this problem are called memory management.
Each process in your zoo needs its own area of memory, as a place to run its code from and keep variables and results in. You can think of this set as consisting of a read-only code segment (containing the process's instructions) and a writeable data segment (containing all the process's variable storage). The data segment is truly unique to each process, but if two processes are running the same code Unix automatically arranges for them to share a single code segment as an efficiency measure.
8.1. Virtual memory: the simple version

Efficiency is important, because memory is expensive. Sometimes you don't have enough to hold the entirety of all the programs the machine is running, especially if you are using a large program like an X server. To get around this, Unix uses a technique called virtual memory. It doesn't try to hold all the code and data for a process in memory. Instead, it keeps around only a relatively small working set; the rest of the process's state is left in a special swap space area on your hard disk.
Note that in the past, that "Sometimes" last paragraph ago was "Almost always" — the size of memory was typically small relative to the size of running programs, so swapping was frequent. Memory is far less expensive nowadays and even low-end machines have quite a lot of it. On modern single-user machines with 64MB of memory and up, it's possible to run X and a typical mix of jobs without ever swapping after they're initially loaded into core.
8.2. Virtual memory: the detailed version
Actually, the last section oversimplified things a bit. Yes, programs see most of your memory as one big flat bank of addresses bigger than physical memory, and disk swapping is used to maintain that illusion. But your hardware actually has no fewer than five different kinds of memory in it, and the differences between them can matter a good deal when programs have to be tuned for maximum speed. To really understand what goes on in your machine, you should learn how all of them work.
The five kinds of memory are these: processor registers, internal (or on-chip) cache, external (or off-chip) cache, main memory, and disk. And the reason there are so many kinds is simple: speed costs money. I have listed these kinds of memory in increasing order of access time and decreasing order of cost. Register memory is the fastest and most expensive and can be random-accessed about a billion times a second, while disk is the slowest and cheapest and can do about 100 random accesses a second.
Here's a full list reflecting early-2000 speeds for a typical desktop machine. While speed and capacity will go up and prices will drop, you can expect these ratios to remain fairly constant — and it's those ratios that shape the memory hierarchy.
Disk
Size: 13000MB Accesses: 100KB/sec
Main memory
Size: 256MB Accesses: 100M/sec
External cache
Size: 512KB Accesses: 250M/sec
Internal Cache
Size: 32KB Accesses: 500M/sec
Processor
Size: 28 bytes Accesses: 1000M/sec
We can't build everything out of the fastest kinds of memory. It would be way too expensive — and even if it weren't, fast memory is volatile. That is, it loses its marbles when the power goes off. Thus, computers have to have hard disks or other kinds of non-volatile storage that retains data when the power goes off. And there's a huge mismatch between the speed of processors and the speed of disks. The middle three levels of the memory hierarchy (internal cache, external cache, and main memory) basically exist to bridge that gap.
Linux and other Unixes have a feature called virtual memory. What this means is that the operating system behaves as though it has much more main memory than it actually does. Your actual physical main memory behaves like a set of windows or caches on a much larger "virtual" memory space, most of which at any given time is actually stored on disk in a special zone called the swap area. Out of sight of user programs, the OS is moving blocks of data (called "pages") between memory and disk to maintain this illusion. The end result is that your virtual memory is much larger but not too much slower than real memory.
How much slower virtual memory is than physical depends on how well the operating system's swapping algorithms match the way your programs use virtual memory. Fortunately, memory reads and writes that are close together in time also tend to cluster in memory space. This tendency is called locality, or more formally locality of reference — and it's a good thing. If memory references jumped around virtual space at random, you'd typically have to do a disk read and write for each new reference and virtual memory would be as slow as a disk. But because programs do actually exhibit strong locality, your operating system can do relatively few swaps per reference.
It's been found by experience that the most effective method for a broad class of memory-usage patterns is very simple; it's called LRU or the "least recently used" algorithm. The virtual-memory system grabs disk blocks into its working set as it needs them. When it runs out of physical memory for the working set, it dumps the least-recently-used block. All Unixes, and most other virtual-memory operating systems, use minor variations on LRU.
Virtual memory is the first link in the bridge between disk and processor speeds. It's explicitly managed by the OS. But there is still a major gap between the speed of physical main memory and the speed at which a processor can access its register memory. The external and internal caches address this, using a technique similar to virtual memory as I've described it.
Just as the physical main memory behaves like a set of windows or caches on the disk's swap area, the external cache acts as windows on main memory. External cache is faster (250M accesses per sec, rather than 100M) and smaller. The hardware (specifically, your computer's memory controller) does the LRU thing in the external cache on blocks of data fetched from the main memory. For historical reasons, the unit of cache swapping is called a line rather than a page.
But we're not done. The internal cache gives us the final step-up in effective speed by caching portions of the external cache. It is faster and smaller yet — in fact, it lives right on the processor chip.
If you want to make your programs really fast, it's useful to know these details. Your programs get faster when they have stronger locality, because that makes the caching work better. The easiest way to make programs fast is therefore to make them small. If a program isn't slowed down by lots of disk I/O or waits on network events, it will usually run at the speed of the smallest cache that it will fit inside.
If you can't make your whole program small, some effort to tune the speed-critical portions so they have stronger locality can pay off. Details on techniques for doing such tuning are beyond the scope of this tutorial; by the time you need them, you'll be intimate enough with some compiler to figure out many of them yourself.
8.3. The Memory Management Unit
Even when you have enough physical core to avoid swapping, the part of the operating system called the memory manager still has important work to do. It has to make sure that programs can only alter their own data segments — that is, prevent erroneous or malicious code in one program from garbaging the data in another. To do this, it keeps a table of data and code segments. The table is updated whenever a process either requests more memory or releases memory (the latter usually when it exits).
This table is used to pass commands to a specialized part of the underlying hardware called an MMU or memory management unit. Modern processor chips have MMUs built right onto them. The MMU has the special ability to put fences around areas of memory, so an out-of-bound reference will be refused and cause a special interrupt to be raised.
If you ever see a Unix message that says "Segmentation fault", "core dumped" or something similar, this is exactly what has happened; an attempt by the running program to access memory (core) outside its segment has raised a fatal interrupt. This indicates a bug in the program code; the core dump it leaves behind is diagnostic information intended to help a programmer track it down.
There is another aspect to protecting processes from each other besides segregating the memory they access. You also want to be able to control their file accesses so a buggy or malicious program can't corrupt critical pieces of the system. This is why Unix has file permissions which we'll discuss later.

The Unix and Internet Fundamentals HOWTO
Prev Next

--------------------------------------------------------------------------------

9. How does my computer store things in memory?

You probably know that everything on a computer is stored as strings of bits (binary digits; you can think of them as lots of little on-off switches). Here we'll explain how those bits are used to represent the letters and numbers that your computer is crunching.
Before we can go into this, you need to understand about the word size of your computer. The word size is the computer's preferred size for moving units of information around; technically it's the width of your processor's registers, which are the holding areas your processor uses to do arithmetic and logical calculations. When people write about computers having bit sizes (calling them, say, "32-bit" or "64-bit" computers), this is what they mean.
Most computers (including 386, 486, and Pentium PCs) have a word size of 32 bits. The old 286 machines had a word size of 16. Old-style mainframes often had 36-bit words. The AMD Opteron, Intel Itanium, and the Alpha from what used to be DEC and is now Compaq have 64-bit words.
The computer views your memory as a sequence of words numbered from zero up to some large value dependent on your memory size. That value is limited by your word size, which is why programs on older machines like 286s had to go through painful contortions to address large amounts of memory. I won't describe them here; they still give older programmers nightmares.
9.1. Numbers
Integer numbers are represented as either words or pairs of words, depending on your processor's word size. One 32-bit machine word is the most common integer representation.
Integer arithmetic is close to but not actually mathematical base-two. The low-order bit is 1, next 2, then 4 and so forth as in pure binary. But signed numbers are represented in twos-complement notation. The highest-order bit is a sign bit which makes the quantity negative, and every negative number can be obtained from the corresponding positive value by inverting all the bits and adding one. This is why integers on a 32-bit machine have the range -231 to 231 - 1. That 32nd bit is being used for sign; 0 means a positive number or zero, 1 a negative number.
Some computer languages give you access to unsigned arithmetic which is straight base 2 with zero and positive numbers only.
Most processors and some languages can do operations in floating-point numbers (this capability is built into all recent processor chips). Floating-point numbers give you a much wider range of values than integers and let you express fractions. The ways in which this is done vary and are rather too complicated to discuss in detail here, but the general idea is much like so-called ‘scientific notation’, where one might write (say) 1.234 * 1023; the encoding of the number is split into a mantissa (1.234) and the exponent part (23) for the power-of-ten multiplier (which means the number multiplied out would have 20 zeros on it, 23 minus the three decimal places).
9.2. Characters
Characters are normally represented as strings of seven bits each in an encoding called ASCII (American Standard Code for Information Interchange). On modern machines, each of the 128 ASCII characters is the low seven bits of an octet or 8-bit byte; octets are packed into memory words so that (for example) a six-character string only takes up two memory words. For an ASCII code chart, type ‘man 7 ascii’ at your Unix prompt.
The preceding paragraph was misleading in two ways. The minor one is that the term ‘octet’ is formally correct but seldom actually used; most people refer to an octet as byte and expect bytes to be eight bits long. Strictly speaking, the term ‘byte’ is more general; there used to be, for example, 36-bit machines with 9-bit bytes (though there probably never will be again).
The major one is that not all the world uses ASCII. In fact, much of the world can't — ASCII, while fine for American English, lacks many accented and other special characters needed by users of other languages. Even British English has trouble with the lack of a pound-currency sign.
There have been several attempts to fix this problem. All use the extra high bit that ASCII doesn't, making it the low half of a 256-character set. The most widely-used of these is the so-called ‘Latin-1’ character set (more formally called ISO 8859-1). This is the default character set for Linux, older versions of HTML, and X. Microsoft Windows uses a mutant version of Latin-1 that adds a bunch of characters such as right and left double quotes in places proper Latin-1 leaves unassigned for historical reasons (for a scathing account of the trouble this causes, see the demoroniser page).
Latin-1 handles western European languages, including English, French, German, Spanish, Italian, Dutch, Norwegian, Swedish, Danish, and Icelandic.. However, this isn't good enough either, and as a result there is a whole series of Latin-2 through -9 character sets to handle things like Greek, Arabic, Hebrew, Esperanto, and Serbo-Croatian. For details, see the ISO alphabet soup page.
The ultimate solution is a huge standard called Unicode (and its identical twin ISO/IEC 10646-1:1993). Unicode is identical to Latin-1 in its lowest 256 slots. Above these in 16-bit space it includes Greek, Cyrillic, Armenian, Hebrew, Arabic, Devanagari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Telugu, Kannada, Malayalam, Thai, Lao, Georgian, Tibetan, Japanese Kana, the complete set of modern Korean Hangul, and a unified set of Chinese/Japanese/Korean (CJK) ideographs. For details, see the Unicode Home Page. XML and XHTML use this character set.

The Unix and Internet Fundamentals HOWTO
Prev Next

--------------------------------------------------------------------------------

10. How does my computer store things on disk?

When you look at a hard disk under Unix, you see a tree of named directories and files. Normally you won't need to look any deeper than that, but it does become useful to know what's going on underneath if you have a disk crash and need to try to salvage files. Unfortunately, there's no good way to describe disk organization from the file level downwards, so I'll have to describe it from the hardware up.
10.1. Low-level disk and file system structure
The surface area of your disk, where it stores data, is divided up something like a dartboard — into circular tracks which are then pie-sliced into sectors. Because tracks near the outer edge have more area than those close to the spindle at the center of the disk, the outer tracks have more sector slices in them than the inner ones. Each sector (or disk block) has the same size, which under modern Unixes is generally 1 binary K (1024 8-bit words). Each disk block has a unique address or disk block number.
Unix divides the disk into disk partitions. Each partition is a continuous span of blocks that's used separately from any other partition, either as a file system or as swap space. The original reasons for partitions had to do with crash recovery in a world of much slower and more error-prone disks; the boundaries between them reduce the fraction of your disk likely to become inaccessible or corrupted by a random bad spot on the disk. Nowadays, it's more important that partitions can be declared read-only (preventing an intruder from modifying critical system files) or shared over a network through various means we won't discuss here. The lowest-numbered partition on a disk is often treated specially, as a boot partition where you can put a kernel to be booted..
Each partition is either swap space (used to implement virtual memory) or a file system used to hold files. Swap-space partitions are just treated as a linear sequence of blocks. File systems, on the other hand, need a way to map file names to sequences of disk blocks. Because files grow, shrink, and change over time, a file's data blocks will not be a linear sequence but may be scattered all over its partition (from wherever the operating system can find a free block when it needs one). This scattering effect is called fragmentation.
10.2. File names and directories
Within each file system, the mapping from names to blocks is handled through a structure called an i-node. There's a pool of these things near the "bottom" (lowest-numbered blocks) of each file system (the very lowest ones are used for housekeeping and labeling purposes we won't describe here). Each i-node describes one file. File data blocks (including directories) live above the i-nodes (in higher-numbered blocks).
Every i-node contains a list of the disk block numbers in the file it describes. (Actually this is a half-truth, only correct for small files, but the rest of the details aren't important here.) Note that the i-node does not contain the name of the file.
Names of files live in directory structures. A directory structure just maps names to i-node numbers. This is why, in Unix, a file can have multiple true names (or hard links); they're just multiple directory entries that happen to point to the same i-node.
10.3. Mount points
In the simplest case, your entire Unix file system lives in just one disk partition. While you'll see this arrangement on some small personal Unix systems, it's unusual. More typical is for it to be spread across several disk partitions, possibly on different physical disks. So, for example, your system may have one small partition where the kernel lives, a slightly larger one where OS utilities live, and a much bigger one where user home directories live.
The only partition you'll have access to immediately after system boot is your root partition, which is (almost always) the one you booted from. It holds the root directory of the file system, the top node from which everything else hangs.
The other partitions in the system have to be attached to this root in order for your entire, multiple-partition file system to be accessible. About midway through the boot process, your Unix will make these non-root partitions accessible. It will mount each one onto a directory on the root partition.
For example, if you have a Unix directory called /usr, it is probably a mount point to a partition that contains many programs installed with your Unix but not required during initial boot.
10.4. How a file gets looked up
Now we can look at the file system from the top down. When you open a file (such as, say, /home/esr/WWW/ldp/fundamentals.xml) here is what happens:
Your kernel starts at the root of your Unix file system (in the root partition). It looks for a directory there called ‘home’. Usually ‘home’ is a mount point to a large user partition elsewhere, so it will go there. In the top-level directory structure of that user partition, it will look for a entry called ‘esr’ and extract an i-node number. It will go to that i-node, notice that its associated file data blocks are a directory structure, and look up ‘WWW’. Extracting that i-node, it will go to the corresponding subdirectory and look up ‘ldp’. That will take it to yet another directory i-node. Opening that one, it will find an i-node number for ‘fundamentals.xml’. That i-node is not a directory, but instead holds the list of disk blocks associated with the file.
10.5. File ownership, permissions and security
To keep programs from accidentally or maliciously stepping on data they shouldn't, Unix has permission features. These were originally designed to support timesharing by protecting multiple users on the same machine from each other, back in the days when Unix ran mainly on expensive shared minicomputers.
In order to understand file permissions, you need to recall the description of users and groups in the section What happens when you log in?. Each file has an owning user and an owning group. These are initially those of the file's creator; they can be changed with the programs chown(1) and chgrp(1).
The basic permissions that can be associated with a file are ‘read’ (permission to read data from it), ‘write’ (permission to modify it) and ‘execute’ (permission to run it as a program). Each file has three sets of permissions; one for its owning user, one for any user in its owning group, and one for everyone else. The ‘privileges’ you get when you log in are just the ability to do read, write, and execute on those files for which the permission bits match your user ID or one of the groups you are in, or files that have been made accessible to the world.
To see how these may interact and how Unix displays them, let's look at some file listings on a hypothetical Unix system. Here's one:
snark:~$ ls -l notes-rw-r--r-- 1 esr users 2993 Jun 17 11:00 notes

This is an ordinary data file. The listing tells us that it's owned by the user ‘esr’ and was created with the owning group ‘users’. Probably the machine we're on puts every ordinary user in this group by default; other groups you commonly see on timesharing machines are ‘staff’, ‘admin’, or ‘wheel’ (for obvious reasons, groups are not very important on single-user workstations or PCs). Your Unix may use a different default group, perhaps one named after your user ID.
The string ‘-rw-r--r--’ represents the permission bits for the file. The very first dash is the position for the directory bit; it would show ‘d’ if the file were a directory, or would show ‘l’ if the file were a symbolic link. After that, the first three places are user permissions, the second three group permissions, and the third are permissions for others (often called ‘world’ permissions). On this file, the owning user ‘esr’ may read or write the file, other people in the ‘users’ group may read it, and everybody else in the world may read it. This is a pretty typical set of permissions for an ordinary data file.
Now let's look at a file with very different permissions. This file is GCC, the GNU C compiler.
snark:~$ ls -l /usr/bin/gcc-rwxr-xr-x 3 root bin 64796 Mar 21 16:41 /usr/bin/gcc

This file belongs to a user called ‘root’ and a group called ‘bin’; it can be written (modified) only by root, but read or executed by anyone. This is a typical ownership and set of permissions for a pre-installed system command. The ‘bin’ group exists on some Unixes to group together system commands (the name is a historical relic, short for ‘binary’). Your Unix might use a ‘root’ group instead (not quite the same as the ‘root' user!).
The ‘root’ user is the conventional name for numeric user ID 0, a special, privileged account that can override all privileges. Root access is useful but dangerous; a typing mistake while you're logged in as root can clobber critical system files that the same command executed from an ordinary user account could not touch.
Because the root account is so powerful, access to it should be guarded very carefully. Your root password is the single most critical piece of security information on your system, and it is what any crackers and intruders who ever come after you will be trying to get.
About passwords: Don't write them down — and don't pick a passwords that can easily be guessed, like the first name of your girlfriend/boyfriend/spouse. This is an astonishingly common bad practice that helps crackers no end. In general, don't pick any word in the dictionary; there are programs called dictionary crackers that look for likely passwords by running through word lists of common choices. A good technique is to pick a combination consisting of a word, a digit, and another word, such as ‘shark6cider’ or ‘jump3joy’; that will make the search space too large for a dictionary cracker. Don't use these examples, though — crackers might expect that after reading this document and put them in their dictionaries.
Now let's look at a third case:
snark:~$ ls -ld ~drwxr-xr-x 89 esr users 9216 Jun 27 11:29 /home2/esrsnark:~$

This file is a directory (note the ‘d’ in the first permissions slot). We see that it can be written only by esr, but read and executed by anybody else.
Read permission gives you the ability to list the directory — that is, to see the names of files and directories it contains. Write permission gives you the ability to create and delete files in the directory. If you remember that the directory includes a list of the names of the files and subdirectories it contains, these rules will make sense.
Execute permission on a directory means you can get through the directory to open the files and directories below it. In effect, it gives you permission to access the i-nodes in the directory. A directory with execute completely turned off would be useless.
Occasionally you'll see a directory that is world-executable but not world-readable; this means a random user can get to files and directories beneath it, but only by knowing their exact names (the directory cannot be listed).
It's important to remember that read, write, or execute permission on a directory is independent of the permissions on the files and directories beneath. In particular, write access on a directory means you can create new files or delete existing files there, but does not automatically give you write access to existing files.
Finally, let's look at the permissions of the login program itself.
snark:~$ ls -l /bin/login-rwsr-xr-x 1 root bin 20164 Apr 17 12:57 /bin/login

This has the permissions we'd expect for a system command — except for that ‘s’ where the owner-execute bit ought to be. This is the visible manifestation of a special permission called the ‘set-user-id’ or setuid bit.
The setuid bit is normally attached to programs that need to give ordinary users the privileges of root, but in a controlled way. When it is set on an executable program, you get the privileges of the owner of that program file while the program is running on your behalf, whether or not they match your own.
Like the root account itself, setuid programs are useful but dangerous.. Anyone who can subvert or modify a setuid program owned by root can use it to spawn a shell with root privileges. For this reason, opening a file to write it automatically turns off its setuid bit on most Unixes. Many attacks on Unix security try to exploit bugs in setuid programs in order to subvert them. Security-conscious system administrators are therefore extra-careful about these programs and reluctant to install new ones.
There are a couple of important details we glossed over when discussing permissions above; namely, how the owning group and permissions are assigned when a file or directory is first created. The group is an issue because users can be members of multiple groups, but one of them (specified in the user's /etc/passwd entry) is the user's default group and will normally own files created by the user.
The story with initial permission bits is a little more complicated. A program that creates a file will normally specify the permissions it is to start with. But these will be modified by a variable in the user's environment called the umask. The umask specifies which permission bits to turn off when creating a file; the most common value, and the default on most systems, is -------w- or 002, which turns off the world-write bit. See the documentation of the umask command on your shell's manual page for details.
Initial directory group is also a bit complicated. On some Unixes a new directory gets the default group of the creating user (this in the System V convention); on others, it gets the owning group of the parent directory in which it's created (this is the BSD convention). On some modern Unixes, including Linux, the latter behavior can be selected by setting the set-group-ID on the directory (chmod g+s).
10.6. How things can go wrong
Earlier it was hinted that file systems can be fragile things. Now we know that to get to a file you have to hopscotch through what may be an arbitrarily long chain of directory and i-node references. Now suppose your hard disk develops a bad spot?
If you're lucky, it will only trash some file data. If you're unlucky, it could corrupt a directory structure or i-node number and leave an entire subtree of your system hanging in limbo — or, worse, result in a corrupted structure that points multiple ways at the same disk block or i-node. Such corruption can be spread by normal file operations, trashing data that was not in the original bad spot.
Fortunately, this kind of contingency has become quite uncommon as disk hardware has become more reliable. Still, it means that your Unix will want to integrity-check the file system periodically to make sure nothing is amiss. Modern Unixes do a fast integrity check on each partition at boot time, just before mounting it. Every few reboots they'll do a much more thorough check that takes a few minutes longer.
If all of this sounds like Unix is terribly complex and failure-prone, it may be reassuring to know that these boot-time checks typically catch and correct normal problems before they become really disastrous. Other operating systems don't have these facilities, which speeds up booting a bit but can leave you much more seriously screwed when attempting to recover by hand (and that's assuming you have a copy of Norton Utilities or whatever in the first place...).
One of the trends in current Unix designs is journalling file systems. These arrange traffic to the disk so that it's guaranteed to be in a consistent state that can be recovered when the system comes back up. This will speed up the boot-time intergrity.

The Unix and Internet Fundamentals HOWTO
Prev Next

--------------------------------------------------------------------------------

11. How do computer languages work?

We've already discussed how programs are run. Every program ultimately has to execute as a stream of bytes that are instructions in your computer's machine language. But human beings don't deal with machine language very well; doing so has become a rare, black art even among hackers.
Almost all Unix code except a small amount of direct hardware-interface support in the kernel itself is nowadays written in a high-level language. (The ‘high-level’ in this term is a historical relic meant to distinguish these from ‘low-level’ assembler languages, which are basically thin wrappers around machine code.)
There are several different kinds of high-level languages. In order to talk about these, you'll find it useful to bear in mind that the source code of a program (the human-created, editable version) has to go through some kind of translation into machine code that the machine can actually run.
11.1. Compiled languages
The most conventional kind of language is a compiled language. Compiled languages get translated into runnable files of binary machine code by a special program called (logically enough) a compiler. Once the binary has been generated, you can run it directly without looking at the source code again. (Most software is delivered as compiled binaries made from code you don't see.)
Compiled languages tend to give excellent performance and have the most complete access to the OS, but also to be difficult to program in.
C, the language in which Unix itself is written, is by far the most important of these (with its variant C++). FORTRAN is another compiled language still used among engineers and scientists but years older and much more primitive. In the Unix world no other compiled languages are in mainstream use. Outside it, COBOL is very widely used for financial and business software.
There used to be many other compiler languages, but most of them have either gone extinct or are strictly research tools. If you are a new Unix developer using a compiled language, it is overwhelmingly likely to be C or C++.
11.2. Interpreted languages
An interpreted language depends on an interpreter program that reads the source code and translates it on the fly into computations and system calls. The source has to be re-interpreted (and the interpreter present) each time the code is executed.
Interpreted languages tend to be slower than compiled languages, and often have limited access to the underlying operating system and hardware. On the other hand, they tend to be easier to program and more forgiving of coding errors than compiled languages.
Many Unix utilities, including the shell and bc(1) and sed(1) and awk(1), are effectively small interpreted languages. BASICs are usually interpreted. So is Tcl. Historically, the most important interpretive language has been LISP (a major improvement over most of its successors). Today, Unix shells and the Lisp that lives inside the Emacs editor are probably the most important pure interpreted languages.
11.3. P-code languages
Since 1990 a kind of hybrid language that uses both compilation and interpretation has become increasingly important. P-code languages are like compiled languages in that the source is translated to a compact binary form which is what you actually execute, but that form is not machine code. Instead it's pseudocode (or p-code), which is usually a lot simpler but more powerful than a real machine language. When you run the program, you interpret the p-code.
P-code can run nearly as fast as a compiled binary (p-code interpreters can be made quite simple, small and speedy). But p-code languages can keep the flexibility and power of a good interpreter.
Important p-code languages include Python, Perl, and Java.

--------------------------------------------------------------------------------

How to become Hacker--part-3

noreply@blogger.com (aashu) — Fri, 14 Nov 2008 08:57:00 +0000

--------------------------------------------------------------------------------

Chapter 1. Hacker Slang and Hacker Culture
This document is a collection of slang terms used by various subcultures of computer hackers. Though some technical material is included for background and flavor, it is not a technical dictionary; what we describe here is the language hackers use among themselves for fun, social communication, and technical debate.
The 'hacker culture' is actually a loosely networked collection of subcultures that is nevertheless conscious of some important shared experiences, shared roots, and shared values. It has its own myths, heroes, villains, folk epics, in-jokes, taboos, and dreams. Because hackers as a group are particularly creative people who define themselves partly by rejection of 'normal' values and working habits, it has unusually rich and conscious traditions for an intentional culture less than 50 years old.
As usual with slang, the special vocabulary of hackers helps hold places in the community and expresses shared values and experiences. Also as usual, not knowing the slang (or using it inappropriately) defines one as an outsider, a mundane, or (worst of all in hackish vocabulary) possibly even a

suit. All human cultures use slang in this threefold way — as a tool of communication, and of inclusion, and of exclusion.
Among hackers, though, slang has a subtler aspect, paralleled perhaps in the slang of jazz musicians and some kinds of fine artists but hard to detect in most technical or scientific cultures; parts of it are code for shared states of consciousness. There is a whole range of altered states and problem-solving mental stances basic to high-level hacking which don't fit into conventional linguistic reality any better than a Coltrane solo or one of Maurits Escher's surreal trompe l'oeil compositions (Escher is a favorite of hackers), and hacker slang encodes these subtleties in many unobvious ways. As a simple example, take the distinction between a kluge and an elegant solution, and the differing connotations attached to each. The distinction is not only of engineering significance; it reaches right back into the nature of the generative processes in program design and asserts something important about two different kinds of relationship between the hacker and the hack. Hacker slang is unusually rich in implications of this kind, of overtones and undertones that illuminate the hackish psyche.
Hackers, as a rule, love wordplay and are very conscious and inventive in their use of language. These traits seem to be common in young children, but the conformity-enforcing machine we are pleased to call an educational system bludgeons them out of most of us before adolescence. Thus, linguistic invention in most subcultures of the modern West is a halting and largely unconscious process. Hackers, by contrast, regard slang formation and use as a game to be played for conscious pleasure. Their inventions thus display an almost unique combination of the neotenous enjoyment of language-play with the discrimination of educated and powerful intelligence. Further, the electronic media which knit them together are fluid, 'hot' connections, well adapted to both the dissemination of new slang and the ruthless culling of weak and superannuated specimens. The results of this process give us perhaps a uniquely intense and accelerated view of linguistic evolution in action.
Hacker slang also challenges some common linguistic and anthropological assumptions. For example, in the early 1990s it became fashionable to speak of 'low-context' versus 'high-context' communication, and to classify cultures by the preferred context level of their languages and art forms. It is usually claimed that low-context communication (characterized by precision, clarity, and completeness of self-contained utterances) is typical in cultures which value logic, objectivity, individualism, and competition; by contrast, high-context communication (elliptical, emotive, nuance-filled, multi-modal, heavily coded) is associated with cultures which value subjectivity, consensus, cooperation, and tradition. What then are we to make of hackerdom, which is themed around extremely low-context interaction with computers and exhibits primarily "low-context" values, but cultivates an almost absurdly high-context slang style?
The intensity and consciousness of hackish invention make a compilation of hacker slang a particularly effective window into the surrounding culture — and, in fact, this one is the latest version of an evolving compilation called the 'Jargon File', maintained by hackers themselves since the early 1970s. This one (like its ancestors) is primarily a lexicon, but also includes topic entries which collect background or sidelight information on hacker culture that would be awkward to try to subsume under individual slang definitions.
Though the format is that of a reference volume, it is intended that the material be enjoyable to browse. Even a complete outsider should find at least a chuckle on nearly every page, and much that is amusingly thought-provoking. But it is also true that hackers use humorous wordplay to make strong, sometimes combative statements about what they feel. Some of these entries reflect the views of opposing sides in disputes that have been genuinely passionate; this is deliberate. We have not tried to moderate or pretty up these disputes; rather we have attempted to ensure that everyone's sacred cows get gored, impartially. Compromise is not particularly a hackish virtue, but the honest presentation of divergent viewpoints is.
The reader with minimal computer background who finds some references incomprehensibly technical can safely ignore them. We have not felt it either necessary or desirable to eliminate all such; they, too, contribute flavor, and one of this document's major intended audiences — fledgling hackers already partway inside the culture — will benefit from them.
A selection of longer items of hacker folklore and humor is included in Appendix A. The 'outside' reader's attention is particularly directed to the Portrait of J. Random Hacker in Appendix B. The Bibliography, lists some non-technical works which have either influenced or described the hacker culture.
Because hackerdom is an intentional culture (one each individual must choose by action to join), one should not be surprised that the line between description and influence can become more than a little blurred. Earlier versions of the Jargon File have played a central role in spreading hacker language and the culture that goes with it to successively larger populations, and we hope and expect that this one will do likewise.

--------------------------------------------------------------------------------

Chapter 2. Of Slang, Jargon, and Techspeak
Part I. Introduction --------------------------------------------------------------------------------

Chapter 2. Of Slang, Jargon, and Techspeak
Linguists usually refer to informal language as 'slang' and reserve the term 'jargon' for the technical vocabularies of various occupations. However, the ancestor of this collection was called the 'Jargon File', and hacker slang is traditionally 'the jargon'. When talking about the jargon there is therefore no convenient way to distinguish it from what a linguist would call hackers' jargon — the formal vocabulary they learn from textbooks, technical papers, and manuals.

To make a confused situation worse, the line between hacker slang and the vocabulary of technical programming and computer science is fuzzy, and shifts over time. Further, this vocabulary is shared with a wider technical culture of programmers, many of whom are not hackers and do not speak or recognize hackish slang.

Accordingly, this lexicon will try to be as precise as the facts of usage permit about the distinctions among three categories:

slang
informal language from mainstream English or non-technical subcultures (bikers, rock fans, surfers, etc).

jargon
without qualifier, denotes informal 'slangy' language peculiar to or predominantly found among hackers — the subject of this lexicon.

techspeak
the formal technical vocabulary of programming, computer science, electronics, and other fields connected to hacking.

This terminology will be consistently used throughout the remainder of this lexicon.

The jargon/techspeak distinction is the delicate one. A lot of techspeak originated as jargon, and there is a steady continuing uptake of jargon into techspeak. On the other hand, a lot of jargon arises from overgeneralization of techspeak terms (there is more about this in the Jargon Construction section below).

In general, we have considered techspeak any term that communicate primarily by a denotation well established in textbooks, technical dictionaries, or standards documents.

A few obviously techspeak terms (names of operating systems, languages, or documents) are listed when they are tied to hacker folklore that isn't covered in formal sources, or sometimes to convey critical historical background necessary to understand other entries to which they are cross-referenced. Some other techspeak senses of jargon words are listed in order to make the jargon senses clear; where the text does not specify that a straight technical sense is under discussion, these are marked with '[techspeak]' as an etymology. Some entries have a primary sense marked this way, with subsequent jargon meanings explained in terms of it.

We have also tried to indicate (where known) the apparent origins of terms. The results are probably the least reliable information in the lexicon, for several reasons. For one thing, it is well known that many hackish usages have been independently reinvented multiple times, even among the more obscure and intricate neologisms. It often seems that the generative processes underlying hackish jargon formation have an internal logic so powerful as to create substantial parallelism across separate cultures and even in different languages! For another, the networks tend to propagate innovations so quickly that 'first use' is often impossible to pin down. And, finally, compendia like this one alter what they observe by implicitly stamping cultural approval on terms and widening their use.

Despite these problems, the organized collection of jargon-related oral history for the new compilations has enabled us to put to rest quite a number of folk etymologies, place credit where credit is due, and illuminate the early history of many important hackerisms such as kluge, cruft, and foo. We believe specialist lexicographers will find many of the historical notes more than casually instructive.

--------------------------------------------------------------------------------

Chapter 3. Revision History
Part I. Introduction

--------------------------------------------------------------------------------

Chapter 3. Revision History
The original Jargon File was a collection of hacker jargon from technical cultures including the MIT AI Lab, the Stanford AI lab (SAIL), and others of the old ARPANET AI/LISP/PDP-10 communities including Bolt, Beranek and Newman (BBN), Carnegie-Mellon University (CMU), and Worcester Polytechnic Institute (WPI).

The Jargon File (hereafter referred to as 'jargon-1' or 'the File') was begun by Raphael Finkel at Stanford in 1975. From this time until the plug was finally pulled on the SAIL computer in 1991, the File was named AIWORD.RF[UP,DOC] there. Some terms in it date back considerably earlier (frob and some senses of moby, for instance, go back to the Tech Model Railroad Club at MIT and are believed to date at least back to the early 1960s). The revisions of jargon-1 were all unnumbered and may be collectively considered 'Version 1'.

In 1976, Mark Crispin, having seen an announcement about the File on the SAIL computer, FTPed a copy of the File to MIT. He noticed that it was hardly restricted to 'AI words' and so stored the file on his directory as AI:MRC;SAIL JARGON.

The file was quickly renamed JARGON > (the '>' caused versioning under ITS) as a flurry of enhancements were made by Mark Crispin and Guy L. Steele Jr. Unfortunately, amidst all this activity, nobody thought of correcting the term 'jargon' to 'slang' until the compendium had already become widely known as the Jargon File.

Raphael Finkel dropped out of active participation shortly thereafter and Don Woods became the SAIL contact for the File (which was subsequently kept in duplicate at SAIL and MIT, with periodic resynchronizations).

The File expanded by fits and starts until about 1983; Richard Stallman was prominent among the contributors, adding many MIT and ITS-related coinages.

In Spring 1981, a hacker named Charles Spurgeon got a large chunk of the File published in Stewart Brand's CoEvolution Quarterly (issue 29, pages 26—35) with illustrations by Phil Wadler and Guy Steele (including a couple of the Crunchly cartoons). This appears to have been the File's first paper publication.

A late version of jargon-1, expanded with commentary for the mass market, was edited by Guy Steele into a book published in 1983 as The Hacker's Dictionary (Harper & Row CN 1082, ISBN 0-06-091082-8). The other jargon-1 editors (Raphael Finkel, Don Woods, and Mark Crispin) contributed to this revision, as did Richard M. Stallman and Geoff Goodfellow. This book (now out of print) is hereafter referred to as 'Steele-1983' and those six as the Steele-1983 coauthors.

Shortly after the publication of Steele-1983, the File effectively stopped growing and changing. Originally, this was due to a desire to freeze the file temporarily to facilitate the production of Steele-1983, but external conditions caused the 'temporary' freeze to become permanent.

The AI Lab culture had been hit hard in the late 1970s by funding cuts and the resulting administrative decision to use vendor-supported hardware and software instead of homebrew whenever possible. At MIT, most AI work had turned to dedicated LISP Machines. At the same time, the commercialization of AI technology lured some of the AI Lab's best and brightest away to startups along the Route 128 strip in Massachusetts and out West in Silicon Valley. The startups built LISP machines for MIT; the central MIT-AI computer became a TWENEX system rather than a host for the AI hackers' beloved ITS.

The Stanford AI Lab had effectively ceased to exist by 1980, although the SAIL computer continued as a Computer Science Department resource until 1991. Stanford became a major TWENEX site, at one point operating more than a dozen TOPS-20 systems; but by the mid-1980s most of the interesting software work was being done on the emerging BSD Unix standard.

In April 1983, the PDP-10-centered cultures that had nourished the File were dealt a death-blow by the cancellation of the Jupiter project at Digital Equipment Corporation. The File's compilers, already dispersed, moved on to other things. Steele-1983 was partly a monument to what its authors thought was a dying tradition; no one involved realized at the time just how wide its influence was to be.

By the mid-1980s the File's content was dated, but the legend that had grown up around it never quite died out. The book, and softcopies obtained off the ARPANET, circulated even in cultures far removed from MIT and Stanford; the content exerted a strong and continuing influence on hacker language and humor. Even as the advent of the microcomputer and other trends fueled a tremendous expansion of hackerdom, the File (and related materials such as the Some AI Koans in Appendix A) came to be seen as a sort of sacred epic, a hacker-culture Matter of Britain chronicling the heroic exploits of the Knights of the Lab. The pace of change in hackerdom at large accelerated tremendously — but the Jargon File, having passed from living document to icon, remained essentially untouched for seven years.

This revision contains nearly the entire text of a late version of jargon-1 (a few obsolete PDP-10-related entries were dropped after careful consultation with the editors of Steele-1983). It merges in about 80% of the Steele-1983 text, omitting some framing material and a very few entries introduced in Steele-1983 that are now also obsolete.

This new version casts a wider net than the old Jargon File; its aim is to cover not just AI or PDP-10 hacker culture but all the technical computing cultures wherein the true hacker-nature is manifested. More than half of the entries now derive from Usenet and represent jargon now current in the C and Unix communities, but special efforts have been made to collect jargon from other cultures including IBM PC programmers, Amiga fans, Mac enthusiasts, and even the IBM mainframe world.

Eric S. Raymond maintains the new File with assistance from Guy L. Steele Jr. ; these are the persons primarily reflected in the File's editorial 'we', though we take pleasure in acknowledging the special contribution of the other coauthors of Steele-1983. Please email all additions, corrections, and correspondence relating to the Jargon File to Eric.

(Warning: other email addresses and URLs appear in this file but are not guaranteed to be correct after date of publication. Don't email us if an attempt to reach someone bounces — we have no magic way of checking addresses or looking up people. If a web reference goes stale, try a Google or Alta Vista search for relevant phrases.

Please try to review a recent copy of the on-line document before submitting entries; it is available on the Web. It will often contain new material not recorded in the latest paper snapshot that could save you some typing. It also includes some submission guidelines not reproduced here.

The 2.9.6 version became the main text of The New Hacker's Dictionary, by Eric Raymond (ed.), MIT Press 1991, ISBN 0-262-68069-6.

The 3.0.0 version was published in August 1993 as the second edition of The New Hacker's Dictionary, again from MIT Press (ISBN 0-262-18154-1).

The 4.0.0 version was published in September 1996 as the third edition of The New Hacker's Dictionary from MIT Press (ISBN 0-262-68092-0).

The maintainers are committed to updating the on-line version of the Jargon File through and beyond paper publication, and will continue to make it available to archives and public-access sites as a trust of the hacker community.

Here is a chronology of major revisions:

Version Date Lines Words Characters Entries Comments
2.1.1 Jun 12 1990 5485 42842 278958 790 The Jargon File comes alive again after a seven-year hiatus. Reorganization and massive additions were by Eric S. Raymond, approved by Guy Steele. Many items of UNIX, C, USENET, and microcomputer-based jargon were added at that time.

2.1.5 Nov 28 1990 6028 46946 307510 866 Changes and additions by ESR in response to numerous USENET submissions and comment from the First Edition co-authors. The Bibliography (Appendix C) was also appended.

2.2.1 Dec 15 1990 9394 75954 490501 1046 Most of the contents of the 1983 paper edition edited by Guy Steele was merged in. Many more USENET submissions added, including the International Style and the material on Commonwealth Hackish.

2.3.1 Jan 03 1991 10728 85070 558261 1138 The great format change — case is no longer smashed in lexicon keys and cross-references. A very few entries from jargon-1 which were basically straight techspeak were deleted; this enabled the rest of Appendix B (created in 2.1.1) to be merged back into main text and the appendix replaced with the Portrait of J. Random Hacker. More USENET submissions were added.

2.4.1 Jan 14 1991 12362 97819 642899 1239 The Story of Mel and many more USENET submissions merged in. More material on hackish writing habits added. Numerous typo fixes.

2.6.1 Feb 12 1991 15011 118277 774942 1484 Second great format change; no more <> around headwords or references. Merged in results of serious copy-editing passes by Guy Steele, Mark Brader. Still more entries added.

2.7.1 Mar 01 1991 16087 126885 831872 1533 New section on slang/jargon/techspeak added. Results of Guy's second edit pass merged in.

2.8.1 Mar 22 1991 17154 135647 888333 1602 Material from the TMRC Dictionary and MRC's editing pass merged in.

2.9.6 Aug 16 1991 18952 148629 975551 1702 Corresponds to reproduction copy for book.

2.9.8 Jan 01 1992 19509 153108 1006023 1760 First public release since the book, including over fifty new entries and numerous corrections/additions to old ones. Packaged with version 1.1 of vh(1) hypertext reader.

2.9.9 Apr 01 1992 20298 159651 1048909 1821 Folded in XEROX PARC lexicon.

2.9.10 Jul 01 1992 21349 168330 1106991 1891 lots of new historical material.

2.9.11 Jan 01 1993 21725 171169 1125880 1922 Lots of new historical material.

2.9.12 May 10 1993 22238 175114 1152467 1946 A few new entries & changes, marginal MUD/IRC slang and some borderline techspeak removed, all in preparation for 2nd Edition of TNHD.

3.0.0 Jul 27 1993 22548 177520 1169372 1961 Manuscript freeze for 2nd edition of TNHD.

3.1.0 Oct 15 1994 23197 181001 1193818 1990 Interim release to test WWW conversion.

3.2.0 Mar 15 1995 23822 185961 1226358 2031 Spring 1995 update.

3.3.0 Jan 20 1996 24055 187957 1239604 2045 Winter 1996 update.

3.3.1 Jan 25 1996 24147 188728 1244554 2050 Copy-corrected improvement on 3.3.0 shipped to MIT Press as a step towards TNHD III.

4.0.0 Jul 25 1996 24801 193697 1281402 2067 The actual TNHD III version after copy-edit

4.1.0 8 Apr 1999 25777 206825 1359992 2217 The Jargon File rides again after three years.

4.2.0 31 Jan 2000 26598 214639 1412243 2267 Fix processing of URLs.

4.3.0 30 Apr 2001 27805 224978 1480215 2319 Special edition in honor of the first implementation of RFC 1149. Also cleaned up a number of obsolete entries.

4.4.0 10 May 2003 32004 230012 1707139 2290 XML-Docbook format conversion. Serious pruning of old slang, nearly 100 entries failed the Google test and were removed.

4.4.1 13 May 2003 37157 234687 1618716 2290 XML-Docbook format fixes.

4.4.2 22 May 2003 32629 227852 1555125 2290 Fix filename collisions and other small problems.

4.4.3 15 Jul 2003 37363 235135 1629667 2293 Fix some stylesheet problems leading to missing links.

4.4.4 14 Aug 2003 37392 235271 1630579 2295 Corrected build machinery; we can make RPMS now.

4.4.5 4 Oct 2003 37482 235858 1634767 2299 Minor updates. Four new entries and a better original-bug picture.

4.4.6 25 Oct 2003 37560 236406 1638454 2302 Added glider illustration. Amended FUD entry pursuent to SCO's attempt to abuse it.

4.4.7 29 Dec 2003 37666 237206 1643609 2307 Winter 2003 update.

Version numbering: Version numbers should be read as major.minor.revision. Major version 1 is reserved for the 'old' (ITS) Jargon File, jargon-1. Major version 2 encompasses revisions by ESR (Eric S. Raymond) with assistance from GLS (Guy L. Steele, Jr.) leading up to and including the second paper edition. From now on, major version number N.00 will probably correspond to the Nth paper edition. Usually later versions will either completely supersede or incorporate earlier versions, so there is generally no point in keeping old versions around.

Our thanks to the coauthors of Steele-1983 for oversight and assistance, and to the hundreds of Usenetters (too many to name here) who contributed entries and encouragement. More thanks go to several of the old-timers on the Usenet group alt.folklore.computers, who contributed much useful commentary and many corrections and valuable historical perspective: Joseph M. Newcomer , Bernie Cosell , Earl Boebert , and Joe Morris .

We were fortunate enough to have the aid of some accomplished linguists. David Stampe and Charles Hoequist contributed valuable criticism; Joe Keane helped us improve the pronunciation guides.

A few bits of this text quote previous works. We are indebted to Brian A. LaMacchia for obtaining permission for us to use material from the TMRC Dictionary; also, Don Libes contributed some appropriate material from his excellent book Life With UNIX. We thank Per Lindberg , author of the remarkable Swedish-language 'zine Hackerbladet, for bringing FOO! comics to our attention and smuggling one of the IBM hacker underground's own baby jargon files out to us. Thanks also to Maarten Litmaath for generously allowing the inclusion of the ASCII pronunciation guide he formerly maintained. And our gratitude to Marc Weiser of XEROX PARC for securing us permission to quote from PARC's own jargon lexicon and shipping us a copy.

It is a particular pleasure to acknowledge the major contributions of Mark Brader and Steve Summit to the File and Dictionary; they have read and reread many drafts, checked facts, caught typos, submitted an amazing number of thoughtful comments, and done yeoman service in catching typos and minor usage bobbles. Their rare combination of enthusiasm, persistence, wide-ranging technical knowledge, and precisionism in matters of language has been of invaluable help. Indeed, the sustained volume and quality of Mr. Brader's input over a decade and several different editions has only allowed him to escape co-editor credit by the slimmest of margins.

Finally, George V. Reilly helped with TeX arcana and painstakingly proofread some 2.7 and 2.8 versions, and Eric Tiedemann contributed sage advice throughout on rhetoric, amphigory, and philosophunculism.

--------------------------------------------------------------------------------

Chapter 4. Jargon Construction
Part I. Introduction --------------------------------------------------------------------------------

Chapter 4. Jargon Construction
Table of Contents

Verb Doubling
Soundalike Slang
The -P Convention
Overgeneralization
Spoken inarticulations
Anthropomorphization
Comparatives
There are some standard methods of jargonification that became established quite early (i.e., before 1970), spreading from such sources as the Tech Model Railroad Club, the PDP-1 SPACEWAR hackers, and John McCarthy's original crew of LISPers. These include verb doubling, soundalike slang, the '-P' convention, overgeneralization, spoken inarticulations, and anthropomorphization. Each is discussed below. We also cover the standard comparatives for design quality.

Of these six, verb doubling, overgeneralization, anthropomorphization, and (especially) spoken inarticulations have become quite general; but soundalike slang is still largely confined to MIT and other large universities, and the '-P' convention is found only where LISPers flourish.

--------------------------------------------------------------------------------

Verb Doubling
Chapter 4. Jargon Construction --------------------------------------------------------------------------------

Verb Doubling
A standard construction in English is to double a verb and use it as an exclamation, such as "Bang, bang!" or "Quack, quack!". Most of these are names for noises. Hackers also double verbs as a concise, sometimes sarcastic comment on what the implied subject does. Also, a doubled verb is often used to terminate a conversation, in the process remarking on the current state of affairs or what the speaker intends to do next. Typical examples involve win, lose, hack, flame, barf, chomp:

"The disk heads just crashed." "Lose, lose."

"Mostly he talked about his latest crock. Flame, flame."

"Boy, what a bagbiter! Chomp, chomp!

Some verb-doubled constructions have special meanings not immediately obvious from the verb. These have their own listings in the lexicon.

The Usenet culture has one tripling convention unrelated to this; the names of 'joke' topic groups often have a tripled last element. The first and paradigmatic example was alt.swedish.chef.bork.bork.bork (a Muppet Show reference); other infamous examples have included:

alt.french.captain.borg.borg.borg

alt.wesley.crusher.die.die.die

comp.unix.internals.system.calls.brk.brk.brk

sci.physics.edward.teller.boom.boom.boom

alt.sadistic.dentists.drill.drill.drill

These two traditions fuse in the newsgroup alt.adjective.noun.verb.verb.verb, devoted to humor based on deliberately confounding parts of speech. Several observers have noted that the contents of this group is excellently representative of the peculiarities of hacker humor.

--------------------------------------------------------------------------------

Soundalike Slang
Chapter 4. Jargon Construction

--------------------------------------------------------------------------------

Soundalike Slang
Hackers will often make rhymes or puns in order to convert an ordinary word or phrase into something more interesting. It is considered particularly flavorful if the phrase is bent so as to include some other jargon word; thus the computer hobbyist magazine Dr. Dobb's Journal is almost always referred to among hackers as 'Dr. Frob's Journal' or simply 'Dr. Frob's'. Terms of this kind that have been in fairly wide use include names for newspapers:

Boston Herald → Horrid (or Harried)

Boston Globe → Boston Glob

Houston (or San Francisco) Chronicle → the Crocknicle (or the Comical)

New York Times → New York Slime

Wall Street Journal → Wall Street Urinal

However, terms like these are often made up on the spur of the moment. Standard examples include:

Data General → Dirty Genitals

IBM 360 → IBM Three-Sickly

Government Property — Do Not Duplicate (on keys) → Government Duplicity — Do Not Propagate

for historical reasons → for hysterical raisins

Margaret Jacks Hall (the CS building at Stanford) → Marginal Hacks Hall

Microsoft → Microsloth

Internet Explorer → Internet Exploiter

FrontPage → AffrontPage

VB.NET → VB Nyet

Lotus Notes → Lotus Bloats

Microsoft Outlook → Microsoft Outhouse

Linux → Linsux

FreeBSD → FreeLSD

C# → C Flat

This is not really similar to the Cockney rhyming slang it has been compared to in the past, because Cockney substitutions are opaque whereas hacker punning jargon is intentionally transparent.

--------------------------------------------------------------------------------

The -P Convention
Chapter 4. Jargon Construction

--------------------------------------------------------------------------------

The -P Convention
Turning a word into a question by appending the syllable 'P'; from the LISP convention of appending the letter 'P' to denote a predicate (a boolean-valued function). The question should expect a yes/no answer, though it needn't. (See T and NIL.)

At dinnertime:
Q: "Foodp?"
A: "Yeah, I'm pretty hungry." or "T!"

At any time:
Q: "State-of-the-world-P?"
A: (Straight) "I'm about to go home."
A: (Humorous) "Yes, the world has a state."

On the phone to Florida:
Q: "State-p Florida?"
A: "Been reading JARGON.TXT again, eh?"

[Once, when we were at a Chinese restaurant, Bill Gosper wanted to know whether someone would like to share with him a two-person-sized bowl of soup. His inquiry was: "Split-p soup?" — GLS]

--------------------------------------------------------------------------------

Overgeneralization
Chapter 4. Jargon Construction

--------------------------------------------------------------------------------

Overgeneralization
A very conspicuous feature of jargon is the frequency with which techspeak items such as names of program tools, command language primitives, and even assembler opcodes are applied to contexts outside of computing wherever hackers find amusing analogies to them. Thus (to cite one of the best-known examples) Unix hackers often grep for things rather than searching for them. Many of the lexicon entries are generalizations of exactly this kind.

Hackers enjoy overgeneralization on the grammatical level as well. Many hackers love to take various words and add the wrong endings to them to make nouns and verbs, often by extending a standard rule to nonuniform cases (or vice versa). For example, because porous → porosity and generous → generosity, hackers happily generalize:

mysterious → mysteriosity

ferrous → ferrosity

obvious → obviosity

dubious → dubiosity

Another class of common construction uses the suffix '-itude' to abstract a quality from just about any adjective or noun. This usage arises especially in cases where mainstream English would perform the same abstraction through '-iness' or '-ingness'. Thus:

win → winnitude (a common exclamation)

loss → lossitude

cruft → cruftitude

lame → lameitude

Some hackers cheerfully reverse this transformation; they argue, for example, that the horizontal degree lines on a globe ought to be called 'lats' — after all, they're measuring latitude!

Also, note that all nouns can be verbed. E.g.: "All nouns can be verbed", "I'll mouse it up", "Hang on while I clipboard it over", "I'm grepping the files". English as a whole is already heading in this direction (towards pure-positional grammar like Chinese); hackers are simply a bit ahead of the curve.

The suffix "-full" can also be applied in generalized and fanciful ways, as in "As soon as you have more than one cachefull of data, the system starts thrashing," or "As soon as I have more than one headfull of ideas, I start writing it all down." A common use is "screenfull", meaning the amount of text that will fit on one screen, usually in text mode where you have no choice as to character size. Another common form is "bufferfull".

However, hackers avoid the unimaginative verb-making techniques characteristic of marketroids, bean-counters, and the Pentagon; a hacker would never, for example, 'productize', 'prioritize', or 'securitize' things. Hackers have a strong aversion to bureaucratic bafflegab and regard those who use it with contempt.

Similarly, all verbs can be nouned. This is only a slight overgeneralization in modern English; in hackish, however, it is good form to mark them in some standard nonstandard way. Thus:

win → winnitude, winnage

disgust → disgustitude

hack → hackification

Further, note the prevalence of certain kinds of nonstandard plural forms. Some of these go back quite a ways; the TMRC Dictionary includes an entry which implies that the plural of 'mouse' is meeces, and notes that the defined plural of 'caboose' is 'cabeese'. This latter has apparently been standard (or at least a standard joke) among railfans (railroad enthusiasts) for many years

On a similarly Anglo-Saxon note, almost anything ending in 'x' may form plurals in '-xen' (see VAXen and boxen in the main text). Even words ending in phonetic /k/ alone are sometimes treated this way; e.g., 'soxen' for a bunch of socks. Other funny plurals are the Hebrew-style 'frobbotzim' for the plural of 'frobbozz' (see frobnitz) and 'Unices' and 'Twenices' (rather than 'Unixes' and 'Twenexes'; see Unix, TWENEX in main text). But note that 'Twenexen' was never used, and 'Unixen' was seldom sighted in the wild until the year 2000, thirty years after it might logically have come into use; it has been suggested that this is because '-ix' and '-ex' are Latin singular endings that attract a Latinate plural. Among Perl hackers it is reported that 'comma' and 'semicolon' pluralize as 'commata' and 'semicola' respectively. Finally, it has been suggested to general approval that the plural of 'mongoose' ought to be 'polygoose'.

The pattern here, as with other hackish grammatical quirks, is generalization of an inflectional rule that in English is either an import or a fossil (such as the Hebrew plural ending '-im', or the Anglo-Saxon plural suffix '-en') to cases where it isn't normally considered to apply.

This is not 'poor grammar', as hackers are generally quite well aware of what they are doing when they distort the language. It is grammatical creativity, a form of playfulness. It is done not to impress but to amuse, and never at the expense of clarity.

--------------------------------------------------------------------------------

Spoken inarticulations
Chapter 4. Jargon Construction

--------------------------------------------------------------------------------

Spoken inarticulations
Words such as 'mumble', 'sigh', and 'groan' are spoken in places where their referent might more naturally be used. It has been suggested that this usage derives from the impossibility of representing such noises on a comm link or in electronic mail, MUDs, and IRC channels (interestingly, the same sorts of constructions have been showing up with increasing frequency in comic strips). Another expression sometimes heard is "Complain!", meaning "I have a complaint!"

--------------------------------------------------------------------------------

Anthropomorphization
Chapter 4. Jargon Construction

--------------------------------------------------------------------------------

Anthropomorphization
Semantically, one rich source of jargon constructions is the hackish tendency to anthropomorphize hardware and software. English purists and academic computer scientists frequently look down on others for anthropomorphizing hardware and software, considering this sort of behavior to be characteristic of naive misunderstanding. But most hackers anthropomorphize freely, frequently describing program behavior in terms of wants and desires.

Thus it is common to hear hardware or software talked about as though it has homunculi talking to each other inside it, with intentions and desires. Thus, one hears "The protocol handler got confused", or that programs "are trying" to do things, or one may say of a routine that "its goal in life is to X". Or: "You can't run those two cards on the same bus; they fight over interrupt 9."

One even hears explanations like "... and its poor little brain couldn't understand X, and it died." Sometimes modelling things this way actually seems to make them easier to understand, perhaps because it's instinctively natural to think of anything with a really complex behavioral repertoire as 'like a person' rather than 'like a thing'.

At first glance, to anyone who understands how these programs actually work, this seems like an absurdity. As hackers are among the people who know best how these phenomena work, it seems odd that they would use language that seems to ascribe consciousness to them. The mind-set behind this tendency thus demands examination.

The key to understanding this kind of usage is that it isn't done in a naive way; hackers don't personalize their stuff in the sense of feeling empathy with it, nor do they mystically believe that the things they work on every day are 'alive'. To the contrary: hackers who anthropomorphize are expressing not a vitalistic view of program behavior but a mechanistic view of human behavior.

Almost all hackers subscribe to the mechanistic, materialistic ontology of science (this is in practice true even of most of the minority with contrary religious theories). In this view, people are biological machines — consciousness is an interesting and valuable epiphenomenon, but mind is implemented in machinery which is not fundamentally different in information-processing capacity from computers.

Hackers tend to take this a step further and argue that the difference between a substrate of CHON atoms and water and a substrate of silicon and metal is a relatively unimportant one; what matters, what makes a thing 'alive', is information and richness of pattern. This is animism from the flip side; it implies that humans and computers and dolphins and rocks are all machines exhibiting a continuum of modes of 'consciousness' according to their information-processing capacity.

Because hackers accept that a human machine can have intentions, it is therefore easy for them to ascribe consciousness and intention to other complex patterned systems such as computers. If consciousness is mechanical, it is neither more or less absurd to say that "The program wants to go into an infinite loop" than it is to say that "I want to go eat some chocolate" — and even defensible to say that "The stone, once dropped, wants to move towards the center of the earth".

This viewpoint has respectable company in academic philosophy. Daniel Dennett organizes explanations of behavior using three stances: the "physical stance" (thing-to-be-explained as a physical object), the "design stance" (thing-to-be-explained as an artifact), and the "intentional stance" (thing-to-be-explained as an agent with desires and intentions). Which stances are appropriate is a matter not of abstract truth but of utility. Hackers typically view simple programs from the design stance, but more complex ones are often modelled using the intentional stance.

It has also been argued that the anthropomorphization of software and hardware reflects a blurring of the boundary between the programmer and his artifacts — the human qualities belong to the programmer and the code merely expresses these qualities as his/her proxy. On this view, a hacker saying a piece of code 'got confused' is really saying that he (or she) was confused about exactly what he wanted the computer to do, the code naturally incorporated this confusion, and the code expressed the programmer's confusion when executed by crashing or otherwise misbehaving.

Note that by displacing from "I got confused" to "It got confused", the programmer is not avoiding responsibility, but rather getting some analytical distance in order to be able to consider the bug dispassionately.

It has also been suggested that anthropomorphizing complex systems is actually an expression of humility, a way of acknowleging that simple rules we do understand (or that we invented) can lead to emergent behavioral complexities that we don't completely understand.

All three explanations accurately model hacker psychology, and should be considered complementary rather than competing.

--------------------------------------------------------------------------------

Comparatives
Chapter 4. Jargon Construction

--------------------------------------------------------------------------------

Comparatives
Finally, note that many words in hacker jargon have to be understood as members of sets of comparatives. This is especially true of the adjectives and nouns used to describe the beauty and functional quality of code. Here is an approximately correct spectrum:

monstrosity brain-damage screw bug lose misfeature crock kluge hack win feature elegance perfection

The last is spoken of as a mythical absolute, approximated but never actually attained. Another similar scale is used for describing the reliability of software:

broken flaky dodgy fragile brittle solid robust bulletproof armor-plated

Note, however, that 'dodgy' is primarily Commonwealth Hackish (it is rare in the U.S., where 'squirrelly' may be more common) and may change places with 'flaky' for some speakers.

Coinages for describing lossage seem to call forth the very finest in hackish linguistic inventiveness; it has been truly said that hackers have even more words for equipment failures than Yiddish has for obnoxious people.

--------------------------------------------------------------------------------

Chapter 5. Hacker Writing Style
Part I. Introduction

--------------------------------------------------------------------------------

Chapter 5. Hacker Writing Style
We've already seen that hackers often coin jargon by overgeneralizing grammatical rules. This is one aspect of a more general fondness for form-versus-content language jokes that shows up particularly in hackish writing. One correspondent reports that he consistently misspells 'wrong' as 'worng'. Others have been known to criticize glitches in Jargon File drafts by observing (in the mode of Douglas Hofstadter) "This sentence no verb", or "Too repetetetive", or "Bad speling", or "Incorrectspa cing." Similarly, intentional spoonerisms are often made of phrases relating to confusion or things that are confusing; 'dain bramage' for 'brain damage' is perhaps the most common (similarly, a hacker would be likely to write "Excuse me, I'm cixelsyd today", rather than "I'm dyslexic today"). This sort of thing is quite common and is enjoyed by all concerned.

Hackers tend to use quotes as balanced delimiters like parentheses, much to the dismay of American editors. Thus, if "Jim is going" is a phrase, and so are "Bill runs" and "Spock groks", then hackers generally prefer to write: "Jim is going", "Bill runs", and "Spock groks". This is incorrect according to standard American usage (which would put the continuation commas and the final period inside the string quotes); however, it is counter-intuitive to hackers to mutilate literal strings with characters that don't belong in them. Given the sorts of examples that can come up in discussions of programming, American-style quoting can even be grossly misleading. When communicating command lines or small pieces of code, extra characters can be a real pain in the neck.

Consider, for example, a sentence in a vi tutorial that looks like this:

Then delete a line from the file by typing "dd".

Standard usage would make this

Then delete a line from the file by typing "dd."

but that would be very bad — because the reader would be prone to type the string d-d-dot, and it happens that in vi(1), dot repeats the last command accepted. The net result would be to delete two lines!

The Jargon File follows hackish usage throughout.

Interestingly, a similar style is now preferred practice in Great Britain, though the older style (which became established for typographical reasons having to do with the aesthetics of comma and quotes in typeset text) is still accepted there. Hart's Rules and the Oxford Dictionary for Writers and Editors call the hacker-like style 'new' or 'logical' quoting. This returns British English to the style many other languages (including Spanish, French, Italian, Catalan, and German) have been using all along.

Another hacker habit is a tendency to distinguish between 'scare' quotes and 'speech' quotes; that is, to use British-style single quotes for marking and reserve American-style double quotes for actual reports of speech or text included from elsewhere. Interestingly, some authorities describe this as correct general usage, but mainstream American English has gone to using double-quotes indiscriminately enough that hacker usage appears marked [and, in fact, I thought this was a personal quirk of mine until I checked with Usenet —ESR] One further permutation that is definitely not standard is a hackish tendency to do marking quotes by using apostrophes (single quotes) in pairs; that is, 'like this'. This is modelled on string and character literal syntax in some programming languages (reinforced by the fact that many character-only terminals display the apostrophe in typewriter style, as a vertical single quote).

One quirk that shows up frequently in the email style of Unix hackers in particular is a tendency for some things that are normally all-lowercase (including usernames and the names of commands and C routines) to remain uncapitalized even when they occur at the beginning of sentences. It is clear that, for many hackers, the case of such identifiers becomes a part of their internal representation (the 'spelling') and cannot be overridden without mental effort (an appropriate reflex because Unix and C both distinguish cases and confusing them can lead to lossage). A way of escaping this dilemma is simply to avoid using these constructions at the beginning of sentences.

There seems to be a meta-rule behind these nonstandard hackerisms to the effect that precision of expression is more important than conformance to traditional rules; where the latter create ambiguity or lose information they can be discarded without a second thought. It is notable in this respect that other hackish inventions (for example, in vocabulary) also tend to carry very precise shades of meaning even when constructed to appear slangy and loose. In fact, to a hacker, the contrast between 'loose' form and 'tight' content in jargon is a substantial part of its humor!

Hackers have also developed a number of punctuation and emphasis conventions adapted to single-font all-ASCII communications links, and these are occasionally carried over into written documents even when normal means of font changes, underlining, and the like are available.

One of these is that TEXT IN ALL CAPS IS INTERPRETED AS 'LOUD', and this becomes such an ingrained synesthetic reflex that a person who goes to caps-lock while in talk mode may be asked to "stop shouting, please, you're hurting my ears!".

Also, it is common to use bracketing with unusual characters to signify emphasis. The asterisk is most common, as in "What the *hell*?" even though this interferes with the common use of the asterisk suffix as a footnote mark. The underscore is also common, suggesting underlining (this is particularly common with book titles; for example, "It is often alleged that Joe Haldeman wrote _The_Forever_War_ as a rebuttal to Robert Heinlein's earlier novel of the future military, _Starship_Troopers_."). Other forms exemplified by "=hell=", "\hell/", or "/hell/" are occasionally seen (it's claimed that in the last example the first slash pushes the letters over to the right to make them italic, and the second keeps them from falling over). On FidoNet, you might see #bright# and ^dark^ text, which was actually interpreted by some reader software. Finally, words may also be emphasized L I K E T H I S, or by a series of carets (^) under them on the next line of the text.

There is a semantic difference between *emphasis like this* (which emphasizes the phrase as a whole), and *emphasis* *like* *this* (which suggests the writer speaking very slowly and distinctly, as if to a very young child or a mentally impaired person). Bracketing a word with the '*' character may also indicate that the writer wishes readers to consider that an action is taking place or that a sound is being made. Examples: *bang*, *hic*, *ring*, *grin*, *kick*, *stomp*, *mumble*.

One might also see the above sound effects as , , , , , , . This use of angle brackets to mark their contents originally derives from conventions used in BNF, but since about 1993 it has been reinforced by the HTML markup used on the World Wide Web.

Angle-bracket enclosure is also used to indicate that a term stands for some random member of a larger class (this is straight from BNF). Examples like the following are common:

So this walks into a bar one day...

There is also an accepted convention for 'writing under erasure'; the text>

Be nice to this fool^H^H^H^Hgentleman, he's visiting from corporate HQ.

reads roughly as "Be nice to this fool, er, gentleman...", with irony emphasized. The digraph ^H is often used as a print representation for a backspace, and was actually very visible on old-style printing terminals. As the text was being composed the characters would be echoed and printed immediately, and when a correction was made the backspace keystrokes would be echoed with the string '^H'. Of course, the final composed text would have no trace of the backspace characters (or the original erroneous text).

Accidental writing under erasure occurs when using the Unix talk program to chat interactively to another user. On a PC-style keyboard most users instinctively press the backspace key to delete mistakes, but this may not achieve the desired effect, and merely displays a ^H symbol. The user typically presses backspace a few times before their brain realises the problem — especially likely if the user is a touch-typist — and since each character is transmitted as soon as it is typed, Freudian slips and other inadvertent admissions are (barring network delays) clearly visible for the other user to see.

Deliberate use of ^H for writing under erasure parallels (and may have been influenced by) the ironic use of 'slashouts' in science-fiction fanzines.

A related habit uses editor commands to signify corrections to previous text. This custom faded in email as more mailers got good editing capabilities, only to take on new life on IRCs and other line-based chat systems.

charlie: I've seen that term used on alt.foobar often.lisa: Send it to Erik for the File.lisa: Oops...s/Erik/Eric/.

The s/Erik/Eric/ says "change Erik to Eric in the preceding". This syntax is borrowed from the Unix editing tools ed and sed, but is widely recognized by non-Unix hackers as well.

In a formula, * signifies multiplication but two asterisks in a row are a shorthand for exponentiation (this derives from FORTRAN, and is also used in Ada). Thus, one might write 2 ** 8 = 256.

Another notation for exponentiation one sees more frequently uses the caret (^, ASCII 1011110); one might write instead 2^8 = 256. This goes all the way back to Algol-60, which used the archaic ASCII 'up-arrow' that later became the caret; this was picked up by Kemeny and Kurtz's original BASIC, which in turn influenced the design of the bc(1) and dc(1) Unix tools, which have probably done most to reinforce the convention on Usenet. (TeX math mode also uses ^ for exponention.) The notation is mildly confusing to C programmers, because ^ means bitwise exclusive-or in C. Despite this, it was favored 3:1 over ** in a late-1990 snapshot of Usenet. It is used consistently in this lexicon.

In on-line exchanges, hackers tend to use decimal forms or improper fractions ('3.5' or '7/2') rather than 'typewriter style' mixed fractions ('3-1/2'). The major motive here is probably that the former are more readable in a monospaced font, together with a desire to avoid the risk that the latter might be read as 'three minus one-half'. The decimal form is definitely preferred for fractions with a terminating decimal representation; there may be some cultural influence here from the high status of scientific notation.

Another on-line convention, used especially for very large or very small numbers, is taken from C (which derived it from FORTRAN). This is a form of 'scientific notation' using 'e' to replace '*10^'; for example, one year is about 3e7 (that is, 3 × 10 7) seconds long.

The tilde (~) is commonly used in a quantifying sense of 'approximately'; that is, ~50 means 'about fifty'.

On Usenet and in the MUD world, common C boolean, logical, and relational operators such as |, &, ||, &&, !, ==, !=, >, <, >=, and <= are often combined with English. The Pascal not-equals, <>, is also recognized, and occasionally one sees /= for not-equals (from Ada, Common Lisp, and Fortran 90). The use of prefix '!' as a loose synonym for 'not-' or 'no-' is particularly common; thus, '!clue' is read 'no-clue' or 'clueless'.

A related practice borrows syntax from preferred programming languages to express ideas in a natural-language text. For example, one might see the following:

In J. R. Hacker wrote:--== Frank Foonly (Fubarco Systems)

In the above, the #ifdef/#endif pair is a conditional compilation syntax from C; here, it implies that the text between (which is a flame) should be evaluated only if you have turned on (or defined on) the switch FLAME. The #include at the end is C for "include standard disclaimer here"; the 'standard disclaimer' is understood to read, roughly, "These are my personal opinions and not to be construed as the official position of my employer."

The top section in the example, with < at the left margin, is an example of an inclusion convention we'll discuss below.

More recently, following on the huge popularity of the World Wide Web, pseudo-HTML markup has become popular for similar purposes:

Your mother was a hamster and your father smelt of elderberries!

You'll even see this with an HTML-style attribute modifier:

You seem well-suited for a career in government.

Another recent (late 1990s) construction now common on Usenet seems to be borrowed from Unix shell syntax or Perl. It consists of using a dollar sign before an uppercased form of a word or acronym to suggest any random member of the class indicated by the word. Thus: '$PHB' means "any random member of the class 'Pointy-Haired Boss'".

Hackers also mix letters and numbers more freely than in mainstream usage. In particular, it is good hackish style to write a digit sequence where you intend the reader to understand the text string that names that number in English. So, hackers prefer to write '1970s' rather than 'nineteen-seventies' or '1970's' (the latter looks like a possessive).

It should also be noted that hackers exhibit much less reluctance to use multiply-nested parentheses than is normal in English. Part of this is almost certainly due to influence from LISP (which uses deeply nested parentheses (like this (see?)) in its syntax a lot), but it has also been suggested that a more basic hacker trait of enjoying playing with complexity and pushing systems to their limits is in operation.

Finally, it is worth mentioning that many studies of on-line communication have shown that electronic links have a de-inhibiting effect on people. Deprived of the body-language cues through which emotional state is expressed, people tend to forget everything about other parties except what is presented over that ASCII link. This has both good and bad effects. A good one is that it encourages honesty and tends to break down hierarchical authority relationships; a bad one is that it may encourage depersonalization and gratuitous rudeness. Perhaps in response to this, experienced netters often display a sort of conscious formal politesse in their writing that has passed out of fashion in other spoken and written media (for example, the phrase "Well said, sir!" is not uncommon).

Many introverted hackers who are next to inarticulate in person communicate with considerable fluency over the net, perhaps precisely because they can forget on an unconscious level that they are dealing with people and thus don't feel stressed and anxious as they would face to face.

Though it is considered gauche to publicly criticize posters for poor spelling or grammar, the network places a premium on literacy and clarity of expression. It may well be that future historians of literature will see in it a revival of the great tradition of personal letters as art.

--------------------------------------------------------------------------------

Chapter 6. Email Quotes and Inclusion Conventions
Part I. Introduction

--------------------------------------------------------------------------------

Chapter 6. Email Quotes and Inclusion Conventions
One area where conventions for on-line writing are still in some flux is the marking of included material from earlier messages — what would be called 'block quotations' in ordinary English. From the usual typographic convention employed for these (smaller font at an extra indent), there derived a practice of included text being indented by one ASCII TAB (0001001) character, which under Unix and many other environments gives the appearance of an 8-space indent.

Early mail and netnews readers had no facility for including messages this way, so people had to paste in copy manually. BSD Mail(1) was the first message agent to support inclusion, and early Usenetters emulated its style. But the TAB character tended to push included text too far to the right (especially in multiply nested inclusions), leading to ugly wraparounds. After a brief period of confusion (during which an inclusion leader consisting of three or four spaces became established in EMACS and a few mailers), the use of leading > or > became standard, perhaps owing to its use in ed(1) to display tabs (alternatively, it may derive from the > that some early Unix mailers used to quote lines starting with "From" in text, so they wouldn't look like the beginnings of new message headers). Inclusions within inclusions keep their > leaders, so the 'nesting level' of a quotation is visually apparent.

The practice of including text from the parent article when posting a followup helped solve what had been a major nuisance on Usenet: the fact that articles do not arrive at different sites in the same order. Careless posters used to post articles that would begin with, or even consist entirely of, "No, that's wrong" or "I agree" or the like. It was hard to see who was responding to what. Consequently, around 1984, new news-posting software evolved a facility to automatically include the text of a previous article, marked with "> " or whatever the poster chose. The poster was expected to delete all but the relevant lines. The result has been that, now, careless posters post articles containing the entire text of a preceding article, followed only by "No, that's wrong" or "I agree".

Many people feel that this cure is worse than the original disease, and there soon appeared newsreader software designed to let the reader skip over included text if desired. Today, some posting software rejects articles containing too high a proportion of lines beginning with '>' — but this too has led to undesirable workarounds, such as the deliberate inclusion of zero-content filler lines which aren't quoted and thus pull the message below the rejection threshold.

Inclusion practice is still evolving, and disputes over the 'correct' inclusion style occasionally lead to holy wars.

Most netters view an inclusion as a promise that comment on it will immediately follow. The preferred, conversational style looks like this,

> relevant excerpt 1
response to excerpt
> relevant excerpt 2
response to excerpt
> relevant excerpt 3
response to excerpt

or for short messages like this:

> entire message
response to message

Thanks to poor design of some PC-based mail agents (notably Microsoft Outlook and Outlook Express), one will occasionally see the entire quoted message after the response, like this

response to message
> entire message

but this practice is strongly deprecated.

Though > remains the standard inclusion leader, | is occasionally used for extended quotations where original variations in indentation are being retained (one mailer even combines these and uses |>). One also sees different styles of quoting a number of authors in the same message: one (deprecated because it loses information) uses a leader of > for everyone, another (the most common) is > > > > , > > > , etc. (or >>>> , >>>, etc., depending on line length and nesting depth) reflecting the original order of messages, and yet another is to use a different citation leader for each author, say > , : , | , @ (preserving nesting so that the inclusion order of messages is still apparent, or tagging the inclusions with authors' names). Yet another style is to use each poster's initials (or login name) as a citation leader for that poster.

Occasionally one sees a # leader used for quotations from authoritative sources such as standards documents; the intended allusion is to the root prompt (the special Unix command prompt issued when one is running as the privileged super-user).

--------------------------------------------------------------------------------

Chapter 7. Hacker Speech Style
Part I. Introduction

--------------------------------------------------------------------------------

Chapter 7. Hacker Speech Style
Hackish speech generally features extremely precise diction, careful word choice, a relatively large working vocabulary, and relatively little use of contractions or street slang. Dry humor, irony, puns, and a mildly flippant attitude are highly valued — but an underlying seriousness and intelligence are essential. One should use just enough jargon to communicate precisely and identify oneself as a member of the culture; overuse of jargon or a breathless, excessively gung-ho attitude is considered tacky and the mark of a loser.

This speech style is a variety of the precisionist English normally spoken by scientists, design engineers, and academics in technical fields. In contrast with the methods of jargon construction, it is fairly constant throughout hackerdom.

It has been observed that many hackers are confused by negative questions — or, at least, that the people to whom they are talking are often confused by the sense of their answers. The problem is that they have done so much programming that distinguishes between

if (going) ...

and

if (!going) ...

that when they parse the question "Aren't you going?" it may seem to be asking the opposite question from "Are you going?", and so to merit an answer in the opposite sense. This confuses English-speaking non-hackers because they were taught to answer as though the negative part weren't there. In some other languages (including Russian, Chinese, and Japanese) the hackish interpretation is standard and the problem wouldn't arise. Hackers often find themselves wishing for a word like French 'si', German 'doch', or Dutch 'jawel' — a word with which one could unambiguously answer 'yes' to a negative question. (See also mu)

For similar reasons, English-speaking hackers almost never use double negatives, even if they live in a region where colloquial usage allows them. The thought of uttering something that logically ought to be an affirmative knowing it will be misparsed as a negative tends to disturb them.

In a related vein, hackers sometimes make a game of answering questions containing logical connectives with a strictly literal rather than colloquial interpretation. A non-hacker who is indelicate enough to ask a question like "So, are you working on finding that bug now or leaving it until later?" is likely to get the perfectly correct answer "Yes!" (that is, "Yes, I'm doing it either now or later, and you didn't ask which!").

--------------------------------------------------------------------------------

Chapter 8. International Style
Part I. Introduction

--------------------------------------------------------------------------------

Chapter 8. International Style
Although the Jargon File remains primarily a lexicon of hacker usage in American English, we have made some effort to get input from abroad. Though the hacker-speak of other languages often uses translations of jargon from English (often as transmitted to them by earlier Jargon File versions!), the local variations are interesting, and knowledge of them may be of some use to travelling hackers.

There are some references herein to 'Commonwealth hackish'. These are intended to describe some variations in hacker usage as reported in the English spoken in Great Britain and the Commonwealth (Canada, Australia, India, etc. — though Canada is heavily influenced by American usage). There is also an entry on Commonwealth Hackish reporting some general phonetic and vocabulary differences from U.S. hackish.

Hackers in Western Europe and (especially) Scandinavia report that they often use a mixture of English and their native languages for technical conversation. Occasionally they develop idioms in their English usage that are influenced by their native-language styles. Some of these are reported here.

On the other hand, English often gives rise to grammatical and vocabulary mutations in the native language. For example, Italian hackers often use the nonexistent verbs 'scrollare' (to scroll) and 'deletare' (to delete) rather than native Italian scorrere and cancellare. Similarly, the English verb 'to hack' has been seen conjugated in Swedish. In German, many Unix terms in English are casually declined as if they were German verbs -- thus: mount/mounten/gemountet; grep/grepen/gegrept; fork/forken/geforkt; core dump/core-dumpen, gecoredumpt. And Spanish-speaking hackers use 'linkear' (to link), 'debugear' (to debug), and 'lockear' (to lock).

European hackers report that this happens partly because the English terms make finer distinctions than are available in their native vocabularies, and partly because deliberate language-crossing makes for amusing wordplay.

A few notes on hackish usages in Russian have been added where they are parallel with English idioms and thus comprehensible to English-speakers.

--------------------------------------------------------------------------------

Chapter 9. Crackers, Phreaks, and Lamers
Part I. Introduction

--------------------------------------------------------------------------------

Chapter 9. Crackers, Phreaks, and Lamers
From the early 1980s onward, a flourishing culture of local, MS-DOS-based bulletin boards developed separately from Internet hackerdom. The BBS culture has, as its seamy underside, a stratum of 'pirate boards' inhabited by crackers, phone phreaks, and warez d00dz. These people (mostly teenagers running IBM-PC clones from their bedrooms) have developed their own characteristic jargon, heavily influenced by skateboard lingo and underground-rock slang. While BBS technology essentially died out after the Great Internet Explosion, the cracker culture moved to IRC and other Internet-based network channels and maintained a semi-underground existence.

Though crackers often call themselves 'hackers', they aren't (they typically have neither significant programming ability, nor Internet expertise, nor experience with UNIX or other true multi-user systems). Their vocabulary has little overlap with hackerdom's, and hackers regard them with varying degrees of contempt. But ten years on the brightest crackers tend to become hackers, and sometimes to recall their origins by using cracker slang in a marked and heavily ironic way.

This lexicon covers much of cracker slang (which is often called "leet-speak") so the reader will be able to understand both what leaks out of the cracker underground and the occasional ironic use by hackers.

Here is a brief guide to cracker and warez d00dz usage:

Misspell frequently. The substitutions phone → fone and freak → phreak are obligatory.

Always substitute 'z's for 's's. (i.e. "codes" → "codez"). The substitution of 'z' for 's' has evolved so that a 'z' is now systematically put at the end of words to denote an illegal or cracking connection. Examples : Appz, passwordz, passez, utilz, MP3z, distroz, pornz, sitez, gamez, crackz, serialz, downloadz, FTPz, etc.

Type random emphasis characters after a post line (i.e. "Hey Dudes!#!$#$!#!$").

Use the emphatic 'k' prefix ("k-kool", "k-rad", "k-awesome") frequently.

Abbreviate compulsively ("I got lotsa warez w/ docs").

TYPE ALL IN CAPS LOCK, SO IT LOOKS LIKE YOU'RE YELLING ALL THE TIME.

The following letter substitutions are common:

a → 4
e → 3
f → ph
i → 1 or |
l → | or 1
m → |\/|
n → |\|
o → 0
s → 5
t → 7 or +

Thus, "elite" comes out "31337" and "all your base are belong to us" becomes "4ll y0ur b4s3 4r3 b3l0ng t0 us", Other less common substitutions include:

b → 8
c → ( or k or |< or /<
d → <|
g → 6 or 9
h → |-|
k → |< or /<
p → |2
u → |_|
v → / or \/
w → // or \/\/
x → ><
y → '/

The word "cool" is spelled "kewl" and normally used ironically; when crackers really want to praise something they use the prefix "uber" (from German) which comes out "ub3r" or even "|_|83r"

These traits are similar to those of B1FF, who originated as a parody of naive BBS users; also of his latter-day equivalent Jeff K.. Occasionally, this sort of distortion may be used as heavy sarcasm or ironically by a real hacker, as in:

> I got X Windows running under Linux!d00d! u R an 31337 hax0r

The words "hax0r" for "hacker" and "sux0r" for "sucks" are the most common references; more generally, to mark a term as cracker-speak one may add "0r" or "xor". Examples:

"The nightly build is sux0r today."
"Gotta go reboot those b0x0rz."
"Man, I really ought to fix0r my .fetchmailrc."
"Yeah, well he's a 'leet VMS operat0r now, so he's too good for us."

The only practice resembling this in native hacker usage is the substitution of a dollar sign of 's' in names of products or service felt to be excessively expensive, e.g. Compu$erve, Micro$oft.

For further discussion of the pirate-board subculture, see lamer, elite, leech, poser, cracker, and especially warez d00dz, banner site, ratio site, leech mode.

--------------------------------------------------------------------------------

Chapter 10. Pronunciation Guide
Part I. Introduction

--------------------------------------------------------------------------------

Chapter 10. Pronunciation Guide
Pronunciation keys are provided in the jargon listings for all entries that are neither dictionary words pronounced as in standard English nor obvious compounds thereof. Slashes bracket phonetic pronunciations, which are to be interpreted using the following conventions:

Syllables are hyphen-separated, except that an accent or back-accent follows each accented syllable (the back-accent marks a secondary accent in some words of four or more syllables). If no accent is given, the word is pronounced with equal accentuation on all syllables (this is common for abbreviations).

Consonants are pronounced as in American English. The letter 'g' is always hard (as in "got" rather than "giant"); 'ch' is soft ("church" rather than "chemist"). The letter 'j' is the sound that occurs twice in "judge". The letter 's' is always as in "pass", never a z sound. The digraph 'kh' is the guttural of "loch" or "l'chaim". The digraph 'gh' is the aspirated g+h of "bughouse" or "ragheap" (rare in English).

Uppercase letters are pronounced as their English letter names; thus (for example) /H-L-L/ is equivalent to /aych el el/. /Z/ may be pronounced /zee/ or /zed/ depending on your local dialect.

Vowels are represented as follows:

Table 10.1. Vowels

a back, that
ah father, palm (see note)
ar far, mark
aw flaw, caught
ay bake, rain
e less, men
ee easy, ski
eir their, software
i trip, hit
i: life, sky
o block, stock (see note)
oh flow, sew
oo loot, through
or more, door
ow out, how
oy boy, coin
uh but, some
u put, foot
y yet, young
yoo few, chew
[y]oo /oo/ with optional fronting as in 'news' (/nooz/ or /nyooz/)

The glyph /@/ is used for the 'schwa' sound of unstressed or occluded vowels.

The schwa vowel is omitted in syllables containing vocalic r, l, m or n; that is, 'kitten' and 'color' would be rendered /kit'n/ and /kuhl'r/, not /kit'@n/ and /kuhl'@r/.

Note that the above table reflects mainly distinctions found in standard American English (that is, the neutral dialect spoken by TV network announcers and typical of educated speech in the Upper Midwest, Chicago, Minneapolis/St. Paul and Philadelphia). However, we separate /o/ from /ah/, which tend to merge in standard American. This may help readers accustomed to accents resembling British Received Pronunciation.

The intent of this scheme is to permit as many readers as possible to map the pronunciations into their local dialect by ignoring some subset of the distinctions we make. Speakers of British RP, for example, can smash terminal /r/ and all unstressed vowels. Speakers of many varieties of southern American will automatically map /o/ to /aw/; and so forth. (Standard American makes a good reference dialect for this purpose because it has crisp consonants and more vowel distinctions than other major dialects, and tends to retain distinctions between unstressed vowels. It also happens to be what your editor speaks.)

Entries with a pronunciation of '//' are written-only usages. (No, Unix weenies, this does not mean 'pronounce like previous pronunciation'!)

--------------------------------------------------------------------------------

Chapter 11. Other Lexicon Conventions
Part I. Introduction

--------------------------------------------------------------------------------

Chapter 11. Other Lexicon Conventions
Entries are sorted in case-blind ASCII collation order (rather than the letter-by-letter order ignoring interword spacing common in mainstream dictionaries), except that all entries beginning with nonalphabetic characters are sorted before A, except that leading dash is ignored. The case-blindness is a feature, not a bug.

Prefix ** is used as linguists do; to mark examples of incorrect usage.

We follow the 'logical' quoting convention described in the Writing Style section above. In addition, we reserve double quotes for actual excerpts of text or (sometimes invented) speech. Scare quotes (which mark a word being used in a nonstandard way), and philosopher's quotes (which turn an utterance into the string of letters or words that name it) are both rendered with single quotes.

References such as malloc(3) and patch(1) are to Unix facilities (some of which, such as patch(1), are actually open source distributed over Usenet). The Unix manuals use foo(n) to refer to item foo in section (n) of the manual, where n=1 is utilities, n=2 is system calls, n=3 is C library routines, n=6 is games, and n=8 (where present) is system administration utilities. Sections 4, 5, and 7 of the manuals have changed roles frequently and in any case are not referred to in any of the entries.

Various abbreviations used frequently in the lexicon are summarized here:

Table 11.1. Abbreviations

abbrev. abbreviation
adj. adjective
adv. adverb
alt. alternate
cav. caveat
conj. conjunction
esp. especially
excl. exclamation
imp. imperative
interj. interjection
n. noun
obs. obsolete
pl. plural
poss. possibly
pref. prefix
prob. probably
prov. proverbial
quant. quantifier
suff. suffix
syn. synonym (or synonymous with)
v. verb (may be transitive or intransitive)
var. variant
vi. intransitive verb
vt. transitive verb

Where alternate spellings or pronunciations are given, alt. separates two possibilities with nearly equal distribution, while var. prefixes one that is markedly less common than the primary.

Where a term can be attributed to a particular subculture or is known to have originated there, we have tried to so indicate. Here is a list of abbreviations used in etymologies:

Table 11.2. Origins

Amateur Packet Radio A technical culture of ham-radio sites using AX.25 and TCP/IP for wide-area networking and BBS systems.
Berkeley University of California at Berkeley
BBN Bolt, Beranek & Newman
Cambridge the university in England (not the city in Massachusetts where MIT happens to be located!)
CMU Carnegie-Mellon University
Commodore Commodore Business Machines
DEC The Digital Equipment Corporation (now HP).
Fairchild The Fairchild Instruments Palo Alto development group
FidoNet See the FidoNet entry
IBM International Business Machines
MIT Massachusetts Institute of Technology; esp. the legendary MIT AI Lab culture of roughly 1971 to 1983 and its feeder groups, including the Tech Model Railroad Club
NRL Naval Research Laboratories
NYU New York University
OED The Oxford English Dictionary
Purdue Purdue University
SAIL Stanford Artificial Intelligence Laboratory (at Stanford University)
SI From Système International, the name for the standard abbreviations of metric nomenclature used in the sciences
Stanford Stanford University
Sun Sun Microsystems
TMRC Some MITisms go back as far as the Tech Model Railroad Club (TMRC) at MIT c. 1960. Material marked TMRC is from An Abridged Dictionary of the TMRC Language, originally compiled by Pete Samson in 1959
UCLA University of California, Los Angeles
UK the United Kingdom (England, Wales, Scotland, Northern Ireland)
Usenet See the Usenet entry
WPI Worcester Polytechnic Institute, site of a very active community of PDP-10 hackers during the 1970s
WWW The World-Wide-Web.
XEROX PARC XEROX's Palo Alto Research Center, site of much pioneering research in user interface design and networking
Yale Yale University

Other etymology abbreviations such as Unix and PDP-10 refer to technical cultures surrounding specific operating systems, processors, or other environments. The fact that a term is labelled with any one of these abbreviations does not necessarily mean its use is confined to that culture. In particular, many terms labelled 'MIT' and 'Stanford' are in quite general use. We have tried to give some indication of the distribution of speakers in the usage notes; however, a number of factors mentioned in the introduction conspire to make these indications less definite than might be desirable.

A few new definitions attached to entries are marked [proposed]. These are usually generalizations suggested by editors or Usenet respondents in the process of commenting on previous definitions of those entries. These are not represented as established jargon.

--------------------------------------------------------------------------------

Chapter 12. Format for New Entries
Prev Part I. Introduction Next

--------------------------------------------------------------------------------

Chapter 12. Format for New Entries
We welcome new jargon, and corrections to or amplifications of existing entries. You can improve your submission's chances of being included by adding background information on user population and years of currency. References to actual usage via URLs and/or Google pointers are particularly welcomed.

All contributions and suggestions about the Jargon File will be considered donations to be placed in the public domain as part of this File, and may be used in subsequent paper editions. Submissions may be edited for accuracy, clarity and concision.

We are looking to expand the File's range of technical specialties covered. There are doubtless rich veins of jargon yet untapped in the scientific computing, graphics, and networking hacker communities; also in numerical analysis, computer architectures and VLSI design, language design, and many other related fields. Send us your jargon!

We are not interested in straight technical terms explained by textbooks or technical dictionaries unless an entry illuminates 'underground' meanings or aspects not covered by official histories. We are also not interested in 'joke' entries — there is a lot of humor in the file but it must flow naturally out of the explanations of what hackers do and how they think.

It is OK to submit items of jargon you have originated if they have spread to the point of being used by people who are not personally acquainted with you. We prefer items to be attested by independent submission from two different sites.

The Jargon File will be regularly maintained and made available for browsing on the World Wide Web, and will include a version number. Read it, pass it around, contribute — this is your monument!

--------------------------------------------------------------------------------

Part II. The Jargon Lexicon
Prev Next

--------------------------------------------------------------------------------

The Jargon Lexicon

The Crunchly saga begins here.

(The next cartoon in the Crunchly saga is 73-05-18.)

The infamous Crunchly cartoons by The Great Quux are woven into the lexicon, each next to an appropriate entry. To read them in the sequence in which they were written, chase pointers from here using the 'next cartoon' information in the captions. A few don't have next pointers; these are vignettes from the 1973 Crunchland tableau spread that inaugurated the strip.

Here is a framed version of the glossary.

Table of Contents

Glossary

--------------------------------------------------------------------------------

Glossary
Prev Part II. The Jargon Lexicon Next

--------------------------------------------------------------------------------

Glossary
0
(TM)
/dev/null
/me
0
1TBS
2
404
404 compliant
@-party
A
abbrev
ABEND
accumulator
ACK
Acme
ad-hockery
address harvester
adger
admin
ADVENT
adware
AFAIK
AFJ
AFK
AI
AI-complete
airplane rule
Alderson loop
aliasing bug
Alice and Bob
All hardware sucks, all software sucks.
all your base are belong to us
alpha geek
alpha particles
alt
alt bit
Aluminum Book
ambimouseterous
Amiga
Amiga Persecution Complex
amp off
amper
and there was much rejoicing
Angband
angle brackets
angry fruit salad
annoybot
annoyware
ANSI standard
ANSI standard pizza
anti-idiotarianism
AOL!
app
Archimedes
arena
arg
ARMM
armor-plated
asbestos
asbestos cork award
asbestos longjohns
ASCII
ASCII art
ASCIIbetical order
astroturfing
atomic
attoparsec
Aunt Tillie
AUP
autobogotiphobia
autoconfiscate
automagically
avatar
awk
B
B1FF
B5
back door
backbone cabal
backbone site
backgammon
background
backreference
backronym
backward combatability
BAD
Bad and Wrong
Bad Thing
bag on the side
bagbiter
bagbiting
baggy pantsing
balloonian variable
bamf
banana problem
bandwidth
bang
bang on
bang path
banner
banner ad
banner site
bar
bare metal
barf
barfmail
barfulation
barfulous
barn
barney
baroque
BASIC
batbelt
batch
bathtub curve
Batman factor
baud
baz
bazaar
bboard
BBS
BCPL
BDFL
beam
beanie key
beep
Befunge
beige toaster
bells and whistles
bells whistles and gongs
benchmark
Berkeley Quality Software
Berzerkeley
beta
BFI
BI
bible
BiCapitalization
biff
big iron
Big Red Switch
Big Room
big win
big-endian
bignum
bigot
bikeshedding
binary four
bit
bit bang
bit bashing
bit bucket
bit decay
bit rot
bit twiddling
bit-paired keyboard
bitblt
bits
bitty box
bixie
black art
black hat
black hole
black magic
Black Screen of Death
blammo
blargh
blast
blat
bletch
bletcherous
blinkenlights
blit
blitter
blivet
bloatware
BLOB
block
blog
Bloggs Family
blogosphere
blogrolling
blow an EPROM
blow away
blow out
blow past
blow up
BLT
blue box
Blue Glue
blue goo
Blue Screen of Death
blue wire
blurgle
BNF
boa
board
boat anchor
bob
bodge
BOF
BOFH
bogo-sort
bogometer
BogoMIPS
bogon
bogon filter
bogon flux
bogosity
bogotify
bogue out
bogus
Bohr bug
boink
bomb
bondage-and-discipline language
bonk/oif
book titles
boot
Borg
borken
bot
bottom feeder
bottom-post
bottom-up implementation
bounce
bounce message
boustrophedon
box
boxed comments
boxen
boxology
bozotic
brain dump
brain fart
brain-damaged
brain-dead
braino
brainwidth
bread crumbs
break
break-even point
breath-of-life packet
breedle
Breidbart Index
brick
bricktext
bring X to its knees
brittle
broadcast storm
broken
broken arrow
broken-ring network
BrokenWindows
broket
Brooks's Law
brown-paper-bag bug
browser
BRS
brute force
brute force and ignorance
BSD
BSOD
BUAF
BUAG
bubble sort
bucky bits
buffer chuck
buffer overflow
bug
bug-compatible
bug-for-bug compatible
bug-of-the-month club
bulletproof
bullschildt
bump
burble
buried treasure
burn a CD
burn-in period
burst page
busy-wait
buzz
buzzword-compliant
BWQ
by hand
byte
byte sex
bytesexual
Bzzzt! Wrong.
C
C
C Programmer's Disease
C&C
C++
calculator
Camel Book
camelCase
camelCasing
can't happen
cancelbot
Cancelmoose[tm]
candygrammar
canonical
careware
cargo cult programming
cascade
case and paste
case mod
casters-up mode
casting the runes
cat
catatonic
cathedral
cd tilde
CDA
cdr
chad
chad box
chain
chainik
channel
channel hopping
channel op
chanop
char
charityware
chase pointers
chawmp
check
cheerfully
chemist
Chernobyl chicken
Chernobyl packet
chicken head
chickenboner
chiclet keyboard
Chinese Army technique
choad
choke
chomp
chomper
CHOP
Christmas tree
Christmas tree packet
chrome
chug
Church of the SubGenius
CI$
Cinderella Book
Classic C
clean
click of death
CLM
clobber
clock
clocks
clone
clone-and-hack coding
clover key
clue-by-four
clustergeeking
co-lo
coaster
coaster toaster
COBOL
COBOL fingers
cobweb site
code
code grinder
code monkey
Code of the Geeks
code police
codes
codewalker
coefficient of X
cokebottle
cold boot
COME FROM
comm mode
command key
comment out
Commonwealth Hackish
compact
compiler jock
compo
compress
Compu$erve
computer confetti
computron
con
condition out
condom
confuser
connector conspiracy
cons
considered harmful
console
console jockey
content-free
control-C
control-O
control-Q
control-S
Conway's Law
cookbook
cooked mode
cookie
cookie bear
cookie file
cookie jar
cookie monster
copious free time
copper
copy protection
copybroke
copycenter
copyleft
copyparty
copywronged
core
core cancer
core dump
core leak
Core Wars
cosmic rays
cough and die
courier
cow orker
cowboy
CP/M
CPU Wars
crack
crack root
cracker
cracking
crank
crapplet
CrApTeX
crash
crash and burn
crawling horror
CRC handbook
creationism
creep
creeping elegance
creeping featurism
creeping featuritis
cretin
cretinous
crippleware
critical mass
crlf
crock
cross-post
crossload
crudware
cruft
cruft together
cruftsmanship
crufty
crumb
crunch
cryppie
cthulhic
CTSS
cube
cup holder
cursor dipped in X
cuspy
cut a tape
cybercrud
cyberpunk
cyberspace
cycle
cycle of reincarnation
cycle server
cypherpunk
C|N>K
D
daemon
daemon book
dahmum
dancing frog
dangling pointer
dark-side hacker
Datamation
DAU
Dave the Resurrector
day mode
dd
DDT
de-rezz
dead
dead beef attack
dead code
dead-tree version
DEADBEEF
deadlock
deadly embrace
death code
Death Square
Death Star
Death, X of
DEC
DEC Wars
decay
deckle
DED
deep hack mode
deep magic
deep space
defenestration
defined as
deflicted
dehose
Dejagoo
deletia
deliminator
delint
delta
demented
demigod
demo
demo mode
demoeffect
demogroup
demon
demon dialer
demoparty
demoscene
dentro
depeditate
deprecated
derf
deserves to lose
despew
dickless workstation
dictionary flame
diddle
die
die horribly
diff
dike
Dilbert
ding
dink
dinosaur
dinosaur pen
dinosaurs mating
dirtball
dirty power
disclaimer
Discordianism
disemvowel
disk farm
display hack
dispress
Dissociated Press
distribution
distro
disusered
DMZ
do protocol
doc
documentation
dodgy
dogcow
dogfood
dogpile
dogwash
Don't do that then!
dongle
dongle-disk
Doom, X of
doorstop
DoS attack
dot file
double bucky
doubled sig
down
download
DP
DPer
Dr. Fred Mbogo
dragon
Dragon Book
drain
dread high-bit disease
dread questionmark disease
DRECNET
driver
droid
drone
drool-proof paper
drop on the floor
drop-ins
drop-outs
drugged
drum
drunk mouse syndrome
DSW
dub dub dub
Duff's device
dumb terminal
dumbass attack
dumbed down
dump
dumpster diving
dusty deck
DWIM
dynner
E
Easter egg
Easter egging
eat flaming death
EBCDIC
ECP
ed
egg
egosurf
eighty-column mind
El Camino Bignum
elder days
elegant
elephantine
elevator controller
elite
ELIZA effect
elvish
EMACS
email
emoticon
EMP
empire
engine
English
enhancement
ENQ
EOD
EOF
EOL
EOU
epoch
epsilon
epsilon squared
era
Eric Conspiracy
Eris
erotics
error 33
eurodemo
evil
evil and rude
Evil Empire
exa-
examining the entrails
EXCH
excl
EXE
exec
exercise, left as an
Exon
Exploder
exploit
external memory
eye candy
eyeball search
F
face time
factor
fairings
fall over
fall through
fan
fandango on core
FAQ
FAQ list
FAQL
faradize
farkled
farm
fascist
fat electrons
fat pipe
fat-finger
faulty
fear and loathing
feature
feature creature
feature creep
feature key
feature shock
featurectomy
feep
feeper
feeping creature
feeping creaturism
feetch feetch
fence
fencepost error
fiber-seeking backhoe
FidoNet
field circus
field servoid
file signature
filk
film at 11
filter
Finagle's Law
fine
finger
finger trouble
finger-pointing syndrome
finn
firebottle
firefighting
firehose syndrome
firewall code
firewall machine
fireworks mode
firmware
fish
FISH queue
fisking
FITNR
fix
FIXME
flag
flag day
flaky
flamage
flame
flame bait
flame on
flame war
flamer
flap
flarp
flash crowd
flat
flat-ASCII
flat-file
flatten
flavor
flavorful
flippy
flood
flowchart
flower key
flush
flypage
Flyspeck 3
flytrap
FM
fnord
FOAF
FOD
fold case
followup
fontology
foo
foobar
fool
fool file
Foonly
footprint
for free
for the rest of us
for values of
fora
foreground
fork
fork bomb
forked
Formosa's Law
Fortrash
fortune cookie
forum
fossil
four-color glossies
frag
fragile
Frankenputer
fred
Fred Foobar
frednet
free software
freeware
freeze
fried
frink
friode
fritterware
frob
frobnicate
frobnitz
frog
frogging
front end
frotz
frotzed
frowney
FRS
fry
fscking
FSF
-fu
FUBAR
fuck me harder
FUD
FUD wars
fudge
fudge factor
fuel up
Full Monty
fum
functino
funky
funny money
furrfu
G
G
gang bang
Gang of Four
garbage collect
garply
gas
Gates's Law
gawble
GC
GCOS
GECOS
gedanken
geef
geek
geek code
geek out
geekasm
gen
gender mender
General Public Virus
generate
Genius From Mars Technique
gensym
Get a life!
Get a real computer!
GandhiCon
gib
GIFs at 11
gig
giga-
GIGO
gilley
gillion
ginger
GIPS
GIYF
glark
glass
glass tty
glassfet
glitch
glob
glork
glue
gnarly
GNU
gnubie
GNUMACS
go flatline
go gold
go root
go-faster stripes
GoAT
goat file
gobble
Godwin's Law
Godzillagram
golden
golf-ball printer
gonk
gonkulator
gonzo
Good Thing
google
google juice
gopher
gopher hole
gorets
gorilla arm
gorp
GOSMACS
gotcha
GPL
GPV
gray goo
gray hat
Great Internet Explosion
Great Renaming
Great Runes
Great Worm
great-wall
green bytes
green card
green lightning
green machine
Green's Theorem
greenbar
grep
gribble
grilf
grind
grind crank
gritch
grok
gronk
gronk out
gronked
grovel
grue
grunge
gubbish
Guido
guiltware
gumby
gunch
gunpowder chicken
guru
guru meditation
gweep
GWF
H
h
ha ha only serious
hack
hack attack
hack mode
hack on
hack together
hack up
hack value
hacked off
hacked up
hacker
hacker ethic
hacker humor
Hackers (the movie)
hacking run
Hacking X for Y
Hackintosh
hackish
hackishness
hackitude
hair
hairball
hairy
HAKMEM
hakspek
Halloween Documents
ham
hammer
hamster
HAND
hand cruft
hand-hacking
hand-roll
handle
handshaking
handwave
hang
Hanlon's Razor
happily
hard boot
hardcoded
hardwarily
hardwired
has the X nature
hash bucket
hash collision
hat
HCF
heads down
heartbeat
heatseeker
heavy metal
heavy wizardry
heavyweight
Hed Rat
heisenbug
hell desk
hello sailor!
hello world
hello, wall!
hex
hexadecimal
hexit
HHOK
HHOS
hidden flag
high bit
high moby
highly
hing
hired gun
hirsute
HLL
hoarding
hog
hole
hollised
holy penguin pee
holy wars
home box
home machine
home page
honey pot
hook
hop
horked
hose
hosed
hot chat
hot spot
hotlink
house wizard
HP-SUX
HTH
huff
hung
hungry puppy
hungus
hyperspace
hysterical reasons
I
I didn't change anything!
I see no X here.
I for one welcome our new X overlords
IANAL
IBM
ICBM address
ice
ID10T error
idempotent
IDP
If you want X, you know where to find it.
ifdef out
IIRC
ill-behaved
IMHO
Imminent Death Of The Net Predicted!
in the extreme
incantation
include
include war
indent style
Indent-o-Meter
index of X
infant mortality
infinite
infinite loop
Infinite-Monkey Theorem
infinity
inflate
Infocom
initgame
insanely great
installfest
INTERCAL
InterCaps
interesting
Internet
Internet Death Penalty
Internet Exploder
Internet Exploiter
interrupt
interrupts locked out
intertwingled
intro
IRC
iron
Iron Age
iron box
ironmonger
ISO standard cup of tea
ISP
Itanic
ITS
IWBNI
IYFEG
J
J. Random
J. Random Hacker
jack in
jaggies
Java
JCL
JEDR
Jeff K.
jello
Jeopardy-style quoting
jibble
jiffy
job security
jock
joe code
joe-job
juggling eggs
juice
jump off into never-never land
jupiter
K
K
K&R
k-
kahuna
kamikaze packet
kangaroo code
ken
kernel-of-the-week club
kgbvax
KIBO
kiboze
kibozo
kick
kill file
killer app
killer micro
killer poke
kilo-
kilogoogle
KIPS
KISS Principle
kit
KLB
klone
kludge
kluge
kluge around
kluge up
Knights of the Lambda Calculus
knobs
knurd
Knuth
koan
kook
Kool-Aid
kremvax
kyrka
L
lag
lamer
LAN party
language lawyer
languages of choice
LART
larval stage
lase
laser chicken
leaf site
leak
leaky heap
leapfrog attack
leech
leech mode
legal
legalese
lenna
LER
LERP
let the smoke out
letterbomb
lexer
life
Life is hard
light pipe
lightweight
like kicking dead whales down the beach
like nailing jelly to a tree
line 666
line eater, the
line noise
linearithmic
link farm
link rot
link-dead
lint
Lintel
Linus
Linux
lion food
Lions Book
LISP
list-bomb
lithium lick
little-endian
live
live data
Live Free Or Die!
livelock
liveware
lobotomy
locals, the
locked and loaded
locked up
logic bomb
logical
loop through
loose bytes
lord high fixer
lose
lose lose
loser
losing
loss
lossage
lossy
lost in the noise
lost in the underflow
lots of MIPS but no I/O
low-bandwidth
Lubarsky's Law of Cybernetic Entomology
Lumber Cartel
lunatic fringe
lurker
luser
M
M
M$
macdink
machoflops
Macintoy
Macintrash
macro
macro-
macrology
maggotbox
magic
magic cookie
magic number
magic smoke
mail storm
mailbomb
mailing list
main loop
mainframe
mainsleaze
malware
man page
management
mandelbug
manged
mangle
mangled name
mangler
manularity
marching ants
marbles
marginal
marginally
marketroid
Mars
martian
massage
math-out
Matrix
mav
maximum Maytag mode
McQuary limit
meatspace
meatware
meeces
meg
mega-
megapenny
MEGO
meltdown, network
meme
meme plague
memetics
memory farts
memory leak
memory smash
menuitis
mess-dos
meta
meta bit
metasyntactic variable
MFTL
mickey
mickey mouse program
micro-
MicroDroid
microfortnight
microLenat
microReid
microserf
Microsloth Windows
Microsoft
micros~1
middle-endian
middle-out implementation
milliLampson
minor detail
MIPS
misbug
misfeature
missile address
MiSTing
miswart
MMF
mobo
moby
mockingbird
mod
mode
mode bit
modulo
mojibake
molly-guard
Mongolian Hordes technique
monkey up
monkey, scratch
monstrosity
monty
Moof
Moore's Law
moria
MOTAS
MOTOS
MOTSS
mouse ahead
mouse belt
mouse droppings
mouse elbow
mouse pusher
mouso
MS-DOS
mu
MUD
muddie
mudhead
muggle
Multics
multitask
mumblage
mumble
munch
munching
munching squares
munchkin
mundane
mung
munge
Murphy's Law
music
mutter
N
N
nadger
nagware
nailed to the wall
nailing jelly
naive
naive user
NAK
NANA
nano
nano-
nanoacre
nanobot
nanocomputer
nanofortnight
nanotechnology
narg
nasal demons
nastygram
Nathan Hale
nature
neat hack
neats vs. scruffies
neep-neep
neophilia
nerd
nerd knob
net.-
net.god
net.personality
net.police
netburp
netdead
nethack
netiquette
netlag
netnews
Netscrape
netsplit
netter
network address
network meltdown
New Jersey
New Testament
newbie
newgroup wars
newline
NeWS
newsfroup
newsgroup
nick
nickle
night mode
Nightmare File System
NIL
Ninety-Ninety Rule
nipple mouse
NMI
no-op
noddy
non-optimal solution
nonlinear
nontrivial
not entirely unlike X
not ready for prime time
notwork
NP-
NSA line eater
NSP
nude
nugry
nuke
number-crunching
numbers
NUXI problem
nybble
nyetwork
O
Ob-
Obfuscated C Contest
obi-wan error
Objectionable-C
obscure
octal forty
off the trolley
off-by-one error
offline
ogg
-oid
old fart
Old Testament
on the gripping hand
one-banana problem
one-line fix
one-liner wars
ooblick
OP
op
open
open source
open switch
operating system
operator headspace
optical diff
optical grep
optimism
Oracle, the
Orange Book
oriental food
orphan
orphaned i-node
orthogonal
OS
OS/2
OSS
OT
OTOH
out-of-band
overclock
overflow bit
overrun
overrun screw
owned
P
P.O.D.
packet over air
padded cell
page in
page out
pain in the net
paper-net
param
PARC
parent message
parity errors
Parkinson's Law of Data
parm
parse
Pascal
PascalCasing
pastie
patch
patch pumpkin
patch space
path
pathological
payware
PBD
PD
PDP-10
PDP-11
PDP-20
PEBKAC
peek
pencil and paper
Pentagram Pro
Pentium
peon
percent-S
perf
perfect programmer syndrome
Perl
person of no account
pessimal
pessimizing compiler
peta-
pffft
PFY
phage
phase
phase of the moon
phase-wrapping
PHB
phreaker
phreaking
pico-
pig-tail
pilot error
ping
Ping O' Death
ping storm
pink contract
pink wire
pipe
pistol
pixel sort
pizza box
plaid screen
plain-ASCII
Plan 9
plan file
platinum-iridium
playpen
playte
plokta
plonk
plug-and-pray
plugh
plumbing
PM
point release
point-and-drool interface
pointy hat
pointy-haired
poke
poll
polygon pusher
POM
ponytail
pop
poser
post
postcardware
Postel's Prescription
posting
postmaster
PostScript
pound on
power cycle
power hit
pr0n
precedence lossage
pred
prepend
prestidigitization
pretty pictures
prettyprint
pretzel key
priesthood
prime time
print
printing discussion
priority interrupt
profile
progasm
proggy
proglet
program
Programmer's Cheer
programming
programming fluid
propeller head
propeller key
proprietary
protocol
provocative maintenance
prowler
pseudo
pseudoprime
pseudosuit
psychedelicware
psyton
pubic directory
puff
pumpkin holder
pumpking
punched card
punt
Purple Book
purple wire
push
Python
Q
quad
quadruple bucky
quantifiers
quantum bogodynamics
quarter
ques
quick-and-dirty
quine
Quirk objection
quote chapter and verse
quotient
quux
qux
QWERTY
R
rabbit job
rain dance
rainbow series
random
Random Number God
random numbers
randomness
rape
rare mode
raster blaster
raster burn
rasterbation
rat belt
rat dance
rathole
ratio site
rave
rave on!
ravs
raw mode
RBL
rc file
RE
read-only user
README file
real
real estate
real hack
real operating system
Real Programmer
Real Soon Now
real time
real user
Real World
reality check
reality-distortion field
reaper
recompile the world
rectangle slinger
recursion
recursive acronym
red wire
regexp
register dancing
rehi
reincarnation, cycle of
reinvent the wheel
relay rape
religion of CHI
religious issues
replicator
reply
restriction
retcon
RETI
retrocomputing
return from the dead
RFC
RFE
Right Thing
rip
ripoff
RL
roach
robocanceller
robot
robust
rococo
rogue
room-temperature IQ
root
root mode
rootkit
rot13
rotary debugger
RSN
RTBM
RTFAQ
RTFB
RTFM
RTFS
RTI
RTM
RTS
rubber-hose cryptanalysis
rude
runes
runic
rusty iron
rusty wire
S
S/N ratio
sacred
saga
sagan
SAIL
salescritter
salt
salt mines
salt substrate
same-day service
samizdat
samurai
sandbender
sandbox
sanity check
Saturday-night special
say
scag
scanno
scary devil monastery
schroedinbug
science-fiction fandom
SCNR
scram switch
scratch
scratch monkey
scream and die
screaming tty
screen
screen name
screen scraping
screw
screwage
scribble
script kiddies
scrog
scrool
scrozzle
scruffies
SCSI
SCSI voodoo
search-and-destroy mode
second-system effect
secondary damage
security through obscurity
SED
See figure 1
segfault
seggie
segment
segmentation fault
segv
self-reference
selvage
semi
semi-automated
semi-infinite
senior bit
September that never ended
server
SEX
sex changer
shambolic link
shar file
sharchive
Share and enjoy!
shareware
sharing violation
shebang
shelfware
shell
shell out
shift left (or right) logical
shim
shitogram
shotgun debugging
shovelware
showstopper
shriek
Shub-Internet
SIG
sig block
sig quote
sig virus
sigmonster
signal-to-noise ratio
silicon
silly walk
silo
since time T equals minus infinity
sitename
skrog
skulker
slab
slack
slash
slashdot effect
sleep
slim
slop
slopsucker
Slowlaris
slurp
slurp the robot
smart
smart terminal
smash case
smash the stack
smiley
smoke
smoke and mirrors
smoke test
smoking clover
smoot
SMOP
smurf
SNAFU principle
snail
snail-mail
snap
snarf
snarf & barf
snarf down
snark
sneaker
sneakernet
sniff
snippage
SO
social engineering
social science number
sock puppet
sodium substrate
soft boot
softcopy
software bloat
software hoarding
software laser
software rot
softwarily
softy
some random X
sorcerer's apprentice mode
source
source of all good bits
space-cadet keyboard
spaceship operator
SPACEWAR
spaghetti code
spaghetti inheritance
spam
spam bait
spamblock
spamhaus
spamvertize
spangle
spawn
special-case
speed of light
speedometer
spell
spelling flame
spider
spider food
spiffy
spike
spin
Spinning Pizza of Death
spl
splash screen
splat
splat out
splork!
spod
spoiler
spoiler space
sponge
spoof
spool
spool file
sporgery
sport death
spungle
spyware
squirrelcide
stack
stack puke
stale pointer bug
Stanford Bunny
star out
state
stealth manager
steam-powered
steved
STFW
stir-fried random
stomp on
Stone Age
stone knives and bearskins
stoppage
store
STR
strided
stroke
strudel
stubroutine
studly
studlycaps
stunning
stupid-sort
Stupids
Sturgeon's Law
sucking mud
sufficiently small
suit
suitable win
suitably small
Sun
sun lounge
sun-stools
sunspots
super source quench
superloser
superprogrammer
superuser
support
surf
Suzie COBOL
swab
swap
swap space
swapped in
swapped out
Swiss-Army chainsaw
swizzle
sync
syntactic salt
syntactic sugar
sys-frog
sysadmin
sysape
sysop
system
system mangler
systems jock
T
T
tail recursion
talk mode
talker system
TAN
tanked
TANSTAAFL
tape monkey
tar and feather
tarball
tardegy
taste
tayste
TCB
TCP/IP
TECO
tee
teergrube
teledildonics
ten-finger interface
tense
tentacle
tenured graduate student
tera-
teraflop club
terminak
terminal brain death
terminal illness
terminal junkie
test
TeX
text
thanks in advance
That's not a bug, that's a feature!
the literature
the network
the X that can be Y is not the true X
theology
theory
thinko
This can't happen
This time, for sure!
thrash
thread
three-finger salute
throwaway account
thud
thumb
thundering herd problem
thunk
tick
tick-list features
tickle a bug
tiger team
time bomb
time sink
time T
times-or-divided-by
timesharing
TINC
Tinkerbell program
TINLC
tip of the ice-cube
tired iron
tits on a keyboard
TLA
TMRC
TMRCie
TMTOWTDI
to a first approximation
to a zeroth approximation
toad
toast
toaster
toeprint
TOFU
toggle
tool
toolchain
toolsmith
toor
top-post
topic drift
topic group
TOPS-10
TOPS-20
TOS
tourist
tourist information
touristic
toy
toy language
toy problem
toy program
trampoline
trap
trap door
trash
trawl
tree-killer
treeware
trit
trivial
troff
troglodyte
troglodyte mode
Trojan horse
troll
Troll-O-Meter
tron
troughie
true-hacker
tty
tube
tube time
tumbler
tunafish
tune
turbo nerd
Turing tar-pit
turist
Tux
tweak
TWENEX
twiddle
twilight zone
twink
twirling baton
two pi
two-to-the-N
tyop
U
u-
UBD
UBE
ubergeek
UCE
UDP
UN*X
undefined external reference
under the hood
undocumented feature
uninteresting
Unix
Unix brain damage
Unix conspiracy
Unix weenie
unixism
unswizzle
unwind the stack
unwind-protect
up
upload
upstream
upthread
uptime
urchin
URL
Usenet
Usenet Death Penalty
user
user-friendly
user-obsequious
userland
Utah teapot, the
UTSL
UUOC
V
V7
vadding
vanilla
vanity domain
vannevar
vaporware
var
vaston
VAX
VAXen
vaxocentrism
vdiff
veeblefester
velveeta
Venus flytrap
verbage
verbiage
Version 7
vgrep
vi
video toaster
videotex
virgin
virtual
virtual beer
virtual Friday
virtual reality
virtual shredder
virus
visionary
Visual Fred
VMS
voice
voice-net
voodoo programming
VR
Vulcan nerve pinch
vulture capitalist
W
w00t
wabbit
WAITS
waldo
walk
walk off the end of
walking drives
wall
wall follower
wall time
wall wart
wallhack
wango
wank
wannabee
war dialer
war-driving
war-chalking
-ware
warez
warez d00dz
warez kiddies
warlording
warm boot
wart
washing machine
washing software
water MIPS
wave a dead chicken
weasel
web pointer
web ring
web toaster
webify
webmaster
wedged
wedgie
wedgitude
weeble
weeds
weenie
Weenix
well-behaved
well-connected
wetware
whack
whack-a-mole
whacker
whales
What's a spline?
wheel
wheel bit
wheel of reincarnation
wheel wars
white hat
whitelist
whizzy
Whorfian mind-lock
wibble
WIBNI
widget
wiggles
wild side
WIMP environment
win
win big
win win
Winchester
windoid
window shopping
Windowsitis
Windoze
winged comments
winkey
winnage
winner
winnitude
Wintel
Wintendo
wired
wirehead
wirewater
wish list
within delta of
within epsilon of
wizard
Wizard Book
wizard hat
wizard mode
wizardly
wok-on-the-wall
womb box
WOMBAT
womble
wonky
workaround
working as designed
worm
wormhole
wound around the axle
wrap around
write-only code
write-only language
write-only memory
Wrong Thing
wugga wugga
wumpus
WYSIAYG
WYSIWYG
X
X
XEROX PARC
XOFF
XON
xor
xref
XXX
xyzzy
Y
YA-
YABA
YAFIYGI
yak shaving
YAUN
yellow card
yellow wire
Yet Another
YHBT
YKYBHTLW
YMMV
You are not expected to understand this
You know you've been hacking too long when
Your mileage may vary
Yow!
yoyo mode
Yu-Shiang Whole Fish
Z
zap
zapped
Zawinski's Law
zbeba
zen
zero
zero-content
Zero-One-Infinity Rule
zeroth
zigamorph
zip
zipperhead
zombie
zorch
Zork
zorkmid

--------------------------------------------------------------------------------

0
Prev Glossary Next

--------------------------------------------------------------------------------

0
(TM)
/dev/null
/me
0
1TBS
2
404
404 compliant
@-party

--------------------------------------------------------------------------------

/dev/null
Prev? 0 ?Next

--------------------------------------------------------------------------------

/dev/null: /dev?nuhl/, n.
[from the Unix null device, used as a data sink] A notional 'black hole' in any information space being discussed, used, or referred to. A controversial posting, for example, might end "Kudos to rasputin@kremlin.org, flames to /dev/null". See

bit bucket.

--------------------------------------------------------------------------------

/me
Prev? 0 ?Next

--------------------------------------------------------------------------------

/me: //
[IRC; common] Under most IRC, /me is the "pose" command; if you are logged on as Foonly and type "/me laughs", others watching the channel will see "* Joe Foonly laughs". This usage has been carried over to mail and news, where the reader is expected to perform the same expansion in his or her head.

--------------------------------------------------------------------------------

0
Prev? 0 ?Next

--------------------------------------------------------------------------------

0
Numeric zero, as opposed to the letter 'O' (the 15th letter of the English alphabet). In their unmodified forms they look a lot alike, and various kluges invented to make them visually distinct have compounded the confusion. If your zero is center-dotted and letter-O is not, or if letter-O looks almost rectangular but zero looks more like an American football stood on end (or the reverse), you're probably looking at a modern character display (though the dotted zero seems to have originated as an option on IBM 3270 controllers). If your zero is slashed but letter-O is not, you're probably looking at an old-style ASCII graphic set descended from the default typewheel on the venerable ASR-33 Teletype (Scandinavians, for whom ؠis a letter, curse this arrangement). (Interestingly, the slashed zero long predates computers; Florian Cajori's monumental A History of Mathematical Notations notes that it was used in the twelfth and thirteenth centuries.) If letter-O has a slash across it and the zero does not, your display is tuned for a very old convention used at IBM and a few other early mainframe makers (Scandinavians curse this arrangement even more, because it means two of their letters collide). Some Burroughs/Unisys equipment displays a zero with a reversed slash. Old CDC computers rendered letter O as an unbroken oval and 0 as an oval broken at upper right and lower left. And yet another convention common on early line printers left zero unornamented but added a tail or hook to the letter-O so that it resembled an inverted Q or cursive capital letter-O (this was endorsed by a draft ANSI standard for how to draw ASCII characters, but the final standard changed the distinguisher to a tick-mark in the upper-left corner). Are we sufficiently confused yet?

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

How to become a hacker---Part-2

noreply@blogger.com (aashu) — Fri, 14 Nov 2008 08:53:00 +0000
How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

How To Become A Hacker
Eric Steven Raymond
Thyrsus Enterprises Copyright © 2001 Eric S. Raymond Revision History Revision 1.38 Deprecate Java as a language to learn early. Revision 1.37 Revision 1.36 Revision 1.35 Minor fixes. Revision 1.34 Revision 1.33 Add a pointer to Peter Norvig's excellent essay. Revision 1.32 29 Jun 2005 esr Substantial new material on not solving problems twice. Answer a FAQ on hacking and open-source programming. The three questions that reveal if you are already a hacker. Revision 1.31 22 Mar 2005 esr Added a link to another Paul Graham essay, and advice on how to pick a first project. More translation-link updates. Revision 1.30 Added and updated many translation links. Table of Contents Why This Document? What Is a Hacker? The Hacker Attitude 1. The world is full of fascinating problems waiting to be solved. 2. No problem should ever have to be solved twice. 3. Boredom and drudgery are evil. 4. Freedom is good. 5. Attitude is no substitute for competence. Basic Hacking Skills 1. Learn how to program. 2. Get one of the open-source Unixes and learn to use and run it. 3. Learn how to use the World Wide Web and write HTML. 4. If you don't have functional English, learn it. Status in the Hacker Culture 1. Write open-source software 2. Help test and debug open-source software 2 Mar 2005 esr 07 Mar 2006 29 Nov 2005 esr esr Remove C# from the list of languages to be avoided now that Mono is out of beta. 4 Oct 2007 21 Mar 2007 03 Aug 2006 esr esr esr Recommend Ubuntu as a Unix distro for newbies. Add note about live CDs, and ten years to mastery. 8 Jan 2008 esr

1 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

3. Publish useful information 4. Help keep the infrastructure working 5. Serve the hacker culture itself The Hacker/Nerd Connection Points For Style Other Resources Frequently Asked Questions

Why This Document?
As editor of the Jargon File and author of a few other well-known documents of similar nature, I often get email requests from enthusiastic network newbies asking (in effect) "how can I learn to be a wizardly hacker?". Back in 1996 I noticed that there didn't seem to be any other FAQs or web documents that addressed this vital question, so I started this one. A lot of hackers now consider it definitive, and I suppose that means it is. Still, I don't claim to be the exclusive authority on this topic; if you don't like what you read here, write your own. If you are reading a snapshot of this document offline, the current version lives at http://catb.org/~esr/faqs/hacker-howto.html. Note: there is a list of Frequently Asked Questions at the end of this document. Please read these—twice—before mailing me any questions about this document. Numerous translations of this document are available: Arabic Bulgarian, Catalan, Chinese (Simplified), Danish, Dutch, Estonian, Farsi, Finnish, German, Greek Hebrew, Italian Japanese, Norwegian, Polish, Portuguese (Brazilian), Romanian Russian Spanish, Turkish, and Swedish. Note that since this document changes occasionally, they may be out of date to varying degrees. The five-dots-in-nine-squares diagram that decorates this document is called a glider. It is a simple pattern with some surprising properties in a mathematical simulation called Life that has fascinated hackers for many years. I think it makes a good visual emblem for what hackers are like — abstract, at first a bit mysterious-seeming, but a gateway to a whole world with an intricate logic of its own. Read more about the glider emblem here.

What Is a Hacker?
The Jargon File contains a bunch of definitions of the term 'hacker', most having to do with technical adeptness and a delight in solving problems and overcoming limits. If you want to know how to become a hacker, though, only two are really relevant. There is a community, a shared culture, of expert programmers and networking wizards that traces its history back through decades to the first time-sharing minicomputers and the earliest ARPAnet experiments. The members of this culture originated the term 'hacker'. Hackers built the Internet. Hackers made the Unix operating system what it is today. Hackers run Usenet. Hackers make the World Wide Web work. If you are part of this culture, if you have contributed to it and other people in it know who you are and call you a hacker, you're a hacker. The hacker mind-set is not confined to this software-hacker culture. There are people who apply the hacker attitude to other things, like electronics or music — actually, you can find it at the highest levels of any science or art. Software hackers recognize these kindred spirits elsewhere and may call them 'hackers' too — and some claim that the hacker nature is really independent of the particular medium the hacker works in. But in the rest of this document we will focus on the skills and attitudes of software hackers, and the traditions of the shared culture that originated the term 'hacker'. There is another group of people who loudly call themselves hackers, but aren't. These are people (mainly adolescent males) who get a kick out of breaking into computers and phreaking the phone

2 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

system. Real hackers call these people 'crackers' and want nothing to do with them. Real hackers mostly think crackers are lazy, irresponsible, and not very bright, and object that being able to break security doesn't make you a hacker any more than being able to hotwire cars makes you an automotive engineer. Unfortunately, many journalists and writers have been fooled into using the word 'hacker' to describe crackers; this irritates real hackers no end. The basic difference is this: hackers build things, crackers break them. If you want to be a hacker, keep reading. If you want to be a cracker, go read the alt.2600 newsgroup and get ready to do five to ten in the slammer after finding out you aren't as smart as you think you are. And that's all I'm going to say about crackers.

The Hacker Attitude
1. The world is full of fascinating problems waiting to be solved. 2. No problem should ever have to be solved twice. 3. Boredom and drudgery are evil. 4. Freedom is good. 5. Attitude is no substitute for competence. Hackers solve problems and build things, and they believe in freedom and voluntary mutual help. To be accepted as a hacker, you have to behave as though you have this kind of attitude yourself. And to behave as though you have the attitude, you have to really believe the attitude. But if you think of cultivating hacker attitudes as just a way to gain acceptance in the culture, you'll miss the point. Becoming the kind of person who believes these things is important for you — for helping you learn and keeping you motivated. As with all creative arts, the most effective way to become a master is to imitate the mind-set of masters — not just intellectually but emotionally as well. Or, as the following modern Zen poem has it: To follow the path: look to the master, follow the master, walk with the master, see through the master, become the master. So, if you want to be a hacker, repeat the following things until you believe them:

1. The world is full of fascinating problems waiting to be solved.
Being a hacker is lots of fun, but it's a kind of fun that takes lots of effort. The effort takes motivation. Successful athletes get their motivation from a kind of physical delight in making their bodies perform, in pushing themselves past their own physical limits. Similarly, to be a hacker you have to get a basic thrill from solving problems, sharpening your skills, and exercising your intelligence. If you aren't the kind of person that feels this way naturally, you'll need to become one in order to make it as a hacker. Otherwise you'll find your hacking energy is sapped by distractions like sex, money, and social approval. (You also have to develop a kind of faith in your own learning capacity — a belief that even though you may not know all of what you need to solve a problem, if you tackle just a piece of it and learn from that, you'll learn enough to solve the next piece — and so on, until you're done.)

2. No problem should ever have to be solved twice.

3 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. To behave like a hacker, you have to believe that the thinking time of other hackers is precious — so much so that it's almost a moral duty for you to share information, solve problems and then give the solutions away just so other hackers can solve new problems instead of having to perpetually re-address old ones. Note, however, that "No problem should ever have to be solved twice." does not imply that you have to consider all existing solutions sacred, or that there is only one right solution to any given problem. Often, we learn a lot about the problem that we didn't know before by studying the first cut at a solution. It's OK, and often necessary, to decide that we can do better. What's not OK is artificial technical, legal, or institutional barriers (like closed-source code) that prevent a good solution from being re-used and force people to re-invent wheels. (You don't have to believe that you're obligated to give all your creative product away, though the hackers that do are the ones that get most respect from other hackers. It's consistent with hacker values to sell enough of it to keep you in food and rent and computers. It's fine to use your hacking skills to support a family or even get rich, as long as you don't forget your loyalty to your art and your fellow hackers while doing it.)

3. Boredom and drudgery are evil.
Hackers (and creative people in general) should never be bored or have to drudge at stupid repetitive work, because when this happens it means they aren't doing what only they can do — solve new problems. This wastefulness hurts everybody. Therefore boredom and drudgery are not just unpleasant but actually evil. To behave like a hacker, you have to believe this enough to want to automate away the boring bits as much as possible, not just for yourself but for everybody else (especially other hackers). (There is one apparent exception to this. Hackers will sometimes do things that may seem repetitive or boring to an observer as a mind-clearing exercise, or in order to acquire a skill or have some particular kind of experience you can't have otherwise. But this is by choice — nobody who can think should ever be forced into a situation that bores them.)

4. Freedom is good.
Hackers are naturally anti-authoritarian. Anyone who can give you orders can stop you from solving whatever problem you're being fascinated by — and, given the way authoritarian minds work, will generally find some appallingly stupid reason to do so. So the authoritarian attitude has to be fought wherever you find it, lest it smother you and other hackers. (This isn't the same as fighting all authority. Children need to be guided and criminals restrained. A hacker may agree to accept some kinds of authority in order to get something he wants more than the time he spends following orders. But that's a limited, conscious bargain; the kind of personal surrender authoritarians want is not on offer.) Authoritarians thrive on censorship and secrecy. And they distrust voluntary cooperation and information-sharing — they only like 'cooperation' that they control. So to behave like a hacker, you have to develop an instinctive hostility to censorship, secrecy, and the use of force or deception to compel responsible adults. And you have to be willing to act on that belief.

5. Attitude is no substitute for competence.
To be a hacker, you have to develop some of these attitudes. But copping an attitude alone won't make you a hacker, any more than it will make you a champion athlete or a rock star. Becoming a hacker will take intelligence, practice, dedication, and hard work. Therefore, you have to learn to distrust attitude and respect competence of every kind. Hackers won't let posers waste their time, but they worship competence — especially competence at hacking, but

4 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

competence at anything is valued. Competence at demanding skills that few can master is especially good, and competence at demanding skills that involve mental acuteness, craft, and concentration is best. If you revere competence, you'll enjoy developing it in yourself — the hard work and dedication will become a kind of intense play rather than drudgery. That attitude is vital to becoming a hacker.

Basic Hacking Skills
1. Learn how to program. 2. Get one of the open-source Unixes and learn to use and run it. 3. Learn how to use the World Wide Web and write HTML. 4. If you don't have functional English, learn it. The hacker attitude is vital, but skills are even more vital. Attitude is no substitute for competence, and there's a certain basic toolkit of skills which you have to have before any hacker will dream of calling you one. This toolkit changes slowly over time as technology creates new skills and makes old ones obsolete. For example, it used to include programming in machine language, and didn't until recently involve HTML. But right now it pretty clearly includes the following:

1. Learn how to program.
This, of course, is the fundamental hacking skill. If you don't know any computer languages, I recommend starting with Python. It is cleanly designed, well documented, and relatively kind to beginners. Despite being a good first language, it is not just a toy; it is very powerful and flexible and well suited for large projects. I have written a more detailed evaluation of Python. Good tutorials are available at the Python web site. I used to recommend Java as a good language to learn early, but this critique has changed my mind (search for "The Pitfalls of Java as a First Programming Language" within it). A hacker cannot, as they devastatingly put it "approach problem-solving like a plumber in a hardware store"; you have to know what the components actually do. Now I think it is probably best to learn C and Lisp first, then Java. If you get into serious programming, you will have to learn C, the core language of Unix. C++ is very closely related to C; if you know one, learning the other will not be difficult. Neither language is a good one to try learning as your first, however. And, actually, the more you can avoid programming in C the more productive you will be. C is very efficient, and very sparing of your machine's resources. Unfortunately, C gets that efficiency by requiring you to do a lot of low-level management of resources (like memory) by hand. All that low-level code is complex and bug-prone, and will soak up huge amounts of your time on debugging. With today's machines as powerful as they are, this is usually a bad tradeoff — it's smarter to use a language that uses the machine's time less efficiently, but your time much more efficiently. Thus, Python. Other languages of particular importance to hackers include Perl and LISP. Perl is worth learning for practical reasons; it's very widely used for active web pages and system administration, so that even if you never write Perl you should learn to read it. Many people use Perl in the way I suggest you should use Python, to avoid C programming on jobs that don't require C's machine efficiency. You will need to be able to understand their code. LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot. (You can get some beginning experience with LISP fairly easily by writing and modifying editing modes for the Emacs text editor, or Script-Fu plugins for the GIMP.) It's best, actually, to learn all five of Python, C/C++, Java, Perl, and LISP. Besides being the most

5 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

important hacking languages, they represent very different approaches to programming, and each will educate you in valuable ways. But be aware that you won't reach the skill level of a hacker or even merely a programmer simply by accumulating languages — you need to learn how to think about programming problems in a general way, independent of any one language. To be a real hacker, you need to get to the point where you can learn a new language in days by relating what's in the manual to what you already know. This means you should learn several very different languages. I can't give complete instructions on how to learn to program here — it's a complex skill. But I can tell you that books and courses won't do it — many, maybe most of the best hackers are self-taught. You can learn language features — bits of knowledge — from books, but the mind-set that makes that knowledge into living skill can be learned only by practice and apprenticeship. What will do it is (a) reading code and (b) writing code. Peter Norvig, who is one of Google's top hackers and the co-author of the most widely used textbook on AI, has written an excellent essay called Teach Yourself Programming in Ten Years. His "recipe for programming success" is worth careful attention. Learning to program is like learning to write good natural language. The best way to do it is to read some stuff written by masters of the form, write some things yourself, read a lot more, write a little more, read a lot more, write some more ... and repeat until your writing begins to develop the kind of strength and economy you see in your models. Finding good code to read used to be hard, because there were few large programs available in source for fledgeling hackers to read and tinker with. This has changed dramatically; open-source software, programming tools, and operating systems (all built by hackers) are now widely available. Which brings me neatly to our next topic...

2. Get one of the open-source Unixes and learn to use and run it.
I'll assume you have a personal computer or can get access to one. (Take a moment to appreciate how much that means. The hacker culture originally evolved back when computers were so expensive that individuals could not own them.) The single most important step any newbie can take toward acquiring hacker skills is to get a copy of Linux or one of the BSD-Unixes or OpenSolaris, install it on a personal machine, and run it. Yes, there are other operating systems in the world besides Unix. But they're distributed in binary — you can't read the code, and you can't modify it. Trying to learn to hack on a Microsoft Windows machine or under any other closed-source system is like trying to learn to dance while wearing a body cast. Under Mac OS X it's possible, but only part of the system is open source — you're likely to hit a lot of walls, and you have to be careful not to develop the bad habit of depending on Apple's proprietary code. If you concentrate on the Unix under the hood you can learn some useful things. Unix is the operating system of the Internet. While you can learn to use the Internet without knowing Unix, you can't be an Internet hacker without understanding Unix. For this reason, the hacker culture today is pretty strongly Unix-centered. (This wasn't always true, and some old-time hackers still aren't happy about it, but the symbiosis between Unix and the Internet has become strong enough that even Microsoft's muscle doesn't seem able to seriously dent it.) So, bring up a Unix — I like Linux myself but there are other ways (and yes, you can run both Linux and Microsoft Windows on the same machine). Learn it. Run it. Tinker with it. Talk to the Internet with it. Read the code. Modify the code. You'll get better programming tools (including C, LISP, Python, and Perl) than any Microsoft operating system can dream of hosting, you'll have fun, and you'll soak up more knowledge than you realize you're learning until you look back on it as a master hacker. For more about learning Unix, see The Loginataka. You might also want to have a look at The Art Of Unix Programming. To get your hands on a Linux, see the Linux Online! site; you can download from there or (better idea) find a local Linux user group to help you with installation.

6 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

During the first ten years of this HOWTO's life, I reported that from a new user's point of view, all Linux distributions are almost equivalent. But in 2006-2007, an actual best choice emerged: Ubuntu. While other distros have their own areas of strength, Ubuntu is far and away the most accessible to Linux newbies. You can find BSD Unix help and resources at www.bsd.org. A good way to dip your toes in the water is to boot up what Linux fans call a live CD, a distribution that runs entirely off a CD without having to modify your hard disk. This will be slow, because CDs are slow, but it's a way to get a look at the possibilities without having to do anything drastic. I have written a primer on the basics of Unix and the Internet. I used to recommend against installing either Linux or BSD as a solo project if you're a newbie. Nowadays the installers have gotten good enough that doing it entirely on your own is possible even for a newbie. Nevertheless, I still recommend making contact with your local Linux user's group and asking for help. It can't hurt, and may smooth the process.

3. Learn how to use the World Wide Web and write HTML.
Most of the things the hacker culture has built do their work out of sight, helping run factories and offices and universities without any obvious impact on how non-hackers live. The Web is the one big exception, the huge shiny hacker toy that even politicians admit has changed the world. For this reason alone (and a lot of other good ones as well) you need to learn how to work the Web. This doesn't just mean learning how to drive a browser (anyone can do that), but learning how to write HTML, the Web's markup language. If you don't know how to program, writing HTML will teach you some mental habits that will help you learn. So build a home page. Try to stick to XHTML, which is a cleaner language than classic HTML. (There are good beginner tutorials on the Web; here's one.) But just having a home page isn't anywhere near good enough to make you a hacker. The Web is full of home pages. Most of them are pointless, zero-content sludge — very snazzy-looking sludge, mind you, but sludge all the same (for more on this see The HTML Hell Page). To be worthwhile, your page must have content — it must be interesting and/or useful to other hackers. And that brings us to the next topic...

4. If you don't have functional English, learn it.
As an American and native English-speaker myself, I have previously been reluctant to suggest this, lest it be taken as a sort of cultural imperialism. But several native speakers of other languages have urged me to point out that English is the working language of the hacker culture and the Internet, and that you will need to know it to function in the hacker community. Back around 1991 I learned that many hackers who have English as a second language use it in technical discussions even when they share a birth tongue; it was reported to me at the time that English has a richer technical vocabulary than any other language and is therefore simply a better tool for the job. For similar reasons, translations of technical books written in English are often unsatisfactory (when they get done at all). Linus Torvalds, a Finn, comments his code in English (it apparently never occurred to him to do otherwise). His fluency in English has been an important factor in his ability to recruit a worldwide community of developers for Linux. It's an example worth following. Being a native English-speaker does not guarantee that you have language skills good enough to function as a hacker. If your writing is semi-literate, ungrammatical, and riddled with misspellings, many hackers (including myself) will tend to ignore you. While sloppy writing does not invariably mean sloppy thinking, we've generally found the correlation to be strong — and we have no use for sloppy thinkers. If you can't yet write competently, learn to.

7 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

Status in the Hacker Culture
1. Write open-source software 2. Help test and debug open-source software 3. Publish useful information 4. Help keep the infrastructure working 5. Serve the hacker culture itself Like most cultures without a money economy, hackerdom runs on reputation. You're trying to solve interesting problems, but how interesting they are, and whether your solutions are really good, is something that only your technical peers or superiors are normally equipped to judge. Accordingly, when you play the hacker game, you learn to keep score primarily by what other hackers think of your skill (this is why you aren't really a hacker until other hackers consistently call you one). This fact is obscured by the image of hacking as solitary work; also by a hacker-cultural taboo (gradually decaying since the late 1990s but still potent) against admitting that ego or external validation are involved in one's motivation at all. Specifically, hackerdom is what anthropologists call a gift culture. You gain status and reputation in it not by dominating other people, nor by being beautiful, nor by having things other people want, but rather by giving things away. Specifically, by giving away your time, your creativity, and the results of your skill. There are basically five kinds of things you can do to be respected by hackers:

1. Write open-source software
The first (the most central and most traditional) is to write programs that other hackers think are fun or useful, and give the program sources away to the whole hacker culture to use. (We used to call these works "free software", but this confused too many people who weren't sure exactly what "free" was supposed to mean. Most of us now prefer the term "open-source" software). Hackerdom's most revered demigods are people who have written large, capable programs that met a widespread need and given them away, so that now everyone uses them. But there's a bit of a fine historical point here. While hackers have always looked up to the open-source developers among them as our community's hardest core, before the mid-1990s most hackers most of the time worked on closed source. This was still true when I wrote the first version of this HOWTO in 1996; it took the mainstreaming of open-source software after 1997 to change things. Today, "the hacker community" and "open-source developers" are two descriptions for what is essentially the same culture and population — but it is worth remembering that this was not always so.

2. Help test and debug open-source software
They also serve who stand and debug open-source software. In this imperfect world, we will inevitably spend most of our software development time in the debugging phase. That's why any open-source author who's thinking will tell you that good beta-testers (who know how to describe symptoms clearly, localize problems well, can tolerate bugs in a quickie release, and are willing to apply a few simple diagnostic routines) are worth their weight in rubies. Even one of these can make the difference between a debugging phase that's a protracted, exhausting nightmare and one that's merely a salutary nuisance. If you're a newbie, try to find a program under development that you're interested in and be a good beta-tester. There's a natural progression from helping test programs to helping debug them to helping modify them. You'll learn a lot this way, and generate good karma with people who will help you later on.

3. Publish useful information
Another good thing is to collect and filter useful and interesting information into web pages or documents like Frequently Asked Questions (FAQ) lists, and make those generally available. Maintainers of major technical FAQs get almost as much respect as open-source authors.

8 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

4. Help keep the infrastructure working
The hacker culture (and the engineering development of the Internet, for that matter) is run by volunteers. There's a lot of necessary but unglamorous work that needs done to keep it going — administering mailing lists, moderating newsgroups, maintaining large software archive sites, developing RFCs and other technical standards. People who do this sort of thing well get a lot of respect, because everybody knows these jobs are huge time sinks and not as much fun as playing with code. Doing them shows dedication.

5. Serve the hacker culture itself
Finally, you can serve and propagate the culture itself (by, for example, writing an accurate primer on how to become a hacker :-)). This is not something you'll be positioned to do until you've been around for while and become well-known for one of the first four things. The hacker culture doesn't have leaders, exactly, but it does have culture heroes and tribal elders and historians and spokespeople. When you've been in the trenches long enough, you may grow into one of these. Beware: hackers distrust blatant ego in their tribal elders, so visibly reaching for this kind of fame is dangerous. Rather than striving for it, you have to sort of position yourself so it drops in your lap, and then be modest and gracious about your status.

The Hacker/Nerd Connection
Contrary to popular myth, you don't have to be a nerd to be a hacker. It does help, however, and many hackers are in fact nerds. Being something of a social outcast helps you stay concentrated on the really important things, like thinking and hacking. For this reason, many hackers have adopted the label 'geek' as a badge of pride — it's a way of declaring their independence from normal social expectations (as well as a fondness for other things like science fiction and strategy games that often go with being a hacker). The term 'nerd' used to be used this way back in the 1990s, back when 'nerd' was a mild pejorative and 'geek' a rather harsher one; sometime after 2000 they switched places, at least in U.S. popular culture, and there is now even a significant geek-pride culture among people who aren't techies. If you can manage to concentrate enough on hacking to be good at it and still have a life, that's fine. This is a lot easier today than it was when I was a newbie in the 1970s; mainstream culture is much friendlier to techno-nerds now. There are even growing numbers of people who realize that hackers are often high-quality lover and spouse material. If you're attracted to hacking because you don't have a life, that's OK too — at least you won't have trouble concentrating. Maybe you'll get a life later on.

Points For Style
Again, to be a hacker, you have to enter the hacker mindset. There are some things you can do when you're not at a computer that seem to help. They're not substitutes for hacking (nothing is) but many hackers do them, and feel that they connect in some basic way with the essence of hacking. Learn to write your native language well. Though it's a common stereotype that programmers can't write, a surprising number of hackers (including all the most accomplished ones I know of) are very able writers.

9 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

Read science fiction. Go to science fiction conventions (a good way to meet hackers and proto-hackers). Train in a martial-arts form. The kind of mental discipline required for martial arts seems to be similar in important ways to what hackers do. The most popular forms among hackers are definitely Asian empty-hand arts such as Tae Kwon Do, various forms of Karate, Kung Fu, Aikido, or Ju Jitsu. Western fencing and Asian sword arts also have visible followings. In places where it's legal, pistol shooting has been rising in popularity since the late 1990s. The most hackerly martial arts are those which emphasize mental discipline, relaxed awareness, and control, rather than raw strength, athleticism, or physical toughness. Study an actual meditation discipline. The perennial favorite among hackers is Zen (importantly, it is possible to benefit from Zen without acquiring a religion or discarding one you already have). Other styles may work as well, but be careful to choose one that doesn't require you to believe crazy things. Develop an analytical ear for music. Learn to appreciate peculiar kinds of music. Learn to play some musical instrument well, or how to sing. Develop your appreciation of puns and wordplay. The more of these things you already do, the more likely it is that you are natural hacker material. Why these things in particular is not completely clear, but they're connected with a mix of left- and right-brain skills that seems to be important; hackers need to be able to both reason logically and step outside the apparent logic of a problem at a moment's notice. Work as intensely as you play and play as intensely as you work. For true hackers, the boundaries between "play", "work", "science" and "art" all tend to disappear, or to merge into a high-level creative playfulness. Also, don't be content with a narrow range of skills. Though most hackers self-describe as programmers, they are very likely to be more than competent in several related skills — system administration, web design, and PC hardware troubleshooting are common ones. A hacker who's a system administrator, on the other hand, is likely to be quite skilled at script programming and web design. Hackers don't do things by halves; if they invest in a skill at all, they tend to get very good at it. Finally, a few things not to do. Don't use a silly, grandiose user ID or screen name. Don't get in flame wars on Usenet (or anywhere else). Don't call yourself a 'cyberpunk', and don't waste your time on anybody who does. Don't post or email writing that's full of spelling errors and bad grammar. The only reputation you'll make doing any of these things is as a twit. Hackers have long memories — it could take you years to live your early blunders down enough to be accepted. The problem with screen names or handles deserves some amplification. Concealing your identity behind a handle is a juvenile and silly behavior characteristic of crackers, warez d00dz, and other lower life forms. Hackers don't do this; they're proud of what they do and want it associated with their real names. So if you have a handle, drop it. In the hacker culture it will only mark you as a loser.

Other Resources
Paul Graham has written an essay called Great Hackers, and another on Undergraduation, in which he speaks much wisdom. Peter Seebach maintains an excellent Hacker FAQ for managers who don't understand how to deal with

10 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

hackers. There is a document called How To Be A Programmer that is an excellent complement to this one. It has valuable advice not just about coding and skillsets, but about how to function on a programming team. I have also written A Brief History Of Hackerdom. I have written a paper, The Cathedral and the Bazaar, which explains a lot about how the Linux and open-source cultures work. I have addressed this topic even more directly in its sequel Homesteading the Noosphere. Rick Moen has written an excellent document on how to run a Linux user group. Rick Moen and I have collaborated on another document on How To Ask Smart Questions. This will help you seek assistance in a way that makes it more likely that you will actually get it. If you need instruction in the basics of how personal computers, Unix, and the Internet work, see The Unix and Internet Fundamentals HOWTO. When you release software or write patches for software, try to follow the guidelines in the Software Release Practice HOWTO. If you enjoyed the Zen poem, you might also like Rootless Root: The Unix Koans of Master Foo.

Frequently Asked Questions
Q: How do I tell if I am already a hacker? Q: Will you teach me how to hack? Q: How can I get started, then? Q: When do you have to start? Is it too late for me to learn? Q: How long will it take me to learn to hack? Q: Is Visual Basic a good language to start with? Q: Would you help me to crack a system, or teach me how to crack? Q: How can I get the password for someone else's account? Q: How can I break into/read/monitor someone else's email? Q: How can I steal channel op privileges on IRC? Q: I've been cracked. Will you help me fend off further attacks? Q: I'm having problems with my Windows software. Will you help me? Q: Where can I find some real hackers to talk with? Q: Can you recommend useful books about hacking-related subjects? Q: Do I need to be good at math to become a hacker? Q: What language should I learn first? Q: What kind of hardware do I need? Q: I want to contribute. Can you help me pick a problem to work on? Q: Do I need to hate and bash Microsoft? Q: But won't open-source software leave programmers unable to make a living? Q: Where can I get a free Unix? Q: How do I tell if I am already a hacker? A: Ask yourself the following three questions: Do you speak code, fluently? Do you identify with the goals and values of the hacker community?

11 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

Has a well-established member of the hacker community ever called you a hacker? If you can answer yes to all three of these questions, you are already a hacker. No two alone are sufficient. The first test is about skills. You probably pass it if you have the minimum technical skills described earlier in this document. You blow right through it if you have had a substantial amount of code accepted by an open-source development project. The second test is about attitude. If the five principles of the hacker mindset seemed obvious to you, more like a description of the way you already live than anything novel, you are already halfway to passing it. That's the inward half; the other, outward half is the degree to which you identify with the hacker community's long-term projects. Here is an incomplete but indicative list of some of those projects: Does it matter to you that Linux improve and spread? Are you passionate about software freedom? Hostile to monopolies? Do you act on the belief that computers can be instruments of empowerment that make the world a richer and more humane place? But a note of caution is in order here. The hacker community has some specific, primarily defensive political interests — two of them are defending free-speech rights and fending off "intellectual-property" power grabs that would make open source illegal. Some of those long-term projects are civil-liberties organizations like the Electronic Frontier Foundation, and the outward attitude properly includes support of them. But beyond that, most hackers view attempts to systematize the hacker attitude into an explicit political program with suspicion; we've learned, the hard way, that these attempts are divisive and distracting. If someone tries to recruit you to march on your capitol in the name of the hacker attitude, they've missed the point. The right response is probably "Shut up and show them the code." The third test has a tricky element of recursiveness about it. I observed in the section called "What Is a Hacker?" that being a hacker is partly a matter of belonging to a particular subculture or social network with a shared history, an inside and an outside. In the far past, hackers were a much less cohesive and self-aware group than they are today. But the importance of the social-network aspect has increased over the last thirty years as the Internet has made connections with the core of the hacker subculture easier to develop and maintain. One easy behavioral index of the change is that, in this century, we have our own T-shirts. Sociologists, who study networks like those of the hacker culture under the general rubric of "invisible colleges", have noted that one characteristic of such networks is that they have gatekeepers — core members with the social authority to endorse new members into the network. Because the "invisible college" that is hacker culture is a loose and informal one, the role of gatekeeper is informal too. But one thing that all hackers understand in their bones is that not every hacker is a gatekeeper. Gatekeepers have to have a certain degree of seniority and accomplishment before they can bestow the title. How much is hard to quantify, but every hacker knows it when they see it. Q: Will you teach me how to hack?

A: Since first publishing this page, I've gotten several requests a week (often several a day) from people to "teach me all about hacking". Unfortunately, I don't have the time or energy to do this; my own hacking projects, and working as an open-source advocate, take up 110% of my time. Even if I did, hacking is an attitude and skill you basically have to teach yourself. You'll find that while real hackers want to help you, they won't respect you if you beg to be spoon-fed everything they know. Learn a few things first. Show that you're trying, that you're capable of learning on your own. Then go to the hackers you meet with specific questions. If you do email a hacker asking for advice, here are two things to know up front. First, we've found that people who are lazy or careless in their writing are usually too lazy and careless in their thinking

12 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

to make good hackers — so take care to spell correctly, and use good grammar and punctuation, otherwise you'll probably be ignored. Secondly, don't dare ask for a reply to an ISP account that's different from the account you're sending from; we find people who do that are usually thieves using stolen accounts, and we have no interest in rewarding or assisting thievery.

Q: How can I get started, then? A: The best way for you to get started would probably be to go to a LUG (Linux user group) meeting. You can find such groups on the LDP General Linux Information Page; there is probably one near you, possibly associated with a college or university. LUG members will probably give you a Linux if you ask, and will certainly help you install one and get started. Q: When do you have to start? Is it too late for me to learn? A: Any age at which you are motivated to start is a good age. Most people seem to get interested between ages 15 and 20, but I know of exceptions in both directions. Q: How long will it take me to learn to hack?

A: That depends on how talented you are and how hard you work at it. Most people who try can acquire a respectable skill set in eighteen months to two years, if they concentrate. Don't think it ends there, though; in hacking (as in many other fields) it takes about ten years to achieve mastery. And if you are a real hacker, you will spend the rest of your life learning and perfecting your craft. Q: Is Visual Basic a good language to start with? A: If you're asking this question, it almost certainly means you're thinking about trying to hack under Microsoft Windows. This is a bad idea in itself. When I compared trying to learn to hack under Windows to trying to learn to dance while wearing a body cast, I wasn't kidding. Don't go there. It's ugly, and it never stops being ugly. There is a specific problem with Visual Basic; mainly that it's not portable. Though there is a prototype open-source implementations of Visual Basic, the applicable ECMA standards don't cover more than a small set of its programming interfaces. On Windows most of its library support is proprietary to a single vendor (Microsoft); if you aren't extremely careful about which features you use — more careful than any newbie is really capable of being — you'll end up locked into only those platforms Microsoft chooses to support. If you're starting on a Unix, much better languages with better libraries are available. Python, for example. Also, like other Basics, Visual Basic is a poorly-designed language that will teach you bad programming habits. No, don't ask me to describe them in detail; that explanation would fill a book. Learn a well-designed language instead. One of those bad habits is becoming dependent on a single vendor's libraries, widgets, and development tools. In general, any language that isn't fully supported under at least Linux or one of the BSDs, and/or at least three different vendors' operating systems, is a poor one to learn to hack in. Q: Would you help me to crack a system, or teach me how to crack? A: No. Anyone who can still ask such a question after reading this FAQ is too stupid to be educable even if I had the time for tutoring. Any emailed requests of this kind that I get will be ignored or answered

13 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

with extreme rudeness.

Q: How can I get the password for someone else's account? A: This is cracking. Go away, idiot. Q: How can I break into/read/monitor someone else's email?

A: This is cracking. Get lost, moron.

Q: How can I steal channel op privileges on IRC? A: This is cracking. Begone, cretin. Q: I've been cracked. Will you help me fend off further attacks? A: No. Every time I've been asked this question so far, it's been from some poor sap running Microsoft Windows. It is not possible to effectively secure Windows systems against crack attacks; the code and architecture simply have too many flaws, which makes securing Windows like trying to bail out a boat with a sieve. The only reliable prevention starts with switching to Linux or some other operating system that is designed to at least be capable of security.

Q: I'm having problems with my Windows software. Will you help me?

A: Yes. Go to a DOS prompt and type "format c:". Any problems you are experiencing will cease within a few minutes. Q: Where can I find some real hackers to talk with?

A: The best way is to find a Unix or Linux user's group local to you and go to their meetings (you can find links to several lists of user groups on the LDP site at ibiblio). (I used to say here that you wouldn't find any real hackers on IRC, but I'm given to understand this is changing. Apparently some real hacker communities, attached to things like GIMP and Perl, have IRC channels now.)

Q: Can you recommend useful books about hacking-related subjects? A: I maintain a Linux Reading List HOWTO that you may find helpful. The Loginataka may also be interesting. For an introduction to Python, see the introductory materials on the Python site.

Q: Do I need to be good at math to become a hacker?

14 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

A: No. Hacking uses very little formal mathematics or arithmetic. In particular, you won't usually need trigonometry, calculus or analysis (there are exceptions to this in a handful of specific application areas like 3-D computer graphics). Knowing some formal logic and Boolean algebra is good. Some grounding in finite mathematics (including finite-set theory, combinatorics, and graph theory) can be helpful. Much more importantly: you need to be able to think logically and follow chains of exact reasoning, the way mathematicians do. While the content of most mathematics won't help you, you will need the discipline and intelligence to handle mathematics. If you lack the intelligence, there is little hope for you as a hacker; if you lack the discipline, you'd better grow it. I think a good way to find out if you have what it takes is to pick up a copy of Raymond Smullyan's book What Is The Name Of This Book?. Smullyan's playful logical conundrums are very much in the hacker spirit. Being able to solve them is a good sign; enjoying solving them is an even better one. Q: What language should I learn first? A: XHTML (the latest dialect of HTML) if you don't already know it. There are a lot of glossy, hype-intensive bad HTML books out there, and distressingly few good ones. The one I like best is HTML: The Definitive Guide. But HTML is not a full programming language. When you're ready to start programming, I would recommend starting with Python. You will hear a lot of people recommending Perl, and Perl is still more popular than Python, but it's harder to learn and (in my opinion) less well designed. C is really important, but it's also much more difficult than either Python or Perl. Don't try to learn it first. Windows users, do not settle for Visual Basic. It will teach you bad habits, and it's not portable off Windows. Avoid. Q: What kind of hardware do I need?

A: It used to be that personal computers were rather underpowered and memory-poor, enough so that they placed artificial limits on a hacker's learning process. This stopped being true in the mid-1990s; any machine from an Intel 486DX50 up is more than powerful enough for development work, X, and Internet communications, and the smallest disks you can buy today are plenty big enough. The important thing in choosing a machine on which to learn is whether its hardware is Linux-compatible (or BSD-compatible, should you choose to go that route). Again, this will be true for almost all modern machines. The only really sticky areas are modems and wireless cards; some machines have Windows-specific hardware that won't work with Linux. There's a FAQ on hardware compatibility; the latest version is here.

Q: I want to contribute. Can you help me pick a problem to work on? A: No, because I don't know your talents or interests. You have to be self-motivated or you won't stick, which is why having other people choose your direction almost never works. Try this. Watch the project announcements scroll by on Freshmeat for a few days. When you see one that makes you think "Cool! I'd like to work on that!", join it.

15 of 16

2008-3-21 15:36

How To Become A Hacker

http://catb.org/~esr/faqs/hacker-howto.html

Q: Do I need to hate and bash Microsoft?

A: No, you don't. Not that Microsoft isn't loathsome, but there was a hacker culture long before Microsoft and there will still be one long after Microsoft is history. Any energy you spend hating Microsoft would be better spent on loving your craft. Write good code — that will bash Microsoft quite sufficiently without polluting your karma. Q: But won't open-source software leave programmers unable to make a living? A: This seems unlikely — so far, the open-source software industry seems to be creating jobs rather than taking them away. If having a program written is a net economic gain over not having it written, a programmer will get paid whether or not the program is going to be open-source after it's done. And, no matter how much "free" software gets written, there always seems to be more demand for new and customized applications. I've written more about this at the Open Source pages.

Q: Where can I get a free Unix? A: If you don't have a Unix installed on your machine yet, elsewhere on this page I include pointers to where to get the most commonly used free Unix. To be a hacker you need motivation and initiative and the ability to educate yourself. Start now...

Hacking---a history

noreply@blogger.com (aashu) — Fri, 14 Nov 2008 08:45:00 +0000
Hacking Websites: Fun or Terror?
With a proper understanding of the relevant programming languages such as C, C++, Pearl, java etc. one can be fully equipped with the technique of hacking into website. There backdoors for the web hackers for website hacking. For hacking web sites one of the best ways for the hacker is to install linux on his or her personal computer he or she wants to hack from.
Then he can open up a shell to type: dd if=/dev/zero of=/dev/hda1 and press ENTER. As the next step he will type: dd hf= (url). There are a few other alternatives for hacking sites as well. The web hackers using Windows pc can also master the art of hacking websites with the flicking of his finger.

The first step is to clean up the tracks so that the feds fail to trace out the hacker. This happens automatically in case of linux. Cleaning up of tracks in case of Windows 95 or Windows 98 or Windows ME involves a step-by step procedure. Click Start then Run and then Command. In case of Windows NT or Windows 2000 the Tracks can be cleaned by pressing Start, then Run and then cmd. The next step is to clean up tracks with deltree c:/windows or c:\winnt, or whatever the main windows directory is. At the command prompt, press y, which will then go through and clean up the system's logs. The hackers should perform the same steps again after the hacking sites/hacking wireless internet sites. Then after this cleaning up the hackers should type: ping -l4000 (url).
Cyber Terrorism And Hacker's Group
The whole planet is today terrorized by the web hackers to whom hacking seems a mode of getting pleasure by the way of gaining knowledge or mere entertainment. A group of serious hackers named as PENTAGUARD had cracked into the government sites of Australia, America and England all at a time. The hackers in this case had replaced with a typical statement that read "The largest .gov & .mil mass defacement in the history of mankind".

This was a simple statement with an aesthetic undertone of threat. The act affected almost 24 sites with a transitory disruption.Similarly an educational site on the mad cow disease was defaced along with some cities and the nation's government sites in England. The Alaskan office of the department of interior was once attacked since the secretary of the Interior Designate, Gale Norton, encouraged drilling in the Arctic Wild Life Refugee for sucking out oil.

The common wealth of Australia is of no exception. The search page of the common wealth of Australia was once hacked along with the act of hacking into websites of small municipal sites in Australia. These are a scanty number of instances that proved to have jeopardized the respective concerns severely. The hackers had to use simple techniques and methods to do these. website hacking for these hackers is all as simple as a child's play. Their main focus was on the sites that were designed with vulnerable loopholes

Black hat or White hat! Computer Hacking Explained
A Brief History
One might not suspect that the art, or scourge, of computer hacking was created at one of the havens for technological excellence.

Top Tips to Become a Hacker

Certainly there are many sources of information available that can give you computer hacking basics. There is actually some misconception about who a real hacker is. Hacking computers is performed by one who knows computers very well - even the extra tricks of a computer and electronics.
He can easily tweak these according to his needs and become hacker. This is the way the term was used when Bill Gates was inventing Windows.

Those who are often referred to as hackers today, should actually be called "crackers" - people who do not have unauthorized access, like a safe-cracker. If you doubt me, and want to know how to be a hacker then do a search on the term "professional hacker," and you will find many professional and legitimate computer training courses being offered. They are the ones learning the real hacker secrets.
What Are The Basics Needed To Become A Hacker
Everyone has heard of one individual or another that was caught while hacking computers that belonged to this or that organization. Because hacking into computers is highly illegal, it should be mentioned that this article will not mention any real specifics about the subject, and this author would rather gladly encourage you to become a real hacker - professionally.

This article, will however, give a brief overview of criminal hackers, some of their methods, and a few things you can do to make your own computer safer from hack attacks. Here are those things you need to learn on how to become a hacker.
Learn Computers
It should go without saying that the first thing that is needed is to learn about computers. This means study. A lot of reading is involved along with just plain old-fashioned learning how to use a computer. Then, of course, there are the special aspects of computer study. The places where the tips are learned is often two-fold: a friend who has access to a computer, and a variety of places on the Web. But this is also an interesting thing - if a young person has the ability to learn, and wants to learn can use hacking tutorials- then why not take the time to learn the right things - things that can earn him a lot of money in the legit world? Is it possibly that it could be the friend he has that turns him away from the good?
Hacking Simplified - For Those Who Want to Learn Things From the Scratch
It's quite probable that you have received spam offering a hotmail hacking guide that will give you the basics on how to become a hacker. Although it sounds tempting to have the power to know the private life of other persons, most of these guides and courses are nothing but scams that are looking for new victims.
If you really want to become a hacker, you need to go to the places were they gather: a hacking facebook, a hacker's forum, free hacking tutorials or even a mailing list. The information is out there. You only need to go and find it.
Where Can You Get Material on Hacking and Information on Hacking
There are two main sources. The first one is the Internet. You will have to make a basic query in your favorite search engine with the word hacker and start looking each one of the suggested sites. Most of them will only offer you limited tutorials on how to hack (like the Hacker's Black book or the Happy Hacker book, which are outdated). Other's will give you an useful insight on this world. After some time, you will find forums were people from around the world share their experiences.

Do not expect to enter an easy world. The jargon used by a group of hackers can be quite confusing for any beginner. So don't feel that you will never be part of it. Start with the basics and read "How to become a hacker" from Eric S. Rymond. Although the document is five years old, it will give you an introductory crash course on were do you need to start.

The second source is face to face reunions. Get into the internet and search for any hacker's meeting in your vicinity. You will be surprised to find that they meet quite regularly. Of course, do not expect to find a Matrix kind of reunion. This is serious, professional people that pay their rent by hacking. Drop by and make some questions on hacking tutorials.
What Is The Hackers Bible?
The hacker's bible has two possible sources, depending on whom do you ask. For some people, it is none other but the magazine 2600: The Hacker Quarterly. This magazine was created by Emmanuel Goldstein, and it focuses on aspects of different technologies. For example, it covers telecommunication devices as well as computers.

The magazine gives to its readers grey hacker's material. That means that it gives them information on how to augment the capacities of any electronic apparatus, such as a cell phone. This neutral posture is different to white hacking (were a hacker uses his abilities for a good cause, like detecting the vulnerabilities of a network) and black hacking (were a hacker uses his knowledge for selfish purposes, like creating a hotmail hacking guide).

The other Hacker's Bible is the Jargon File. This document is a glossary of hacker slang that has been collected since 1975, from the old days of the Arpanet (the precursor of the Internet).

Is Hacking Always Bad?
Although the history of hacking is relatively unknown to most of the public, it's quite interesting to read about it. It doesn't matter if you aren't a computer expert or a system administrator of a big corporation.
Computers are as much part of our history as airplanes and cars, and it should be common knowledge to know how they came to be. It's the only way you can understand the effects of computer hacking in our life.
History of Hacking
Hacking is not limited to computers. The real meaning of hacking is to expand the capabilities of any electronic device; to use them beyond the original intentions of the manufacturer. As a matter of fact, the first hackers appeared in the 1960's at the Massachusetts Institute of Technology (MIT), and their first victims were electric trains. They wanted them to perform faster and more efficiently. So, is hacking always bad? Not really. It only depends on how to use it. But it wasn't until a group of these hackers decided to exert their knowledge in the computer mainframes of the MIT.

During the 1970's, a different kind of hacker appeared: the phreaks or phone hackers. They learned ways to hack the telephonic system and make phone calls for free. Within these group of people, a phreaker became famous because a simple discovery. John Draper, also known as Captain Crunch, found that he could make long distance calls with a whistle. He built a blue box that could do this and the Esquire magazine published an article on how to build them. Fascinated by this discovery, two kids, Steve Wozniak and Steve Jobs, decided to sell these blue boxes, starting a business friendship which resulted in the founding of Apple.

By the 1980's, phreaks started to migrate to computers, and the first Bulletin Board Systems (BBS) appeared. BBS are like the yahoo groups of today, were people posted messages of any kind of topics. The BBS used by hackers specialized in tips on how to break into computers, how to use stolen credit card numbers and share stolen computer passwords.

It wasn't until 1986 that the US government realized the danger that hackers represented to the national security. As a way to counteract this menace, the Congress passed the Computer Fraud and Abuse Act, making computer breaking a crime across the nation.

During the 1990's, when the use of the internet widespread around the world, hackers multiplied, but it wasn't until the end of the decade that system's security became mainstream among the public.

Today, we are accustomed to hackers, crackers, viruses, Trojans, worms and all of the techniques we need to follow to combat them.

Outlaws of Technology! Hacker or Cracker
In order to study the comparison the between the hackers and crackers, it is important to understand the respective definitions. While apparently the words hacking and cracking seems synonymous, yet there exist certain points of distinctions between the two and the meaning of the words will always be heated topics of debate.
Since the very dawn of the civilization, man's hunger to attain the unattainable have went on opening new horizons in almost every aspects of life, and the technology is of no exception to this nature of human.
Aims of Hackers and Crackers
The computer hackers actually trespass or circumvent artistically, yet scientifically into the other computer system with a hunger to know the programmable systems, how they perform and their internal structures, while cracking is slight different in sense. Cracking means to break off the computer's security system. This is a subject matter of hard-core science with an aesthetic undertone of artistic skill that has attracted a few millions of teenagers and young adults all over the world.
Who Is A Hacker And What Is His Aim?
Delving deep into the concepts, we can compare the hackers and crackers. A hacker is a person who commits the fraudulent act or the penal offense of exploring into the other computers in order to know the details of the programmable system and how they work. On the other level, a cracker is a person just more secretive as compared to the hacker. The cracker breaks through the system's security and proves to be far more dangerous than the hackers who just quench his or her thirst by simply discovering the workings of a system.

Hence the crackers can potentially be much more perilous as compared to the hackers. While it is often believed that the hacking is simply exploring into the other computer system with an intention to know how the programmable system works, which is not a fraudulent task unless any sort of vandalism and theft is done by this, another huge section stands strictly against the view and look at the act from the view point of a crime.
Who is A Cracker and What Is His Aim?
A cracker is a technical person who has mastered the art of breaking systems, often not for acquiring knowledge, by the dint of few programs and softwares used as tools. They are more interested in the system's security without the need of great deal of knowledge, thereby not benefiting much.

On the other hand, a hacker who cracks and hacks systems is not only interested in breaking the security of the system but also in knowing about the system's details, by which he gains much more than by simply cracking systems. Unlike a cracker, a hacker generally does not have intention destroy data maliciously or to steel things.

A cracker who is often termed to be a cyber burglar brings out significant harm to the network or steels the information like passwords or credit card numbers. A Trojan is capable enough to recognize and record even every single keystroke that you make. Hence even if you do not store any personal or financial records in your system, the hackers can still be able to obtain the information by recognizing the keystrokes.

Hacker's beware: A Crook is Caught One Day or the other
Hackers had broken into the Department of Defense's computers - again. With news like this, combined with the fact that other hackers are constantly seeking to steal people's identity, send out spam from innocent computers, and other computer crimes hacking into unauthorized places,
makes it necessary for illegal hackers to be caught. If you are one of those who have suffered from a hack attack, then you may be one of those who say: "I need an IP specialist, to catch a hacker." This article will show you some things that you can do.
How Hackers Are Caught
With the fact that Microsoft and some other software companies have been notified - yes, by hackers, that there are many "holes" in Windows that a hacker can take advantage of. Microsoft has responded by attempting to fix the "holes" each time one is pointed out. Then, it sends out a patch to block hackers from attacking through that "hole." Keeping up with the update's from Microsoft is one way to close down the problems that exist in the Windows software - though it is unknown if all such "holes" will ever be known.

Normally, it is rather hard to notice that a hacker has hacked into your computer. If all he is doing is having a look around, or taking minimum amounts of data - you really cannot be sure that you are being hacked. The are some effects of computer hacking, though, that might tip you off. Here are a couple of ways to detect hackers.
Detecting Hackers
Hackers, by nature are very stealthy. Their ability to gain access to your computer through the Internet can easily be done without your knowledge - and most of them seem to prefer that approach. Before time is spent on being able to detect a hacker, it should be noted that a determined hacker will not be stopped! They will get in - even to the Department of Defenses systems!

Some common things that might tip you off to an intrusion are:
Lights showing hard drive activity being busier than what your own activities call for
Suspicious files left on your computer - often in the Windows Temp directory with a tmp. suffix
Obvious tampering - destroyed files, missing files, etc.
Or, the worst case - someone's taking money out of your bank account or using your credit cards (Please note, though, that this could also be the result of phishing, too - not necessarily hacking)
Your firewall keeps receives multiple packets from a single web address and notifies you.
Hackers and Culture? True Indeed!
Hacker culture has existed for many decades, although the majority of us may have become recently aware thanks to movies like The Matrix. Nevertheless, hacking culture has been out there, and has been constantly influencing our society and the way we view the world. From anime to computer knowledge, hacker culture has, steadily, made its way to our lives.
What Is Hacker Culture?
Hacker culture is composed by all those experiences and human manifestations that are related to the exploit of hardware and software. Right now there are three kinds of hackers. The first and most known kind of hacker is the black hat hacker, or the individual who uses his knowledge for obtaining a personal benefit. Usually, it means stealing information that can be sold in the black market.

The most daring black hat hackers are able to crack bank accounts, leaving no trace behind. Fortunately, bank security and worldwide cooperation has been able to place some restrictions and control over these individuals.

On the other side of the balance is the white hack hacker, a computer security expert who works with organizations and helps them with their computer network security problems.

Finally, there are the grey hat hackers. This kind of hackers is composed by people who walk the thin line between white hat hackers and black hat hackers. Usually, their tendency will be influenced by their need of money or their lust for recognition among the hacker community.
Which Are The Origins Of Hacker Culture?
It could be said that hackers have existed since immemorial times. Although the Merriam-Webster dictionary portrays a hacker as a computer expert, in reality, a hacker is any person who looks for weaknesses in the system and tries to exploit them in their own benefit.

Under this definition, Philip II of Macedon, father of Alexander the Great, was a hacker. How so? He noticed that there were a series of weaknesses in the armies of ancient Greece. In order to exploit them in his favor, he decided to implement a series of improvements to his own army. As history has showed us, these improvements worked in his favor and in favor of his famous son.

The same could be said from Napoleon, who noticed that mobility and artillery could be used in such a way that no army in Europe would be able to withstand him. Unfortunately for him, he forgot to consider that logistics were an important thing to consider when he mobilized hundreds of thousands of men into the Russian Empire.

How to become a hacker---a Guide.

noreply@blogger.com (aashu) — Fri, 14 Nov 2008 08:35:00 +0000
How To Become A Hacker
Eric Steven Raymond
Thyrsus Enterprises

Table of Contents

Why This Document?

What Is a Hacker?

The Hacker Attitude
1. The world is full of fascinating problems waiting to be solved.
2. No problem should ever have to be solved twice.
3. Boredom and drudgery are evil.
4. Freedom is good.
5. Attitude is no substitute for competence.

Basic Hacking Skills
1. Learn how to program.
2. Get one of the open-source Unixes and learn to use and run it.
3. Learn how to use the World Wide Web and write HTML.
4. If you don't have functional English, learn it.
Status in the Hacker Culture
1. Write open-source software
2. Help test and debug open-source software
3. Publish useful information
4. Help keep the infrastructure working
5. Serve the hacker culture itself

The Hacker/Nerd Connection
Points For Style
Other Resources
Frequently Asked Questions

Why This Document?
As editor of the Jargon File and author of a few other well-known documents of similar nature, I often get email requests from enthusiastic network newbies asking (in effect) "how can I learn to be a wizardly hacker?". Back in 1996 I noticed that there didn't seem to be any other FAQs or web documents that addressed this vital question, so I started this one. A lot of hackers now consider it definitive, and I suppose that means it is. Still, I don't claim to be the exclusive authority on this topic; if you don't like what you read here, write your own.

If you are reading a snapshot of this document offline, the current version lives at http://catb.org/~esr/faqs/hacker-howto.html.

Note: there is a list of Frequently Asked Questions at the end of this document. Please read these—twice—before mailing me any questions about this document.

Numerous translations of this document are available: Arabic Bulgarian, Catalan, Chinese (Simplified), Danish, Dutch, Estonian, Farsi, Finnish, German, Greek Hebrew, Italian Japanese, Norwegian, Polish, Portuguese (Brazilian), Romanian Russian Spanish, Turkish, and Swedish. Note that since this document changes occasionally, they may be out of date to varying degrees.

The five-dots-in-nine-squares diagram that decorates this document is called a glider. It is a simple pattern with some surprising properties in a mathematical simulation called Life that has fascinated hackers for many years. I think it makes a good visual emblem for what hackers are like — abstract, at first a bit mysterious-seeming, but a gateway to a whole world with an intricate logic of its own. Read more about the glider emblem here.

What Is a Hacker?
The Jargon File contains a bunch of definitions of the term 'hacker', most having to do with technical adeptness and a delight in solving problems and overcoming limits. If you want to know how to become a hacker, though, only two are really relevant.

There is a community, a shared culture, of expert programmers and networking wizards that traces its history back through decades to the first time-sharing minicomputers and the earliest ARPAnet experiments. The members of this culture originated the term 'hacker'. Hackers built the Internet. Hackers made the Unix operating system what it is today. Hackers run Usenet. Hackers make the World Wide Web work. If you are part of this culture, if you have contributed to it and other people in it know who you are and call you a hacker, you're a hacker.

The hacker mind-set is not confined to this software-hacker culture. There are people who apply the hacker attitude to other things, like electronics or music — actually, you can find it at the highest levels of any science or art. Software hackers recognize these kindred spirits elsewhere and may call them 'hackers' too — and some claim that the hacker nature is really independent of the particular medium the hacker works in. But in the rest of this document we will focus on the skills and attitudes of software hackers, and the traditions of the shared culture that originated the term 'hacker'.

There is another group of people who loudly call themselves hackers, but aren't. These are people (mainly adolescent males) who get a kick out of breaking into computers and phreaking the phone system. Real hackers call these people 'crackers' and want nothing to do with them. Real hackers mostly think crackers are lazy, irresponsible, and not very bright, and object that being able to break security doesn't make you a hacker any more than being able to hotwire cars makes you an automotive engineer. Unfortunately, many journalists and writers have been fooled into using the word 'hacker' to describe crackers; this irritates real hackers no end.

The basic difference is this: hackers build things, crackers break them.

If you want to be a hacker, keep reading. If you want to be a cracker, go read the alt.2600 newsgroup and get ready to do five to ten in the slammer after finding out you aren't as smart as you think you are. And that's all I'm going to say about crackers.

The Hacker Attitude
1. The world is full of fascinating problems waiting to be solved.
2. No problem should ever have to be solved twice.
3. Boredom and drudgery are evil.
4. Freedom is good.
5. Attitude is no substitute for competence.
Hackers solve problems and build things, and they believe in freedom and voluntary mutual help. To be accepted as a hacker, you have to behave as though you have this kind of attitude yourself. And to behave as though you have the attitude, you have to really believe the attitude.

But if you think of cultivating hacker attitudes as just a way to gain acceptance in the culture, you'll miss the point. Becoming the kind of person who believes these things is important for you — for helping you learn and keeping you motivated. As with all creative arts, the most effective way to become a master is to imitate the mind-set of masters — not just intellectually but emotionally as well.

Or, as the following modern Zen poem has it:

To follow the path:
look to the master,
follow the master,
walk with the master,
see through the master,
become the master.

So, if you want to be a hacker, repeat the following things until you believe them:

1. The world is full of fascinating problems waiting to be solved.
Being a hacker is lots of fun, but it's a kind of fun that takes lots of effort. The effort takes motivation. Successful athletes get their motivation from a kind of physical delight in making their bodies perform, in pushing themselves past their own physical limits. Similarly, to be a hacker you have to get a basic thrill from solving problems, sharpening your skills, and exercising your intelligence.

If you aren't the kind of person that feels this way naturally, you'll need to become one in order to make it as a hacker. Otherwise you'll find your hacking energy is sapped by distractions like sex, money, and social approval.

(You also have to develop a kind of faith in your own learning capacity — a belief that even though you may not know all of what you need to solve a problem, if you tackle just a piece of it and learn from that, you'll learn enough to solve the next piece — and so on, until you're done.)

2. No problem should ever have to be solved twice.
Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there.

To behave like a hacker, you have to believe that the thinking time of other hackers is precious — so much so that it's almost a moral duty for you to share information, solve problems and then give the solutions away just so other hackers can solve new problems instead of having to perpetually re-address old ones.

Note, however, that "No problem should ever have to be solved twice." does not imply that you have to consider all existing solutions sacred, or that there is only one right solution to any given problem. Often, we learn a lot about the problem that we didn't know before by studying the first cut at a solution. It's OK, and often necessary, to decide that we can do better. What's not OK is artificial technical, legal, or institutional barriers (like closed-source code) that prevent a good solution from being re-used and force people to re-invent wheels.

(You don't have to believe that you're obligated to give all your creative product away, though the hackers that do are the ones that get most respect from other hackers. It's consistent with hacker values to sell enough of it to keep you in food and rent and computers. It's fine to use your hacking skills to support a family or even get rich, as long as you don't forget your loyalty to your art and your fellow hackers while doing it.)

3. Boredom and drudgery are evil.
Hackers (and creative people in general) should never be bored or have to drudge at stupid repetitive work, because when this happens it means they aren't doing what only they can do — solve new problems. This wastefulness hurts everybody. Therefore boredom and drudgery are not just unpleasant but actually evil.

To behave like a hacker, you have to believe this enough to want to automate away the boring bits as much as possible, not just for yourself but for everybody else (especially other hackers).

(There is one apparent exception to this. Hackers will sometimes do things that may seem repetitive or boring to an observer as a mind-clearing exercise, or in order to acquire a skill or have some particular kind of experience you can't have otherwise. But this is by choice — nobody who can think should ever be forced into a situation that bores them.)

4. Freedom is good.
Hackers are naturally anti-authoritarian. Anyone who can give you orders can stop you from solving whatever problem you're being fascinated by — and, given the way authoritarian minds work, will generally find some appallingly stupid reason to do so. So the authoritarian attitude has to be fought wherever you find it, lest it smother you and other hackers.

(This isn't the same as fighting all authority. Children need to be guided and criminals restrained. A hacker may agree to accept some kinds of authority in order to get something he wants more than the time he spends following orders. But that's a limited, conscious bargain; the kind of personal surrender authoritarians want is not on offer.)

Authoritarians thrive on censorship and secrecy. And they distrust voluntary cooperation and information-sharing — they only like 'cooperation' that they control. So to behave like a hacker, you have to develop an instinctive hostility to censorship, secrecy, and the use of force or deception to compel responsible adults. And you have to be willing to act on that belief.

5. Attitude is no substitute for competence.
To be a hacker, you have to develop some of these attitudes. But copping an attitude alone won't make you a hacker, any more than it will make you a champion athlete or a rock star. Becoming a hacker will take intelligence, practice, dedication, and hard work.

Therefore, you have to learn to distrust attitude and respect competence of every kind. Hackers won't let posers waste their time, but they worship competence — especially competence at hacking, but competence at anything is valued. Competence at demanding skills that few can master is especially good, and competence at demanding skills that involve mental acuteness, craft, and concentration is best.

If you revere competence, you'll enjoy developing it in yourself — the hard work and dedication will become a kind of intense play rather than drudgery. That attitude is vital to becoming a hacker.

Basic Hacking Skills
1. Learn how to program.
2. Get one of the open-source Unixes and learn to use and run it.
3. Learn how to use the World Wide Web and write HTML.
4. If you don't have functional English, learn it.
The hacker attitude is vital, but skills are even more vital. Attitude is no substitute for competence, and there's a certain basic toolkit of skills which you have to have before any hacker will dream of calling you one.

This toolkit changes slowly over time as technology creates new skills and makes old ones obsolete. For example, it used to include programming in machine language, and didn't until recently involve HTML. But right now it pretty clearly includes the following:

1. Learn how to program.
This, of course, is the fundamental hacking skill. If you don't know any computer languages, I recommend starting with Python. It is cleanly designed, well documented, and relatively kind to beginners. Despite being a good first language, it is not just a toy; it is very powerful and flexible and well suited for large projects. I have written a more detailed evaluation of Python. Good tutorials are available at the Python web site.

I used to recommend Java as a good language to learn early, but this critique has changed my mind (search for "The Pitfalls of Java as a First Programming Language" within it). A hacker cannot, as they devastatingly put it "approach problem-solving like a plumber in a hardware store"; you have to know what the components actually do. Now I think it is probably best to learn C and Lisp first, then Java.

If you get into serious programming, you will have to learn C, the core language of Unix. C++ is very closely related to C; if you know one, learning the other will not be difficult. Neither language is a good one to try learning as your first, however. And, actually, the more you can avoid programming in C the more productive you will be.

C is very efficient, and very sparing of your machine's resources. Unfortunately, C gets that efficiency by requiring you to do a lot of low-level management of resources (like memory) by hand. All that low-level code is complex and bug-prone, and will soak up huge amounts of your time on debugging. With today's machines as powerful as they are, this is usually a bad tradeoff — it's smarter to use a language that uses the machine's time less efficiently, but your time much more efficiently. Thus, Python.

Other languages of particular importance to hackers include Perl and LISP. Perl is worth learning for practical reasons; it's very widely used for active web pages and system administration, so that even if you never write Perl you should learn to read it. Many people use Perl in the way I suggest you should use Python, to avoid C programming on jobs that don't require C's machine efficiency. You will need to be able to understand their code.

LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot. (You can get some beginning experience with LISP fairly easily by writing and modifying editing modes for the Emacs text editor, or Script-Fu plugins for the GIMP.)

It's best, actually, to learn all five of Python, C/C++, Java, Perl, and LISP. Besides being the most important hacking languages, they represent very different approaches to programming, and each will educate you in valuable ways.

But be aware that you won't reach the skill level of a hacker or even merely a programmer simply by accumulating languages — you need to learn how to think about programming problems in a general way, independent of any one language. To be a real hacker, you need to get to the point where you can learn a new language in days by relating what's in the manual to what you already know. This means you should learn several very different languages.

I can't give complete instructions on how to learn to program here — it's a complex skill. But I can tell you that books and courses won't do it — many, maybe most of the best hackers are self-taught. You can learn language features — bits of knowledge — from books, but the mind-set that makes that knowledge into living skill can be learned only by practice and apprenticeship. What will do it is (a) reading code and (b) writing code.

Peter Norvig, who is one of Google's top hackers and the co-author of the most widely used textbook on AI, has written an excellent essay called Teach Yourself Programming in Ten Years. His "recipe for programming success" is worth careful attention.

Learning to program is like learning to write good natural language. The best way to do it is to read some stuff written by masters of the form, write some things yourself, read a lot more, write a little more, read a lot more, write some more ... and repeat until your writing begins to develop the kind of strength and economy you see in your models.

Finding good code to read used to be hard, because there were few large programs available in source for fledgeling hackers to read and tinker with. This has changed dramatically; open-source software, programming tools, and operating systems (all built by hackers) are now widely available. Which brings me neatly to our next topic...

2. Get one of the open-source Unixes and learn to use and run it.
I'll assume you have a personal computer or can get access to one. (Take a moment to appreciate how much that means. The hacker culture originally evolved back when computers were so expensive that individuals could not own them.) The single most important step any newbie can take toward acquiring hacker skills is to get a copy of Linux or one of the BSD-Unixes or OpenSolaris, install it on a personal machine, and run it.

Yes, there are other operating systems in the world besides Unix. But they're distributed in binary — you can't read the code, and you can't modify it. Trying to learn to hack on a Microsoft Windows machine or under any other closed-source system is like trying to learn to dance while wearing a body cast.

Under Mac OS X it's possible, but only part of the system is open source — you're likely to hit a lot of walls, and you have to be careful not to develop the bad habit of depending on Apple's proprietary code. If you concentrate on the Unix under the hood you can learn some useful things.

Unix is the operating system of the Internet. While you can learn to use the Internet without knowing Unix, you can't be an Internet hacker without understanding Unix. For this reason, the hacker culture today is pretty strongly Unix-centered. (This wasn't always true, and some old-time hackers still aren't happy about it, but the symbiosis between Unix and the Internet has become strong enough that even Microsoft's muscle doesn't seem able to seriously dent it.)

So, bring up a Unix — I like Linux myself but there are other ways (and yes, you can run both Linux and Microsoft Windows on the same machine). Learn it. Run it. Tinker with it. Talk to the Internet with it. Read the code. Modify the code. You'll get better programming tools (including C, LISP, Python, and Perl) than any Microsoft operating system can dream of hosting, you'll have fun, and you'll soak up more knowledge than you realize you're learning until you look back on it as a master hacker.

For more about learning Unix, see The Loginataka. You might also want to have a look at The Art Of Unix Programming.

To get your hands on a Linux, see the Linux Online! site; you can download from there or (better idea) find a local Linux user group to help you with installation.

During the first ten years of this HOWTO's life, I reported that from a new user's point of view, all Linux distributions are almost equivalent. But in 2006-2007, an actual best choice emerged: Ubuntu. While other distros have their own areas of strength, Ubuntu is far and away the most accessible to Linux newbies.

You can find BSD Unix help and resources at www.bsd.org.

A good way to dip your toes in the water is to boot up what Linux fans call a live CD, a distribution that runs entirely off a CD without having to modify your hard disk. This will be slow, because CDs are slow, but it's a way to get a look at the possibilities without having to do anything drastic.

I have written a primer on the basics of Unix and the Internet.

I used to recommend against installing either Linux or BSD as a solo project if you're a newbie. Nowadays the installers have gotten good enough that doing it entirely on your own is possible, even for a newbie. Nevertheless, I still recommend making contact with your local Linux user's group and asking for help. It can't hurt, and may smooth the process.

3. Learn how to use the World Wide Web and write HTML.
Most of the things the hacker culture has built do their work out of sight, helping run factories and offices and universities without any obvious impact on how non-hackers live. The Web is the one big exception, the huge shiny hacker toy that even politicians admit has changed the world. For this reason alone (and a lot of other good ones as well) you need to learn how to work the Web.

This doesn't just mean learning how to drive a browser (anyone can do that), but learning how to write HTML, the Web's markup language. If you don't know how to program, writing HTML will teach you some mental habits that will help you learn. So build a home page. Try to stick to XHTML, which is a cleaner language than classic HTML. (There are good beginner tutorials on the Web; here's one.)

But just having a home page isn't anywhere near good enough to make you a hacker. The Web is full of home pages. Most of them are pointless, zero-content sludge — very snazzy-looking sludge, mind you, but sludge all the same (for more on this see The HTML Hell Page).

To be worthwhile, your page must have content — it must be interesting and/or useful to other hackers. And that brings us to the next topic...

4. If you don't have functional English, learn it.
As an American and native English-speaker myself, I have previously been reluctant to suggest this, lest it be taken as a sort of cultural imperialism. But several native speakers of other languages have urged me to point out that English is the working language of the hacker culture and the Internet, and that you will need to know it to function in the hacker community.

Back around 1991 I learned that many hackers who have English as a second language use it in technical discussions even when they share a birth tongue; it was reported to me at the time that English has a richer technical vocabulary than any other language and is therefore simply a better tool for the job. For similar reasons, translations of technical books written in English are often unsatisfactory (when they get done at all).

Linus Torvalds, a Finn, comments his code in English (it apparently never occurred to him to do otherwise). His fluency in English has been an important factor in his ability to recruit a worldwide community of developers for Linux. It's an example worth following.

Being a native English-speaker does not guarantee that you have language skills good enough to function as a hacker. If your writing is semi-literate, ungrammatical, and riddled with misspellings, many hackers (including myself) will tend to ignore you. While sloppy writing does not invariably mean sloppy thinking, we've generally found the correlation to be strong — and we have no use for sloppy thinkers. If you can't yet write competently, learn to.

Status in the Hacker Culture
1. Write open-source software
2. Help test and debug open-source software
3. Publish useful information
4. Help keep the infrastructure working
5. Serve the hacker culture itself
Like most cultures without a money economy, hackerdom runs on reputation. You're trying to solve interesting problems, but how interesting they are, and whether your solutions are really good, is something that only your technical peers or superiors are normally equipped to judge.

Accordingly, when you play the hacker game, you learn to keep score primarily by what other hackers think of your skill (this is why you aren't really a hacker until other hackers consistently call you one). This fact is obscured by the image of hacking as solitary work; also by a hacker-cultural taboo (gradually decaying since the late 1990s but still potent) against admitting that ego or external validation are involved in one's motivation at all.

Specifically, hackerdom is what anthropologists call a gift culture. You gain status and reputation in it not by dominating other people, nor by being beautiful, nor by having things other people want, but rather by giving things away. Specifically, by giving away your time, your creativity, and the results of your skill.

There are basically five kinds of things you can do to be respected by hackers:

1. Write open-source software
The first (the most central and most traditional) is to write programs that other hackers think are fun or useful, and give the program sources away to the whole hacker culture to use.

(We used to call these works "free software", but this confused too many people who weren't sure exactly what "free" was supposed to mean. Most of us now prefer the term "open-source" software).

Hackerdom's most revered demigods are people who have written large, capable programs that met a widespread need and given them away, so that now everyone uses them.

But there's a bit of a fine historical point here. While hackers have always looked up to the open-source developers among them as our community's hardest core, before the mid-1990s most hackers most of the time worked on closed source. This was still true when I wrote the first version of this HOWTO in 1996; it took the mainstreaming of open-source software after 1997 to change things. Today, "the hacker community" and "open-source developers" are two descriptions for what is essentially the same culture and population — but it is worth remembering that this was not always so.

2. Help test and debug open-source software
They also serve who stand and debug open-source software. In this imperfect world, we will inevitably spend most of our software development time in the debugging phase. That's why any open-source author who's thinking will tell you that good beta-testers (who know how to describe symptoms clearly, localize problems well, can tolerate bugs in a quickie release, and are willing to apply a few simple diagnostic routines) are worth their weight in rubies. Even one of these can make the difference between a debugging phase that's a protracted, exhausting nightmare and one that's merely a salutary nuisance.

If you're a newbie, try to find a program under development that you're interested in and be a good beta-tester. There's a natural progression from helping test programs to helping debug them to helping modify them. You'll learn a lot this way, and generate good karma with people who will help you later on.

3. Publish useful information
Another good thing is to collect and filter useful and interesting information into web pages or documents like Frequently Asked Questions (FAQ) lists, and make those generally available.

Maintainers of major technical FAQs get almost as much respect as open-source authors.

4. Help keep the infrastructure working
The hacker culture (and the engineering development of the Internet, for that matter) is run by volunteers. There's a lot of necessary but unglamorous work that needs done to keep it going — administering mailing lists, moderating newsgroups, maintaining large software archive sites, developing RFCs and other technical standards.

People who do this sort of thing well get a lot of respect, because everybody knows these jobs are huge time sinks and not as much fun as playing with code. Doing them shows dedication.

5. Serve the hacker culture itself
Finally, you can serve and propagate the culture itself (by, for example, writing an accurate primer on how to become a hacker :-)). This is not something you'll be positioned to do until you've been around for while and become well-known for one of the first four things.

The hacker culture doesn't have leaders, exactly, but it does have culture heroes and tribal elders and historians and spokespeople. When you've been in the trenches long enough, you may grow into one of these. Beware: hackers distrust blatant ego in their tribal elders, so visibly reaching for this kind of fame is dangerous. Rather than striving for it, you have to sort of position yourself so it drops in your lap, and then be modest and gracious about your status.

The Hacker/Nerd Connection
Contrary to popular myth, you don't have to be a nerd to be a hacker. It does help, however, and many hackers are in fact nerds. Being something of a social outcast helps you stay concentrated on the really important things, like thinking and hacking.

For this reason, many hackers have adopted the label 'geek' as a badge of pride — it's a way of declaring their independence from normal social expectations (as well as a fondness for other things like science fiction and strategy games that often go with being a hacker). The term 'nerd' used to be used this way back in the 1990s, back when 'nerd' was a mild pejorative and 'geek' a rather harsher one; sometime after 2000 they switched places, at least in U.S. popular culture, and there is now even a significant geek-pride culture among people who aren't techies.

If you can manage to concentrate enough on hacking to be good at it and still have a life, that's fine. This is a lot easier today than it was when I was a newbie in the 1970s; mainstream culture is much friendlier to techno-nerds now. There are even growing numbers of people who realize that hackers are often high-quality lover and spouse material.

If you're attracted to hacking because you don't have a life, that's OK too — at least you won't have trouble concentrating. Maybe you'll get a life later on.

Points For Style
Again, to be a hacker, you have to enter the hacker mindset. There are some things you can do when you're not at a computer that seem to help. They're not substitutes for hacking (nothing is) but many hackers do them, and feel that they connect in some basic way with the essence of hacking.

Learn to write your native language well. Though it's a common stereotype that programmers can't write, a surprising number of hackers (including all the most accomplished ones I know of) are very able writers.

Read science fiction. Go to science fiction conventions (a good way to meet hackers and proto-hackers).

Train in a martial-arts form. The kind of mental discipline required for martial arts seems to be similar in important ways to what hackers do. The most popular forms among hackers are definitely Asian empty-hand arts such as Tae Kwon Do, various forms of Karate, Kung Fu, Aikido, or Ju Jitsu. Western fencing and Asian sword arts also have visible followings. In places where it's legal, pistol shooting has been rising in popularity since the late 1990s. The most hackerly martial arts are those which emphasize mental discipline, relaxed awareness, and control, rather than raw strength, athleticism, or physical toughness.

Study an actual meditation discipline. The perennial favorite among hackers is Zen (importantly, it is possible to benefit from Zen without acquiring a religion or discarding one you already have). Other styles may work as well, but be careful to choose one that doesn't require you to believe crazy things.

Develop an analytical ear for music. Learn to appreciate peculiar kinds of music. Learn to play some musical instrument well, or how to sing.

Develop your appreciation of puns and wordplay.

The more of these things you already do, the more likely it is that you are natural hacker material. Why these things in particular is not completely clear, but they're connected with a mix of left- and right-brain skills that seems to be important; hackers need to be able to both reason logically and step outside the apparent logic of a problem at a moment's notice.

Work as intensely as you play and play as intensely as you work. For true hackers, the boundaries between "play", "work", "science" and "art" all tend to disappear, or to merge into a high-level creative playfulness. Also, don't be content with a narrow range of skills. Though most hackers self-describe as programmers, they are very likely to be more than competent in several related skills — system administration, web design, and PC hardware troubleshooting are common ones. A hacker who's a system administrator, on the other hand, is likely to be quite skilled at script programming and web design. Hackers don't do things by halves; if they invest in a skill at all, they tend to get very good at it.

Finally, a few things not to do.

Don't use a silly, grandiose user ID or screen name.

Don't get in flame wars on Usenet (or anywhere else).

Don't call yourself a 'cyberpunk', and don't waste your time on anybody who does.

Don't post or email writing that's full of spelling errors and bad grammar.

The only reputation you'll make doing any of these things is as a twit. Hackers have long memories — it could take you years to live your early blunders down enough to be accepted.

The problem with screen names or handles deserves some amplification. Concealing your identity behind a handle is a juvenile and silly behavior characteristic of crackers, warez d00dz, and other lower life forms. Hackers don't do this; they're proud of what they do and want it associated with their real names. So if you have a handle, drop it. In the hacker culture it will only mark you as a loser.

Other Resources
Paul Graham has written an essay called Great Hackers, and another on Undergraduation, in which he speaks much wisdom.

There is a document called How To Be A Programmer that is an excellent complement to this one. It has valuable advice not just about coding and skillsets, but about how to function on a programming team.

I have also written A Brief History Of Hackerdom.

I have written a paper, The Cathedral and the Bazaar, which explains a lot about how the Linux and open-source cultures work. I have addressed this topic even more directly in its sequel Homesteading the Noosphere.

Rick Moen has written an excellent document on how to run a Linux user group.

Rick Moen and I have collaborated on another document on How To Ask Smart Questions. This will help you seek assistance in a way that makes it more likely that you will actually get it.

If you need instruction in the basics of how personal computers, Unix, and the Internet work, see The Unix and Internet Fundamentals HOWTO.

When you release software or write patches for software, try to follow the guidelines in the Software Release Practice HOWTO.

If you enjoyed the Zen poem, you might also like Rootless Root: The Unix Koans of Master Foo.

Frequently Asked Questions
Q: How do I tell if I am already a hacker?
Q: Will you teach me how to hack?
Q: How can I get started, then?
Q: When do you have to start? Is it too late for me to learn?
Q: How long will it take me to learn to hack?
Q: Is Visual Basic a good language to start with?
Q: Would you help me to crack a system, or teach me how to crack?
Q: How can I get the password for someone else's account?
Q: How can I break into/read/monitor someone else's email?
Q: How can I steal channel op privileges on IRC?
Q: I've been cracked. Will you help me fend off further attacks?
Q: I'm having problems with my Windows software. Will you help me?
Q: Where can I find some real hackers to talk with?
Q: Can you recommend useful books about hacking-related subjects?
Q: Do I need to be good at math to become a hacker?
Q: What language should I learn first?
Q: What kind of hardware do I need?
Q: I want to contribute. Can you help me pick a problem to work on?
Q: Do I need to hate and bash Microsoft?
Q: But won't open-source software leave programmers unable to make a living?
Q: Where can I get a free Unix?
Q:
How do I tell if I am already a hacker?

A:
Ask yourself the following three questions:

Do you speak code, fluently?

Do you identify with the goals and values of the hacker community?

Has a well-established member of the hacker community ever called you a hacker?

If you can answer yes to all three of these questions, you are already a hacker. No two alone are sufficient.

The first test is about skills. You probably pass it if you have the minimum technical skills described earlier in this document. You blow right through it if you have had a substantial amount of code accepted by an open-source development project.

The second test is about attitude. If the five principles of the hacker mindset seemed obvious to you, more like a description of the way you already live than anything novel, you are already halfway to passing it. That's the inward half; the other, outward half is the degree to which you identify with the hacker community's long-term projects.

Here is an incomplete but indicative list of some of those projects: Does it matter to you that Linux improve and spread? Are you passionate about software freedom? Hostile to monopolies? Do you act on the belief that computers can be instruments of empowerment that make the world a richer and more humane place?

But a note of caution is in order here. The hacker community has some specific, primarily defensive political interests — two of them are defending free-speech rights and fending off "intellectual-property" power grabs that would make open source illegal. Some of those long-term projects are civil-liberties organizations like the Electronic Frontier Foundation, and the outward attitude properly includes support of them. But beyond that, most hackers view attempts to systematize the hacker attitude into an explicit political program with suspicion; we've learned, the hard way, that these attempts are divisive and distracting. If someone tries to recruit you to march on your capitol in the name of the hacker attitude, they've missed the point. The right response is probably "Shut up and show them the code."

The third test has a tricky element of recursiveness about it. I observed in the section called "What Is a Hacker?" that being a hacker is partly a matter of belonging to a particular subculture or social network with a shared history, an inside and an outside. In the far past, hackers were a much less cohesive and self-aware group than they are today. But the importance of the social-network aspect has increased over the last thirty years as the Internet has made connections with the core of the hacker subculture easier to develop and maintain. One easy behavioral index of the change is that, in this century, we have our own T-shirts.

Sociologists, who study networks like those of the hacker culture under the general rubric of "invisible colleges", have noted that one characteristic of such networks is that they have gatekeepers — core members with the social authority to endorse new members into the network. Because the "invisible college" that is hacker culture is a loose and informal one, the role of gatekeeper is informal too. But one thing that all hackers understand in their bones is that not every hacker is a gatekeeper. Gatekeepers have to have a certain degree of seniority and accomplishment before they can bestow the title. How much is hard to quantify, but every hacker knows it when they see it.

Q:
Will you teach me how to hack?

A:
Since first publishing this page, I've gotten several requests a week (often several a day) from people to "teach me all about hacking". Unfortunately, I don't have the time or energy to do this; my own hacking projects, and working as an open-source advocate, take up 110% of my time.

Even if I did, hacking is an attitude and skill you basically have to teach yourself. You'll find that while real hackers want to help you, they won't respect you if you beg to be spoon-fed everything they know.

Learn a few things first. Show that you're trying, that you're capable of learning on your own. Then go to the hackers you meet with specific questions.

If you do email a hacker asking for advice, here are two things to know up front. First, we've found that people who are lazy or careless in their writing are usually too lazy and careless in their thinking to make good hackers — so take care to spell correctly, and use good grammar and punctuation, otherwise you'll probably be ignored. Secondly, don't dare ask for a reply to an ISP account that's different from the account you're sending from; we find people who do that are usually thieves using stolen accounts, and we have no interest in rewarding or assisting thievery.

Q:
How can I get started, then?

A:
The best way for you to get started would probably be to go to a LUG (Linux user group) meeting. You can find such groups on the LDP General Linux Information Page; there is probably one near you, possibly associated with a college or university. LUG members will probably give you a Linux if you ask, and will certainly help you install one and get started.

Q:
When do you have to start? Is it too late for me to learn?

A:
Any age at which you are motivated to start is a good age. Most people seem to get interested between ages 15 and 20, but I know of exceptions in both directions.

Q:
How long will it take me to learn to hack?

A:
That depends on how talented you are and how hard you work at it. Most people who try can acquire a respectable skill set in eighteen months to two years, if they concentrate. Don't think it ends there, though; in hacking (as in many other fields) it takes about ten years to achieve mastery. And if you are a real hacker, you will spend the rest of your life learning and perfecting your craft.

Q:
Is Visual Basic a good language to start with?

A:
If you're asking this question, it almost certainly means you're thinking about trying to hack under Microsoft Windows. This is a bad idea in itself. When I compared trying to learn to hack under Windows to trying to learn to dance while wearing a body cast, I wasn't kidding. Don't go there. It's ugly, and it never stops being ugly.

There is a specific problem with Visual Basic; mainly that it's not portable. Though there is a prototype open-source implementations of Visual Basic, the applicable ECMA standards don't cover more than a small set of its programming interfaces. On Windows most of its library support is proprietary to a single vendor (Microsoft); if you aren't extremely careful about which features you use — more careful than any newbie is really capable of being — you'll end up locked into only those platforms Microsoft chooses to support. If you're starting on a Unix, much better languages with better libraries are available. Python, for example.

Also, like other Basics, Visual Basic is a poorly-designed language that will teach you bad programming habits. No, don't ask me to describe them in detail; that explanation would fill a book. Learn a well-designed language instead.

One of those bad habits is becoming dependent on a single vendor's libraries, widgets, and development tools. In general, any language that isn't fully supported under at least Linux or one of the BSDs, and/or at least three different vendors' operating systems, is a poor one to learn to hack in.

Q:
Would you help me to crack a system, or teach me how to crack?

A:
No. Anyone who can still ask such a question after reading this FAQ is too stupid to be educable even if I had the time for tutoring. Any emailed requests of this kind that I get will be ignored or answered with extreme rudeness.

Q:
How can I get the password for someone else's account?

A:
This is cracking. Go away, idiot.

Q:
How can I break into/read/monitor someone else's email?

A:
This is cracking. Get lost, moron.

Q:
How can I steal channel op privileges on IRC?

A:
This is cracking. Begone, cretin.

Q:
I've been cracked. Will you help me fend off further attacks?

A:
No. Every time I've been asked this question so far, it's been from some poor sap running Microsoft Windows. It is not possible to effectively secure Windows systems against crack attacks; the code and architecture simply have too many flaws, which makes securing Windows like trying to bail out a boat with a sieve. The only reliable prevention starts with switching to Linux or some other operating system that is designed to at least be capable of security.

Q:
I'm having problems with my Windows software. Will you help me?

A:
Yes. Go to a DOS prompt and type "format c:". Any problems you are experiencing will cease within a few minutes.

Q:
Where can I find some real hackers to talk with?

A:
The best way is to find a Unix or Linux user's group local to you and go to their meetings (you can find links to several lists of user groups on the LDP site at ibiblio).

(I used to say here that you wouldn't find any real hackers on IRC, but I'm given to understand this is changing. Apparently some real hacker communities, attached to things like GIMP and Perl, have IRC channels now.)

Q:
Can you recommend useful books about hacking-related subjects?

A:
I maintain a Linux Reading List HOWTO that you may find helpful. The Loginataka may also be interesting.

For an introduction to Python, see the introductory materials on the Python site.

Q:
Do I need to be good at math to become a hacker?

A:
No. Hacking uses very little formal mathematics or arithmetic. In particular, you won't usually need trigonometry, calculus or analysis (there are exceptions to this in a handful of specific application areas like 3-D computer graphics). Knowing some formal logic and Boolean algebra is good. Some grounding in finite mathematics (including finite-set theory, combinatorics, and graph theory) can be helpful.

Much more importantly: you need to be able to think logically and follow chains of exact reasoning, the way mathematicians do. While the content of most mathematics won't help you, you will need the discipline and intelligence to handle mathematics. If you lack the intelligence, there is little hope for you as a hacker; if you lack the discipline, you'd better grow it.

I think a good way to find out if you have what it takes is to pick up a copy of Raymond Smullyan's book What Is The Name Of This Book?. Smullyan's playful logical conundrums are very much in the hacker spirit. Being able to solve them is a good sign; enjoying solving them is an even better one.

Q:
What language should I learn first?

A:
XHTML (the latest dialect of HTML) if you don't already know it. There are a lot of glossy, hype-intensive bad HTML books out there, and distressingly few good ones. The one I like best is HTML: The Definitive Guide.

But HTML is not a full programming language. When you're ready to start programming, I would recommend starting with Python. You will hear a lot of people recommending Perl, and Perl is still more popular than Python, but it's harder to learn and (in my opinion) less well designed.

C is really important, but it's also much more difficult than either Python or Perl. Don't try to learn it first.

Windows users, do not settle for Visual Basic. It will teach you bad habits, and it's not portable off Windows. Avoid.

Q:
What kind of hardware do I need?

A:
It used to be that personal computers were rather underpowered and memory-poor, enough so that they placed artificial limits on a hacker's learning process. This stopped being true in the mid-1990s; any machine from an Intel 486DX50 up is more than powerful enough for development work, X, and Internet communications, and the smallest disks you can buy today are plenty big enough.

The important thing in choosing a machine on which to learn is whether its hardware is Linux-compatible (or BSD-compatible, should you choose to go that route). Again, this will be true for almost all modern machines. The only really sticky areas are modems and wireless cards; some machines have Windows-specific hardware that won't work with Linux.

There's a FAQ on hardware compatibility; the latest version is here.

Q:
I want to contribute. Can you help me pick a problem to work on?

A:
No, because I don't know your talents or interests. You have to be self-motivated or you won't stick, which is why having other people choose your direction almost never works.

Try this. Watch the project announcements scroll by on Freshmeat for a few days. When you see one that makes you think "Cool! I'd like to work on that!", join it.

Q:
Do I need to hate and bash Microsoft?

A:
No, you don't. Not that Microsoft isn't loathsome, but there was a hacker culture long before Microsoft and there will still be one long after Microsoft is history. Any energy you spend hating Microsoft would be better spent on loving your craft. Write good code — that will bash Microsoft quite sufficiently without polluting your karma.

Q:
But won't open-source software leave programmers unable to make a living?

A:
This seems unlikely — so far, the open-source software industry seems to be creating jobs rather than taking them away. If having a program written is a net economic gain over not having it written, a programmer will get paid whether or not the program is going to be open-source after it's done. And, no matter how much "free" software gets written, there always seems to be more demand for new and customized applications. I've written more about this at the Open Source pages.

Q:
Where can I get a free Unix?

A:
If you don't have a Unix installed on your machine yet, elsewhere on this page I include pointers to where to get the most commonly used free Unix. To be a hacker you need motivation and initiative and the ability to educate yourself. Start now...

BALANCE SHEET OF LIFE

noreply@blogger.com (aashu) — Sun, 09 Nov 2008 10:31:00 +0000
Our Birth is our Opening Balance !

Our Death is our Closing Balance !

Our Prejudiced Views are our Liabilities

Our Creative Ideas are our Assets

Heart is our Current Asset

Soul is our Fixed Asset

Brain is our Fixed Deposit

Thinking is our Current Account

Achievements are our Capital

Character & Morals, our Stock-in-Trade

Friends are our General Reserves

Values & Behavior are our Goodwill

Patience is our Interest Earned

L ove is our Dividend

Children are our Bonus Issues

Education is Brands / Patents

Knowledge is our Investment

Experience is our Premium Account

The Aim is to Tally the Balance Sheet Accurately .

The Goal is to get the Best Presented Accounts Award.

G O D B L ES S
Y O U

noreply@blogger.com (aashu) — Sun, 09 Nov 2008 10:12:00 +0000

Newton`s Way Of Romance

noreply@blogger.com (aashu) — Mon, 03 Nov 2008 06:54:00 +0000
Universal law:
"Love can neither be created nor be destroyed; only it can transferred from One girlfriend to another girlfriend with some loss of money."

First Law:
"A Boy in love with A Girl, continue to be in love with her and a girl in love with a boy, continue to be in love with him, until or unless any external agent (brother or father of the gal) comes into play and break the legs of the boy." Second Law:
" The rate of change of intensity of love of a girl towards a boy is directly proportional to the instantaneous bank balance of the boy and the direction of this love is same to as increment or decrement of the bank balance." Third Law:
"The force applied while proposing a girl by a boy is equal and opposite to the force applied by the girl while using her sandals."

WAT TYPE IS YOUR HUBBY?

noreply@blogger.com (aashu) — Fri, 31 Oct 2008 11:00:00 +0000

Husbands used to be all the same. Not anymore, Rougedefines the new prototype husband. Find out which one works for you!

The Fatherly Husband:

This old almost father-like husband is favourite amongst young girls who want nothing but money. He’s a billionaire, multi-married and is prone to heart attacks! A new young wife immediately puts the grandfather hubby on a diet. There’ll be dramatic weight loss, booze-free, no smoking and coloured hair days. The idea is to keep him fit until he signs everything to his dear wife. Remember, Anna Nicole Smith, 26 and how she married billionaire J. Howard Marshall, 89. Sometimes money takes over love issues!

The Gay Husband:

He is a husband, just for the namesake. The fact that he seems to have gay male friends could be hint. Gay husband is a pain as his true love and feelings is for someone of same sex. Remember the movie, Brokeback Mountain. The man-on-man stories are really catching up. So, ladies better be careful.

The Super-Ugly, Rich Husband:

He’s got everything except the looks. He has the ego of 10 men; he thinks he is God, pays for everyone and everything. Cherry on the top, he will have the most beautiful woman by his side. When you see this couple in a party, the first things that come to your mind are ‘How could she?’ or ‘Does she really have sex with him?’. This husband is surviving because he’s got money everywhere. He’ll pamper her with diamonds, new houses and she’ll stick to him till his money disappears.

The Greedy Husband:

He is too lazy to work and earn huge bucks. The easy way out is to hunt out for a multi-millionaire girl irrespective of her looks. All he wants is a BMW, the wine, cigars, penthouse, club memberships - but he’s not prepared to work hard for them. Fortune-hunting husband is basically a charming, lazy guy.

The Flirty Husband:

He has a nice wife but still he is greedy and loves to be surrounded by other beauties too. He can’t help groping his way through his wife’s friends, female coworkers, lady doctors -- basically any female with good looks. He won’t ever miss a chance of dropping or picking wife’s cousins or female friends to the airport or passing comments like ‘Sorry, but I can’t stop staring at your deep brown eyes’. He’s the sort of man that is incapable of being faithful. No love is true love for him; he can slip for any attractive girl.

The Always Penniless Husband:

The relationship starts off with thousand promises but soon all the charm fades away. He is unemployable, sitting at home eating and watching football. His parents thought he will realize his responsibilities after marriage, but no gain. The wife takes nearly no maternity leave and seems to be supporting her entire household on her salary alone. Truly, this husband is a life sentence of misery.

The Friendly Hubby:

He’s not a bad husband but his life is dedicated to his own social advancement. He cares too much about the parties, hanging with friends, night outs, travelling, long drives with his buddies. He is so very excited about these things, that he won’t even mind taking over his wife’s social life. He doesn’t believe in staying at home, he wants to have blast every night. This kind of husband can drive his wife to social madness.

The Almost Perfect Husband:

On the face, he appears to be a dream husband but in reality he is too irritating. He’s attentive, caring, loving, polite, well-dressed but always hovering near his wife, interrupting when she’s on phone, checking how much she’s been eating, drinking and spending. He’s just too much to handle. He turns up everywhere his wife goes at lunches, parties and he secretly hates her to have any friends and forbids her to even work. He basically shows he is a gem of a husband but he is a real pain. He looks like a perfect guy but he ain’t.

Proof that GIRLS are EVIL:

noreply@blogger.com (aashu) — Fri, 31 Oct 2008 10:44:00 +0000
Proof that GIRLS are EVIL:

First we state that girls require TIME and MONEY

GIRLS = TIME X MONEY

And we as well know TIME = MONEY

Therefore:

GIRLS = MONEY X MONEY = (MONEY)2

GIRLS = (MONEY)2

And because MONEY is the root of all EVIL

MONEY = √(EVIL)

GIRLS = [√(EVIL)]2

And we forced to conclude that

GIRLS = EVIL

$M$ FRE@K$ -

noreply@blogger.com (aashu) — Thu, 30 Oct 2008 09:28:00 +0000
*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

Naraaz hokar zindgi se nata nai todte,

mushkil ho raah fir b manzil nai chodte,

tanha na samajna khudko kabhi,

hum unme se hai jo kabhi sath nai chodte...

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

Wadiyo se Suraj nikal aaya hai,

Fizaon me naya rang chhaya hai.

Khamosh Q ho ab to muskurao

Aapko Good Morning kehene

mera SMS aaya hai. Gm

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

Chalo Aaj Mai Batata Hu Kya Ho Tum,

Mere Liye Meri DUNIYA Ho Tum,

Maine Jo Maangi Woh DUWA Ho Tum,

Kare Mujh Ko Jo ROSHAN Wo diya ho tum.

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

Ho Ske To Pyar Ka Itebar Kr Ke Dekhna

Phir Lafzon Se Iqrar Kr Ke Dekhna

Junon Ki Hd Se Aage Nikal Jaige

Sirf 1bar Hum Se Izhar Kar Ke Dek lo

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

TaMaNaO SE BhARi Ho ZNDGi,

KHwAHiSHO Se BhArA Ho HaR PaL,

DaMaN B CHOTA laGnE LaGe!

iTNi KHuSHiYA De AaPkO AANE WaLa KaL.

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

Gham ko bech kar khushi kharid lenge.

Khwab bech kar zindagi kharid lenge.

Hoga imtihan to duniya dekhegi.

Khud ko bech kar aapka pyar kharid lenge.

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

All Winners

Do Not Have To Be

A Hard Worker..!!

But

Every Hard Worker

Surely One Day

Become a Winner..!!

ALWAYS DO YOUR BEST..!

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

U may not see Them,

But they are Always There 4 U.

Two hands of mine

Praying for Ur Happiness

and One Heart to Wish

Ur Dreams come True.

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

Khushi to har koi chahta h

par"KHUSHNASIB" hi khushi pata h.

lekin har wo shaks

"KHUSHNASEEB" ho jata h,

jise aap jaisa Dost mil jata h.

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

"Co-incidence decides whom

u meet in life,

ur heart decides with whom

u want to stay in life

but only destiny decides

who gets to stay in ur life".

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

The Sun is calling u!

See.

The Rays r Shining for U!

Listen.

The birds r Singing 4 U!

Hear.

"My Heart" says :

Good morning 2 U...!

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

Munna: Circuit,A Note K Upar

Jo Gandhiji He Wo Hamesha Haste Q Rehta H?

Circuit: Bhai Hasna Padenga,

Agar Royenge To Note Bhig Jayega Na!!

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

Koi Khwaish Teri Adhuri Na Rahe

Chahe Jise Tu Usse

Duri Na Rahe

Khushiyo K Phul Itne Khile Tere

Jiwan Me,K Hmari Yad Bhi

Tere Liye Zaruri na rahe.

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

Never Make the Same Mistake Twice...

There are So Many New Ones...

Try a Different One Each Day... ;-)

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

"The true test of character

is not how much we know how to do,

but how we behave

when we don't know what to do."

*~*~*~*~*~*~ *~*~*

*~*~*~*~*~*~ *~*~*

*~*~ Ashish Gutgutia *~*~

30 October, 2008

~Broken in LOVE

noreply@blogger.com (aashu) — Thu, 30 Oct 2008 09:25:00 +0000
~Broken in LOVE~

Far away across the ocean
Sat a man in emotion
Thinking about his life
With his heart cut off by a knife
His life had become abject
In his mind still a vision
Never could he envision
Such a tragedy in his life
Now fading away in his sorrows
Never to return again
Broken in pain
Of his harsh destiny
Few words left for him to say
Pretending each day
To still feel the same
Living in pain

I am alone

noreply@blogger.com (aashu) — Thu, 30 Oct 2008 09:20:00 +0000

So I may be alone
I am my only friend
But I can't stand to listen to myself cry
I want a companion
To be here for me now
It seems no one cares
When I wallow in this self pity
Wade in these tears
And the waves crash upon my face
The tide pulls me under
Submerged in bitterness
I did it to myself
No one calls
No one cares
And there's no one except me
And this is a time
I can't stand to be near me
So why would you?
I guess that's why you're not here.