Beachhead - What's in a Name?
I was sanding down the hull of the Agape, my sloop that I sail from time to time, trying to get the boat ready for its annual painting when one of the younger Pollywogs, Yury, came up to me and complained that someone had called him a “hacker”.
“Why does that bother you?” I asked. “I do not break into other people's systems”, Yury said. “I program, I do systems administration and I help people a lot with their computer problems.”
I stopped sanding a bit and realized that Yury had confused the term Hacker with Cracker. It is easy to do, as the mass media has done much to mix the two terms.
“No Yury”, I said. “A hacker is a fine name to be called, it is someone who really knows programming, has studied it, enjoys doing it and shows exceptional skill at solving difficult problems with elegant code. Usually that code is relatively short, what we call a quick hack.”
Seeing me talking to Yury, more Pollywogs started coming up. “Then what is a cracker?” asked one of them. “A cracker”, I explained, “is someone that breaks into other people's systems, sometimes to do malicious damage, like destroy their Web site, but often just to show people that their sites or systems are insecure.”
I went on to explain that there were two main types of crackers, those who were extremely skilled and often very hard to detect without constant diligence and those who were less skilled, often relying on techniques developed by others, but applied to thousands or tens of thousands of systems over the Internet. Often these less skilled people are nicknamed script kiddies.
I also explained that in a lot of countries breaking into another person's system is against the law, even if it is relatively easy and no damage is done, and if the person is caught, there can be dire circumstances.
“But why do these people break in?” asked Yury, “Sometimes it is for financial gain”, I explained, and I continued:
Sometimes it is to steal records or change data that will bring some type of financial benefit to the cracker. Sometimes it is to see what other people are doing or to change their software so people will inadvertently send the crackers information that will be useful to them over time. Sometimes it is just for the challenge of breaking in, for peer respect of having “done the deed”.
A friend of mine named Marcelo Marques in Sao Paulo, Brazil, had been talking to the Brazilian FBI. They had empirical information that 80% of computer crimes were being either initiated or helped by teenagers. The FBI spokesman expressed frustration to my friend, because he could not understand why these teenagers were doing these things. Marcelo talked with me about crackers and hackers, and after planning for a while, he and his partners from 4Linux, a consulting firm in Sao Paulo, started a program called Hackerteen (www.hackerteen.com.br), under the premise that if you gave training to young people in how to be a really good systems administrator, programmer and community member, you could turn potential crackers into hackers. So far, the program has been in existence for two years and has graduated its first class of “Black Belt” students.
“Can anyone become a hacker?” asked Yury. I answered:
Well, there were a lot of young people who dropped out of Hackerteen along the way. The Hackerteen program is not an easy one. It is made up of on-line work, study and even on-site visits where the students are given courses in ethics, entrepreneurship, computer security, networks, programming and collaboration. My personal experience tells me that not every person can do programming. I have taught for too many years to say that every person has the gifts to become a top hacker. Nevertheless, a course set up like this can have a very positive effect on young programmers, and some of these graduates now have jobs with companies. I met with the first class of graduates, and I could see what the class meant to both them and their parents.
“Do you have to go to school or take a course to be a hacker?” asked Jay.
“No”, I answered, and I continued:
Lots of hackers I know are self-taught. One of the things that I like about free and open-source software is that there is nothing hidden from those who wish to learn. You can see other people's code and learn from it. There are plenty of books on the library shelves, magazines to read, Internet mailing lists and news groups and even electronic books to learn from. Things are very different now than from when I learned to code.
But some people find it difficult to learn by reading books, and some really like to have a guide or mentor along the way. Some do best with classroom instruction, and some are held back by it. My experience has been that a more structured approach gives a more balanced person, but this does not mean that you have to take a course or go to a school, you just have to define a path for yourself and stick with it. Some people find that difficult.
Ethics are particularly difficult, for what may be ethical for one person may not be ethical for many others. Here is where a lot of people may make the wrong decisions without proper guidance. If people think that ethics in computers are easy, they should attend a session of the Ethics Working Group of the SAGE Executive Committee.
“What about girls?” asked another young Pollywog, sort of crinkling his nose. “Can girls become hackers?”
“Definitely”, I said, and added:
One of my favorite people of all time, one of the earliest programmers and one of the pioneers of the Cobol language was Rear Admiral Dr Grace Murray Hopper. Dr Hopper encouraged early programmers to share common segments of code, reducing duplication of effort and errors.
In Malaysia, more than 70% of the people in data processing are women, and not just in “menial” tasks, but with jobs of influence and power. At my job in Bell Laboratories, my supervisor was a very talented woman by the name of Bea Fink. My observations have been that there is no inherent differences between a man and a woman doing a job in the computer field. As a former board member of the USENIX Association (www.usenix.org), I was very proud of the work USENIX did with organizations encouraging women to enter the field and acknowledging the women who contributed to it. I also met many fine women who would indeed fit the definition of hacker through USENIX and organizations like the ACM and IEEE.
Some of the Linux community has recognized the need to encourage women to enter the computer science field and started groups like LinuxChix (www.LinuxChix.org); GNUrias (www.gnurias.org.br), a Brazilian/Portuguese organization; Debian Women (www.women.debian.org); and ChicasLinux (www.chicaslinux.org), a Spanish organization.
“But how do you know you are a hacker?” asked Yury.
I had to sand the bottom of the Agape for a while before answering him. I had to think of all the many fine programmers that I had known over the years, all the people who were master craftspeople. I thought about the lists of hackers that I had seen, and the names on those lists. Yet, I did not remember any of these people referring to themselves, unless it was in a passing comment, as a hacker. Then I knew the answer for my young friend.
“Yury”, I said, “you are probably a hacker when some programmer that you respect as a good programmer calls you a hacker.”
The Agape is almost ready to sail.
Jon “maddog” Hall is the Executive Director of Linux International (www.li.org), a nonprofit association of end users who wish to support and promote the Linux operating system. During his career in commercial computing, which started in 1969, Mr Hall has been a programmer, systems designer, systems administrator, product manager, technical marketing manager and educator. He has worked for such companies as Western Electric Corporation, Aetna Life and Casualty, Bell Laboratories, Digital Equipment Corporation, VA Linux Systems and SGI. He is now an independent consultant in Free and Open Source Software (FOSS) Business and Technical issues.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide