BLOG main image
분류 전체보기 (71)
노래 (4)
후세인 (1)
잡담 (36)
MPD (0)
Linux (11)
영화,비디오,드라마 (16)
Note 4 (1)
Visitors up to today!
Today hit, Yesterday hit
daisy rss
tistory 티스토리 가입하기!
'리눅스'에 해당되는 글 7건
2006. 9. 22. 11:58

ipaq 3850에 familiar + opie를 올린 후 양쪽 아이피설정


백묵폰트와 pc쪽에 설치해줄 드라이버.

폰트는 아이팩쪽 /opt/QtPalmtop/lib/fonts/에 압축풀어 복사해준다.

'Linux' 카테고리의 다른 글

이 맛에 젠투를..  (0) 2011.06.29
e17용 carbon 한글테마  (0) 2008.05.28
The GNU Manifesto  (0) 2006.09.16
GNU 선언문(The GNU Manifesto)  (0) 2006.09.16
Gentoo Linux 배포판의 탄생  (0) 2006.09.16
2006. 9. 16. 17:27

The GNU Manifesto

The GNU Manifesto (which appears below) was written by Richard Stallman
at the beginning of the GNU Project, to ask for participation and support.
For the first few years, it was updated in minor ways to account for
developments, but now it seems best to leave it unchanged as most people
have seen it.
Since that time, we have learned about certain common misunderstandings
that different wording could help avoid.
Footnotes added in 1993 help clarify these points.
For up-to-date information about the available GNU software, please see
the information available onour web server,
in particular our list of software.
For how to contribute, see http://www.gnu.org/help.

What's GNU? Gnu's Not Unix!


GNU, which stands for Gnu's Not Unix, is the name for the complete Unix-compatible software system which I am writing so that I can give it away free to everyone who can use it. (1) Several other volunteers are helping me. Contributions of time, money, programs and equipment are greatly needed.

So far we have an Emacs text editor with Lisp for writing editor commands, a source level debugger, a yacc-compatible parser generator, a linker, and around 35 utilities. A shell (command interpreter) is nearly completed. A new portable optimizing C compiler has compiled itself and may be released this year. An initial kernel exists but many more features are needed to emulate Unix. When the kernel and compiler are finished, it will be possible to distribute a GNU system suitable for program development. We will use TeX as our text formatter, but an nroff is being worked on. We will use the free, portable X window system as well. After this we will add a portable Common Lisp, an Empire game, a spreadsheet, and hundreds of other things, plus on-line documentation. We hope to supply, eventually, everything useful that normally comes with a Unix system, and more.

GNU will be able to run Unix programs, but will not be identical to Unix. We will make all improvements that are convenient, based on our experience with other operating systems. In particular, we plan to have longer file names, file version numbers, a crashproof file system, file name completion perhaps, terminal-independent display support, and perhaps eventually a Lisp-based window system through which several Lisp programs and ordinary Unix programs can share a screen. Both C and Lisp will be available as system programming languages. We will try to support UUCP, MIT Chaosnet, and Internet protocols for communication.

GNU is aimed initially at machines in the 68000/16000 class with virtual memory, because they are the easiest machines to make it run on. The extra effort to make it run on smaller machines will be left to someone who wants to use it on them.

To avoid horrible confusion, please pronounce the `G' in the word `GNU' when it is the name of this project.

Why I Must Write GNU

I consider that the golden rule requires that if I like a program I must share it with other people who like it. Software sellers want to divide the users and conquer them, making each user agree not to share with others. I refuse to break solidarity with other users in this way. I cannot in good conscience sign a nondisclosure agreement or a software license agreement. For years I worked within the Artificial Intelligence Lab to resist such tendencies and other inhospitalities, but eventually they had gone too far: I could not remain in an institution where such things are done for me against my will.

So that I can continue to use computers without dishonor, I have decided to put together a sufficient body of free software so that I will be able to get along without any software that is not free. I have resigned from the AI lab to deny MIT any legal excuse to prevent me from giving GNU away.

Why GNU Will Be Compatible with Unix

Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.

How GNU Will Be Available

GNU is not in the public domain. Everyone will be permitted to modify and redistribute GNU, but no distributor will be allowed to restrict its further redistribution. That is to say, proprietary modifications will not be allowed. I want to make sure that all versions of GNU remain free.

Why Many Other Programmers Want to Help

I have found many other programmers who are excited about GNU and want to help.

Many programmers are unhappy about the commercialization of system software. It may enable them to make more money, but it requires them to feel in conflict with other programmers in general rather than feel as comrades. The fundamental act of friendship among programmers is the sharing of programs; marketing arrangements now typically used essentially forbid programmers to treat others as friends. The purchaser of software must choose between friendship and obeying the law. Naturally, many decide that friendship is more important. But those who believe in law often do not feel at ease with either choice. They become cynical and think that programming is just a way of making money.

By working on and using GNU rather than proprietary programs, we can be hospitable to everyone and obey the law. In addition, GNU serves as an example to inspire and a banner to rally others to join us in sharing. This can give us a feeling of harmony which is impossible if we use software that is not free. For about half the programmers I talk to, this is an important happiness that money cannot replace.

How You Can Contribute

(Nowadays, for software tasks to work on, see the GNU task list. For other ways to contribute, see http://www.gnu.org/help.)

I am asking computer manufacturers for donations of machines and money. I'm asking individuals for donations of programs and work.

One consequence you can expect if you donate machines is that GNU will run on them at an early date. The machines should be complete, ready to use systems, approved for use in a residential area, and not in need of sophisticated cooling or power.

I have found very many programmers eager to contribute part-time work for GNU. For most projects, such part-time distributed work would be very hard to coordinate; the independently-written parts would not work together. But for the particular task of replacing Unix, this problem is absent. A complete Unix system contains hundreds of utility programs, each of which is documented separately. Most interface specifications are fixed by Unix compatibility. If each contributor can write a compatible replacement for a single Unix utility, and make it work properly in place of the original on a Unix system, then these utilities will work right when put together. Even allowing for Murphy to create a few unexpected problems, assembling these components will be a feasible task. (The kernel will require closer communication and will be worked on by a small, tight group.)

If I get donations of money, I may be able to hire a few people full or part time. The salary won't be high by programmers' standards, but I'm looking for people for whom building community spirit is as important as making money. I view this as a way of enabling dedicated people to devote their full energies to working on GNU by sparing them the need to make a living in another way.

Why All Computer Users Will Benefit

Once GNU is written, everyone will be able to obtain good system software free, just like air.(2)

This means much more than just saving everyone the price of a Unix license. It means that much wasteful duplication of system programming effort will be avoided. This effort can go instead into advancing the state of the art.

Complete system sources will be available to everyone. As a result, a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him. Users will no longer be at the mercy of one programmer or company which owns the sources and is in sole position to make changes.

Schools will be able to provide a much more educational environment by encouraging all students to study and improve the system code. Harvard's computer lab used to have the policy that no program could be installed on the system if its sources were not on public display, and upheld it by actually refusing to install certain programs. I was very much inspired by this.

Finally, the overhead of considering who owns the system software and what one is or is not entitled to do with it will be lifted.

Arrangements to make people pay for using a program, including licensing of copies, always incur a tremendous cost to society through the cumbersome mechanisms necessary to figure out how much (that is, which programs) a person must pay for. And only a police state can force everyone to obey them. Consider a space station where air must be manufactured at great cost: charging each breather per liter of air may be fair, but wearing the metered gas mask all day and all night is intolerable even if everyone can afford to pay the air bill. And the TV cameras everywhere to see if you ever take the mask off are outrageous. It's better to support the air plant with a head tax and chuck the masks.

Copying all or parts of a program is as natural to a programmer as breathing, and as productive. It ought to be as free.

Some Easily Rebutted Objections to GNU's Goals

"Nobody will use it if it is free, because that means they can't rely on any support."

"You have to charge for the program to pay for providing the support."

If people would rather pay for GNU plus service than get GNU free without service, a company to provide just service to people who have obtained GNU free ought to be profitable.(3)

We must distinguish between support in the form of real programming work and mere handholding. The former is something one cannot rely on from a software vendor. If your problem is not shared by enough people, the vendor will tell you to get lost.

If your business needs to be able to rely on support, the only way is to have all the necessary sources and tools. Then you can hire any available person to fix your problem; you are not at the mercy of any individual. With Unix, the price of sources puts this out of consideration for most businesses. With GNU this will be easy. It is still possible for there to be no available competent person, but this problem cannot be blamed on distribution arrangements. GNU does not eliminate all the world's problems, only some of them.

Meanwhile, the users who know nothing about computers need handholding: doing things for them which they could easily do themselves but don't know how.

Such services could be provided by companies that sell just hand-holding and repair service. If it is true that users would rather spend money and get a product with service, they will also be willing to buy the service having got the product free. The service companies will compete in quality and price; users will not be tied to any particular one. Meanwhile, those of us who don't need the service should be able to use the program without paying for the service.

"You cannot reach many people without advertising, and you must charge for the program to support that."

"It's no use advertising a program people can get free."

There are various forms of free or very cheap publicity that can be used to inform numbers of computer users about something like GNU. But it may be true that one can reach more microcomputer users with advertising. If this is really so, a business which advertises the service of copying and mailing GNU for a fee ought to be successful enough to pay for its advertising and more. This way, only the users who benefit from the advertising pay for it.

On the other hand, if many people get GNU from their friends, and such companies don't succeed, this will show that advertising was not really necessary to spread GNU. Why is it that free market advocates don't want to let the free market decide this?(4)

"My company needs a proprietary operating system to get a competitive edge."

GNU will remove operating system software from the realm of competition. You will not be able to get an edge in this area, but neither will your competitors be able to get an edge over you. You and they will compete in other areas, while benefiting mutually in this one. If your business is selling an operating system, you will not like GNU, but that's tough on you. If your business is something else, GNU can save you from being pushed into the expensive business of selling operating systems.

I would like to see GNU development supported by gifts from many manufacturers and users, reducing the cost to each.(5)

"Don't programmers deserve a reward for their creativity?"

If anything deserves a reward, it is social contribution. Creativity can be a social contribution, but only in so far as society is free to use the results. If programmers deserve to be rewarded for creating innovative programs, by the same token they deserve to be punished if they restrict the use of these programs.

"Shouldn't a programmer be able to ask for a reward for his creativity?"

There is nothing wrong with wanting pay for work, or seeking to maximize one's income, as long as one does not use means that are destructive. But the means customary in the field of software today are based on destruction.

Extracting money from users of a program by restricting their use of it is destructive because the restrictions reduce the amount and the ways that the program can be used. This reduces the amount of wealth that humanity derives from the program. When there is a deliberate choice to restrict, the harmful consequences are deliberate destruction.

The reason a good citizen does not use such destructive means to become wealthier is that, if everyone did so, we would all become poorer from the mutual destructiveness. This is Kantian ethics; or, the Golden Rule. Since I do not like the consequences that result if everyone hoards information, I am required to consider it wrong for one to do so. Specifically, the desire to be rewarded for one's creativity does not justify depriving the world in general of all or part of that creativity.

"Won't programmers starve?"

I could answer that nobody is forced to be a programmer. Most of us cannot manage to get any money for standing on the street and making faces. But we are not, as a result, condemned to spend our lives standing on the street making faces, and starving. We do something else.

But that is the wrong answer because it accepts the questioner's implicit assumption: that without ownership of software, programmers cannot possibly be paid a cent. Supposedly it is all or nothing.

The real reason programmers will not starve is that it will still be possible for them to get paid for programming; just not paid as much as now.

Restricting copying is not the only basis for business in software. It is the most common basis because it brings in the most money. If it were prohibited, or rejected by the customer, software business would move to other bases of organization which are now used less often. There are always numerous ways to organize any kind of business.

Probably programming will not be as lucrative on the new basis as it is now. But that is not an argument against the change. It is not considered an injustice that sales clerks make the salaries that they now do. If programmers made the same, that would not be an injustice either. (In practice they would still make considerably more than that.)

"Don't people have a right to control how their creativity is used?"

"Control over the use of one's ideas" really constitutes control over other people's lives; and it is usually used to make their lives more difficult.

People who have studied the issue of intellectual property rights(6) carefully (such as lawyers) say that there is no intrinsic right to intellectual property. The kinds of supposed intellectual property rights that the government recognizes were created by specific acts of legislation for specific purposes.

For example, the patent system was established to encourage inventors to disclose the details of their inventions. Its purpose was to help society rather than to help inventors. At the time, the life span of 17 years for a patent was short compared with the rate of advance of the state of the art. Since patents are an issue only among manufacturers, for whom the cost and effort of a license agreement are small compared with setting up production, the patents often do not do much harm. They do not obstruct most individuals who use patented products.

The idea of copyright did not exist in ancient times, when authors frequently copied other authors at length in works of non-fiction. This practice was useful, and is the only way many authors' works have survived even in part. The copyright system was created expressly for the purpose of encouraging authorship. In the domain for which it was invented--books, which could be copied economically only on a printing press--it did little harm, and did not obstruct most of the individuals who read the books.

All intellectual property rights are just licenses granted by society because it was thought, rightly or wrongly, that society as a whole would benefit by granting them. But in any particular situation, we have to ask: are we really better off granting such license? What kind of act are we licensing a person to do?

The case of programs today is very different from that of books a hundred years ago. The fact that the easiest way to copy a program is from one neighbor to another, the fact that a program has both source code and object code which are distinct, and the fact that a program is used rather than read and enjoyed, combine to create a situation in which a person who enforces a copyright is harming society as a whole both materially and spiritually; in which a person should not do so regardless of whether the law enables him to.

"Competition makes things get done better."

The paradigm of competition is a race: by rewarding the winner, we encourage everyone to run faster. When capitalism really works this way, it does a good job; but its defenders are wrong in assuming it always works this way. If the runners forget why the reward is offered and become intent on winning, no matter how, they may find other strategies--such as, attacking other runners. If the runners get into a fist fight, they will all finish late.

Proprietary and secret software is the moral equivalent of runners in a fist fight. Sad to say, the only referee we've got does not seem to object to fights; he just regulates them ("For every ten yards you run, you can fire one shot"). He really ought to break them up, and penalize runners for even trying to fight.

"Won't everyone stop programming without a monetary incentive?"

Actually, many people will program with absolutely no monetary incentive. Programming has an irresistible fascination for some people, usually the people who are best at it. There is no shortage of professional musicians who keep at it even though they have no hope of making a living that way.

But really this question, though commonly asked, is not appropriate to the situation. Pay for programmers will not disappear, only become less. So the right question is, will anyone program with a reduced monetary incentive? My experience shows that they will.

For more than ten years, many of the world's best programmers worked at the Artificial Intelligence Lab for far less money than they could have had anywhere else. They got many kinds of non-monetary rewards: fame and appreciation, for example. And creativity is also fun, a reward in itself.

Then most of them left when offered a chance to do the same interesting work for a lot of money.

What the facts show is that people will program for reasons other than riches; but if given a chance to make a lot of money as well, they will come to expect and demand it. Low-paying organizations do poorly in competition with high-paying ones, but they do not have to do badly if the high-paying ones are banned.

"We need the programmers desperately. If they demand that we stop helping our neighbors, we have to obey."

You're never so desperate that you have to obey this sort of demand. Remember: millions for defense, but not a cent for tribute!

"Programmers need to make a living somehow."

In the short run, this is true. However, there are plenty of ways that programmers could make a living without selling the right to use a program. This way is customary now because it brings programmers and businessmen the most money, not because it is the only way to make a living. It is easy to find other ways if you want to find them. Here are a number of examples.

A manufacturer introducing a new computer will pay for the porting of operating systems onto the new hardware.

The sale of teaching, hand-holding and maintenance services could also employ programmers.

People with new ideas could distribute programs as freeware(7), asking for donations from satisfied users, or selling hand-holding services. I have met people who are already working this way successfully.

Users with related needs can form users' groups, and pay dues. A group would contract with programming companies to write programs that the group's members would like to use.

All sorts of development can be funded with a Software Tax:

Suppose everyone who buys a computer has to pay x percent of the price as a software tax. The government gives this to an agency like the NSF to spend on software development.

But if the computer buyer makes a donation to software development himself, he can take a credit against the tax. He can donate to the project of his own choosing--often, chosen because he hopes to use the results when it is done. He can take a credit for any amount of donation up to the total tax he had to pay.

The total tax rate could be decided by a vote of the payers of the tax, weighted according to the amount they will be taxed on.

The consequences:

  • The computer-using community supports software development.
  • This community decides what level of support is needed.
  • Users who care which projects their share is spent on can choose this for themselves.

In the long run, making programs free is a step toward the post-scarcity world, where nobody will have to work very hard just to make a living. People will be free to devote themselves to activities that are fun, such as programming, after spending the necessary ten hours a week on required tasks such as legislation, family counseling, robot repair and asteroid prospecting. There will be no need to be able to make a living from programming.

We have already greatly reduced the amount of work that the whole society must do for its actual productivity, but only a little of this has translated itself into leisure for workers because much nonproductive activity is required to accompany productive activity. The main causes of this are bureaucracy and isometric struggles against competition. Free software will greatly reduce these drains in the area of software production. We must do this, in order for technical gains in productivity to translate into less work for us.


Footnotes

(1) The wording here was careless. The intention was that nobody would have to pay for *permission* to use the GNU system. But the words don't make this clear, and people often interpret them as saying that copies of GNU should always be distributed at little or no charge. That was never the intent; later on, the manifesto mentions the possibility of companies providing the service of distribution for a profit. Subsequently I have learned to distinguish carefully between "free" in the sense of freedom and "free" in the sense of price. Free software is software that users have the freedom to distribute and change. Some users may obtain copies at no charge, while others pay to obtain copies--and if the funds help support improving the software, so much the better. The important thing is that everyone who has a copy has the freedom to cooperate with others in using it.

(2) This is another place I failed to distinguish carefully between the two different meanings of "free". The statement as it stands is not false--you can get copies of GNU software at no charge, from your friends or over the net. But it does suggest the wrong idea.

(3) Several such companies now exist.

(4) The Free Software Foundation for 10 years raised most of its funds from a distribution service, although it is a charity rather than a company. You can order things from the FSF.

(5) A group of computer companies pooled funds around 1991 to support maintenance of the GNU C Compiler.

(6) In the 80s I had not yet realized how confusing it was to speak of "the issue" of "intellectual property". That term is obviously biased; more subtle is the fact that it lumps together various disparate laws which raise very different issues. Nowadays I urge people to reject the term "intellectual property" entirely, lest it lead others to suppose that those laws form one coherent issue. The way to be clear is to discuss patents, copyrights, and trademarks separately. See further explanation of how this term spreads confusion and bias.

(7) Subsequently we have learned to distinguish between "free software" and "freeware". The term "freeware" means software you are free to redistribute, but usually you are not free to study and change the source code, so most of it is not free software. the Confusing Words and Phrases page for more explanation.

2006. 9. 16. 17:20

GNU 선언문(The GNU Manifesto)

저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 허용되며 상업적 이용을 포함할 수 있는 지속적인 배포에 따른 사용상의 모든 권리는 문서의 취득자에게 조건없이 양도된다. 1993년의 개정 이후, GNU 선언문은 영구 보존문으로 남아있게 될 것이며 원문에 대한 어떠한 형태의 수정과 첨삭도 허용되지 않는다. Original Copy: The GNU Manifesto


Copyright (C) 1985, 1993 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA

Korean Translator: Ha Jaewon 하재원 Amendment Translator: 1998 Song Changhun 송창훈 chsong@cyber.co.kr


개정본 역자 참고 사항


2차적 저작권의 포기 여부에 상관없이 선행 작업에 대한 존중의 표시로 원역자를 통해서 문서를 개정하려고 했지만, 상당한 노력에도 불구하고 원역자와 연결될 수 없었기 때문에 다음과 같은 기준에 의해서 문서를 개정한다.

  1. GNU 정신에 입각해서 중복 작업이라는 소모적인 비효율성을 피하고 선행 작업의 노력과 성과를 가능한 그대로 유지하기 위해서 본질적인 내용 전달 상의 오역만을 수정한다.
  2. 1993년 개정문에 대한 내용들을 새롭게 첨가시킨다.

GNU 선언문은 GNU 프로젝트가 시작되었을 당시, 많은 사람들의 참여와 지원을 요청하기 위해서 리차드 스톨만에 의해서 작성되었다. 처음 몇 년 동안은 프로젝트의 발전 상황을 설명하기 위해서 부분적인 개정이 이루어 졌으나 문서가 널리 확산됨에 따라서 많은 사람들이 인지하고 있는 내용 그대로를 보존하는 편이 낫다고 판단하게 되었다.

문서에 대한 보존이 결정된 이후로, 우리는 일반적인 오해의 여지가 있는 몇몇 단어에 대한 문제점들을 알게 되었고 1993년에 주석을 첨가하는 것으로 해석상의 난점들을 명확하게 정리하였다.

GNU 소프트웨어에 대한 최신 정보는 GNU의 게시판 (GNU's Bulletin)을 참고하기 바란다. 분량 상의 이유로 이 문서에서는 생략하기로 한다.

GNU란 무엇인가? GNU는 유닉스가아니다! GNU란 'GNU는 유닉스가 아니다'(Gnu is Not Unix)를 의미하는 재귀적 약어다. GNU는 유닉스와 완벽하게 호환하는 소프트웨어 시스템이며 사용 가능한 모든 이가 자유롭게 사용할 수 있도록 작성한 것이다. (1) 몇몇 다른 자원자들이 도움을 주고 있으며 많은 시간적, 금전적 지원과 프로그램과 장비가 절실히 필요한 상태이다.

지금까지 우리는 편집 명령을 작성하기 위한 인공 지능 언어 리스프(Lisp)를 갖춘 Emacs 문서 편집기, 소스 수준의 디버거(debugger), yacc 호환 파서 생성기(parser generator), 링커등 35개 가량의 유틸리티를 만들어 왔으며, 쉘(shell-명령어 번역기)은 거의 완벽한 수준에 이르렀다. 이식성 있게 최적화된 C 컴파일러가 새로이 제작되었으며 이번 해에 배포될 것이다. 이미 커널(kernel)을 갖고 있기는 하지만 유닉스를 구현하기 위해서는 보다 많은 사양들이 추가되어야 할 것이다. 커널과 컴파일러가 완성되면 프로그램 개발에 적합한 GNU 시스템을 배포할 수 있을 것이다. 우리는 문서 형식기(text formatter)로 TeX를 사용할 것이며, nroff도 여전히 사용될 것이다. 또한, 이식성을 갖춘 공개 소프트웨어인 X 윈도우 시스템도 사용할 것이다. 이런 후에 이식성을 확보한 Common Lisp, 게임 프로그램인 Empire, 스프레드시트(spreadsheet) 등과 수많은 다른 프로그램을 온라인 문서를 포함하여 추가할 것이다. 우리는 결국, 일반적인 유닉스 시스템의 모든 기능을 갖추게 될 것이다.

GNU는 유닉스 프로그램들을 사용할 수 있게 해주지만 유닉스와 동일한 것은 아니다. 우리는 다른 운영체제에서의 경험을 살려 가능한 사용하기 편리하도록 향상을 꾀했다. 특히, 긴 길이와 복잡한 조합 형태의 파일 명을 쓸 수 있게 하고, 파일 버전을 표시하고, 견고한 파일 시스템을 구축하고, 터미널 비 의존적인 디스플레이 장치를 지원할 계획이며 최종적으로 몇 개의 리스프 프로그램과 일반적인 유닉스 프로그램이 한 화면을 나누어 쓸 수 있는 리스프 기반의 윈도우 시스템을 만들 것이다. 시스템 프로그래밍 언어로 C와 리스프 두 가지를 다 사용할 수 있을 것이다. 일대일 네트워크 기능인 UUCP(Unix to Unix Copy Program), MIT Chaosnet, 인터넷 프로토콜을 지원할 것이다.

GNU는 본래 가상 메모리를 가진 모토롤라(motorola)사의 68000/16000 CPU 계열의 컴퓨터를 겨냥하고 제작되었다. 그 까닭은 그 기계들에서 GNU를 가장 쉽게 작동시킬 수 있기 때문이다. 보다 작은 컴퓨터에서 작동시키기 위해서는 사용하고자 하는 사람이 특별한 노력을 기울여야 할 것이다.

심각한 혼동이 야기될 수 있으므로 'GNU'가 소프트웨어 시스템이 아닌 이 프로젝트 자체를 지칭할 때는 'GNU'의 'G'를 반드시 발음해 주기 바란다.

왜 GNU를 작성해야만 했는가?

어떤 프로그램을 좋아한다면 당연히 그것을 좋아하는 사람들과 함께 나누는 것이 황금률(대우받고자 하는 데로 대하라-성서)이라고 생각한다. 소프트웨어를 판매하는 사람들은 사용자를 각각 구분하고, 그들 위에 군림하고, 사용자 서로가 프로그램을 공유하는 것을 막고자 한다. 나는 이런 식으로 사용자간의 결속이 깨지는 것을 거부한다. 나는 올바른 양심으로 비공개 협정이나 소프트웨어 라이센스 협약에 서명할 수 없다. 여러 해 동안 인공지능 연구소에서 일하면서 그러한 경향과 다른 박정한 일들에 저항해 보았지만 결국에는 그들의 승리로 끝나고 말았다. 내 의지에 역행하는 그런 일들이 일어나는 연구소에 나는 더이상 머무를 수가 없었다.

내가 계속해서 명예를 손상시키지 않고 컴퓨터를 사용하기 위해서 나는 사용이 제한되는 소프트웨어들을 더이상 이용하지 않고도 작업을 해 나갈 수 있는 충분한 자유 소프트웨어의 본체를 만들 결심을 했다. 나는 MIT(Massachusetts Institute of Technology) 측이 어떠한 법률적 근거에 의해서도 GNU의 자유로운 배포를 제지하지 못하도록 하기 위해서 연구소를 그만두었다.

유닉스와 호환성을 가지는 이유

유닉스가 이상적인 운영체제라고 생각하지는 않지만 제법 쓸만하다고 할 수 있다. 유닉스의 골자는 훌륭한 것이며 나는 유닉스의 장점을 해치지 않고도 부족한 점들을 메울 수 있으리라고 생각했다. 그리고 유닉스와 호환성을 가지면 다른 많은 사람들이 적응하기에도 편리할 것이라 생각했다.

GNU를 사용하는 방법

GNU는 저작권이 인정되는(not public domain) 소프트웨어다. 누구나 GNU를 개작하고 배포할 수 있지만 어떤 이도 GNU가 보다 널리 배포되는 것을 제한할 수 없다. 즉, 변경한 내용을 독점할 수 없다는 것이다. 나는 모든 버전의 GNU가 공개된 채로 남아 있기를 보장받고 싶은 것이다.

많은 프로그래머들이 동참을 원하는 이유

나는 그 동안, GNU에 흥미를 느끼고 돕고자 하는 많은 프로그래머들을 찾을 수 있었다.

많은 프로그래머들은 시스템 소프트웨어가 상용화된 것을 불쾌하게 생각한다. 이렇게 함으로 해서 보다 더 많은 돈을 벌 수는 있겠지만 일반적으로 이런 상황에서는 프로그래머들이 서로를 동지로 느끼기보다는 투쟁해야 할 대상으로 느끼게 된다. 프로그래머들 사이의 우정을 나타내는 가장 기본적인 행동은 프로그램을 나누는 것이다. 이제는 전형적인 핵심으로 여기는 마케팅 협정은 프로그래머들이 친구로서 다른 프로그래머를 대하는 것을 금하고 있다. 소프트웨어를 구입한 자는 우정과 준법 중 하나를 선택해야만 한다. 물론 자연적으로 많은 이들이 우정을 보다 중요시한다. 그러나 법의 존재 가치를 인정하는 사람들은 어떤 결정을 내리든 편한 마음을 가질 수 없다. 그들은 냉소적이 되어 프로그래밍은 단지 돈을 버는 수단이라고 생각하게 된다.

그러나 독점적인 프로그램들 대신 GNU를 사용하게 되면, 우리는 모든 이에게 온정을 가질 수 있으며 법도 준수하게 된다. 게다가 GNU는 공유의 표본으로써 다른 이가 우리와 함께 공유에 동참하도록 고무하는 깃발 노릇도 한다. 이는 우리가 상용 프로그램을 쓸 때는 느낄 수 없는 조화로운 느낌을 갖게 한다. 나와 대화한 프로그래머들 중 거의 반정도는 이것은 돈이 대신할 수 없는 중요한 행복이라는데 공감했다.

당신이 기여할 수 있는 방법

나는 제조업자들에게는 기계와 돈을, 개인들에게는 프로그램과 노동을 지원해 줄 것을 요청한다.

컴퓨터를 기증해서 기대할 수 있는 중요한 점은 GNU가 머지않아 그 기계에서 작동 할 것이란 점이다. 기증된 컴퓨터는 완전해 질 것이며 따라서, 시스템을 사용할 준비를 모두 갖추게 되어 능력과 효율을 과대 포장할 필요가 없을 것이다.

나는 GNU를 위해 시간제로 일하기를 갈망하는 많은 프로그래머들을 찾을 수 있었다. 대부분의 프로젝트에서 이러한 시간제로 배치된 작업을 통합하고 조정하는 일은 매우 어려웠다. 독립적으로 쓰여진 부분들은 함께 동작하지 않았다. 그러나 유닉스를 이용할 경우에는 그러한 문제가 생기지 않는다. 완전한 유닉스 시스템은 개별적인 설명이 포함된 백여 개의 유틸리티를 포함한다. 대부분의 인터페이스 사양은 유닉스에 호환되도록 맞추어 진다. 만약 각각의 프로그래머가 유닉스 유틸리티 한 개를 유닉스에 호환하도록 재 구현하고 본래의 유닉스 시스템에서 충분히 작동하게 할 수 있으면, 이것들은 함께 묶어 놓아도 올바르게 작동할 것이다. 예기치 못한 문제 발생의 가능성을 고려한다 하더라도 전체적인 구성 요소들을 통합하는 작업은 충분히 가능할 것이다(커널을 만드는 작업은 세밀한 대화가 필요할 것이며, 소수의 호흡이 잘 맞는 집단이 적당할 것이다)

만일 내가 금전적인 지원을 얻는다면 약간의 인원을 전일제나 시간제로 고용할 수 있을 것이다. 일반적인 프로그래머의 수준보다 높은 봉급을 줄 수는 없겠지만 돈을 가지는 것만큼이나 공동체 의식을 정립하는 일도 중요한 의미를 가진다고 생각하는 사람들을 찾아 볼 것이다. 이런 사람들에게 적절한 보수를 제공하는 것은 그들이 생계에 대한 절박함에서 벗어나서 보다 자유롭게 그들의 모든 역량을 GNU에 집중할 수 있도록 할 수 있는 방법이 될 것이다.

모든 컴퓨터 사용자가 이득을 얻게 되는 이유

일단 GNU가 작성되니까, 마치 공기처럼, 모든 사람들이 훌륭한 시스템 소프트웨어를 자유롭게 얻을 수 있게 되었다. (2)

이것은 단지 모든 이에게 유닉스의 사용에 대한 비용을 덜어 주는 것보다 훨씬 더 많은 의미를 가진다. 이는 시스템 프로그래밍에 드는 노력이 불필요하게 중복되는 것을 피할 수 있음을 의미한다. 대신, 절약된 노력은 기술 수준을 향상시키는데 사용될 것이다.

시스템에 대한 모든 소스 코드가 모든 사람에게 제공될 것이다. 결과적으로, 시스템에 변화를 주고자 한다면 언제든지 스스로 자유롭게 수정할 수 있을 것이다. 혹은 적당한 프로그래머나 업체에 의뢰할 수도 있을 것이다. 사용자들은 더이상 프로그램 소스를 독점적으로 소유하거나 이를 수정할 수 있는 프로그래머나 회사에 의존하지 않아도 될 것이다.

학교는 모든 학생들이 시스템 코드를 배우고 향상시키도록 장려함으로써 보다 나은 교육 환경을 조성할 수 있을 것이다. 하버드 대학의 컴퓨터 연구소에서는 어떤 프로그램이든지 그 소스가 공개되지 않으면 시스템에 설치하지 못하게 하는 정책을 쓰곤 했다. 실제로 어떤 프로그램들을 설치하지 못하게 함으로써 이 정책을 고수했다. 나는 이것에서 커다란 영감을 받게 되었다.

결국에는, 누가 시스템 소프트웨어를 소유하고 있으며 누구에게 사용 자격을 부여할 것인가를 결정하는 문제들이 사라지게 될 것이다.

복사 라이센스를 포함하여 프로그램 사용에 대한 지불을 준비할 때는 언제나 개인이 지불해야 할 돈이 얼마인가를 알아내야 하는 번잡한 과정에 의해서 사회에 많은 비용을 야기시킨다. 그리고, 오직 경찰 당국만이 모든 사람이 그것을 따르게 하도록 힘을 행사할 수 있다. 막대한 비용을 들여 공기를 생산하는 우주 정거장을 생각해 보자. 이런 경우 각각의 개인은 자신이 호흡하는 공기에 대해 리터(liter) 단위로 요금을 지불하는 것이 합당할 것이다. 그렇다고는 해도 호흡하는 공기의 양을 측정하기 위해서 계측기가 달린 방독면을 밤낮으로 쓰고 있어야 한다면 그런 방식은 지불 능력에 관계없이 타당한 것이 아니다. 그리고 TV 카메라는 당신이 마스크를 벗는 불법을 행하는지 어디서나 지켜보아야 할 것이며 따라서, 이것보다는 사람 수에 따라 일정한 세금을 부과하고 마스크를 벗어 던지는 것이 현명하다.

프로그램의 일부 혹은 전체를 복제하는 행위는 프로그래머에게 있어서는 숨을 쉬는 것만큼이나 자연스러운 일이며 생산적이다. 따라서, 프로그램은 마땅히 자유롭게 사용될 수 있어야 한다.

몇 가지 GNU의 목표에 대한 반대 의견

"무료라면 아무도 그것을 쓰지 않을 것이다. 왜냐하면 무료라는 것은 어떠한 지원도 기대할 수 없다는 것을 의미하기 때문이다."

"당신은 그 프로그램에 대한 지원과 도움을 제공하는 대가로 이에 관한 비용을 부과해야만 한다."

만약 사람들이 돈을 지불하고서 GNU에 대한 서비스를 받기를 희망한다면, GNU를 무료로 얻은 사람들에게 그런 서비스를 제공하는 회사도 이익을 얻을 수 있을 것이다. (3)

우리는 반드시 실제 프로그래밍 작업과 단순 관리 작업을 구별해야 한다. 전자는 때때로 소프트웨어 판매 회사에게 의존할 수가 없다. 만일 당신의 문제가 보편적으로 발생되는 사안이 아니라면, 판매 회사는 그 문제를 끝까지 해결해 주려고 하지 않을 것이다.

만일 당신의 사업이 지원에 대한 의존이 필요하다면, 필요한 모든 소스와 도구를 갖춰야 할 것이다. 그리고, 당신의 문제를 해결해 줄 수 있는 사람을 고용할 수 있을 것이다. 이것이 다른 사람의 자비를 얻는 것은 아니다. 유닉스에서는 이러한 부분에 있어서의 소스의 가격이 고려되어 있지 않지만 GNU의 경우는 이러한 문제를 용이하게 할 수 있을 것이다. 그러나, 유능한 사람을 구할 수 없을 가능성은 여전히 존재하고 이것을 배포에 따른 문제라고 비난할 수는 없다. GNU는 모든 세계의 문제를 제거하는 것은 아니며 단지 그중 하나일 뿐이다.

한편, 컴퓨터에 대해 전혀 모르는 사용자들은 여전히 단순한 관리 서비스를 필요로 한다. 이러한 일은 사용자 스스로 능히 처리할 수 있는 종류의 일이지만 그러한 방법을 모르기 때문이다.

이런 서비스들은 단순한 수작업이나 복구 서비스를 지원하는 회사들이 제공할 수 있다. 사용자들이 제품을 사고 그에 대한 서비스를 받는 방식을 받아들인다면, 제품을 무료로 받고 서비스에 대한 비용을 지불하는 방식에도 기꺼이 동의할 것이다. 서비스를 제공하는 회사들은 가격과 질적인 면에서 모두 완벽을 기할 수 있을 것이며 사용자들은 특정한 업체에 얽매이지 않아도 될 것이다. 또한, 그러한 서비스가 필요하지 않은 사람들은 서비스에 대한 비용을 들이지 않고도 프로그램들을 쓸 수 있을 것이다.

"광고를 하지 않고는 많은 사람들에게 알릴 수 없을 것이며, 그러기 위해서는 필히 프로그램에 가격을 매겨야 한다. "

"무료로 제공되는 프로그램을 광고하는 것은 무의미하다."

GNU 같은 프로그램을 많은 컴퓨터 사용자들에게 알릴 수 있는 방법에는 무료 혹은 극히 적은 비용으로 사용할 수 있는 다양한 정보 전파 방식이 있다. 그러나 광고를 하는 것이 보다 많은 컴퓨터 사용자에게 정보를 알릴 수 있는 방법일지도 모른다. 만일 실제로 이런 것이 사실이라면 복제와 배포를 하는데 돈을 받음으로써 능히 광고와 그 외의 부수적인 비용을 감당할 수 있을 것이다. 이런 방식에서는, 광고를 보고 배포본을 구입해서 이익을 얻을 수 있는 사용자가 광고 비용을 부담하게 되는 것이다.

반면, 많은 사람들이 GNU를 그 친구들을 통해서 구한다면, 이런 종류의 회사들은 성공할 수 없을 것이다. 이는 GNU를 보급하는데 광고가 필요한 것은 아님을 보여준다. 그렇다고 한다면 무료로 보급되고 있다는 사실이 무료로 알려지는 것을 바라지 않을 만한 이유가 있겠는가? 자유 시장 경제에서는 광고에 의하지 않은 전파 방식 또한 충분히 가능한 것이다. (4)

"나의 회사는 경쟁사들에 대한 우위를 차지하기 위해 독점적인 운영체제가 필요하다."

GNU는 시스템 소프트웨어를 경쟁이라는 범주에서 제외시킬 것이다. 당신의 회사가 우위를 차지할 수 없는 것처럼 당신의 경쟁사들도 그 점에 있어서는 마찬가지일 것이다. 당신과 당신의 경쟁사들 모두 이 분야에서는 별반 이득을 볼 수 없겠지만 다른 분야에서 서로 경쟁하는 것은 가능할 것이다. 당신의 사업이 운영체제를 판매하는 것이라면 GNU가 마땅치 않게 생각 될 것이다. 당신의 사업이 이런 종류가 아니라면 GNU는 시스템 소프트웨어에 관련된 막대한 비용을 절감해 줄 것이다.

나는 제작자와 사용자들이 GNU의 발전에 기여해 나감으로써 서로의 비용을 절감할 수 있기를 희망한다. (5)

"프로그래머는 자신의 창의력에 대한 보상을 받을 자격이 있지 않은가?"

보상받을 만한 일이란 사회적 공헌을 말한다. 창의성이란 그 결과물을 사회가 대가 없이 사용할 수 있을 때 사회적 공헌이 되는 것이다. 어떤 혁신적인 프로그램을 제작한 사람이 그에 대해 보상을 받아야만 한다면, 같은 맥락에서 그것을 자유롭게 사용하지 못하게 한다면 그때는 제재를 받아야 할 것이다.

"프로그래머는 그의 창의력에 대한 보상을 요구할 수 없는가?"

유해한 수단을 사용하지 않는다면, 노동에 대한 보수와 자신의 소득이 극대화되기를 바라는 것은 아무 문제가 없다. 그러나 지금 까지 소프트웨어 산업에서 보편화된 수단은 유해한 방법이다.

프로그램을 사용하는 것에 제한을 둠으로써 돈을 벌어들이는 행위는 프로그램이 사용되는 범위와 방식을 제한하기 때문에 유해한 것이다. 이는 인간들이 프로그램으로부터 얻을 수 있는 인간적인 풍요로움을 전체적으로 감소시키는 것이다. 프로그램의 자유로운 사용에 대한 제한은 결국, 유해한 파괴 행위라고 할 수 있다.

선량한 시민이라면 자신이 보다 부유해지기 위해 그런 수단을 쓰지 않는다. 그 까닭은, 만일 모든 사람들이 그렇게 한다면 상호간의 유해한 행위로 인해 결과적으로 우리 모두는 보다 빈곤해 질 것이기 때문이다. 이것은 칸트의 윤리학(네 의지의 준칙이 언제나 보편적 입법의 원리로서 타당하게 행동하라-실천이성비판)이나 황금률같은 분명한 것이다. 나는 모든 사람들이 자기만의 정보를 축적해 나가는 것은 바람직하다고 여기지 않기 때문에, 누군가 그런 일을 한다면 그것이 잘못된 일이라고 생각한다. 특히, 한 개인의 창의성을 보장받고자 하는 욕구가 일반적으로 전체의 창의성이나 혹은 그 일부분을 저하시키는 행위를 정당화시키는 것은 않는다.

"프로그래머들의 밥줄이 끊기지 않을까?"

나는 모든 사람이 프로그래머가 될 필요는 없다고 답하고 싶다. 아마 우리들 대부분은 거리에 나가 인상을 써서 간신히 약간의 돈을 벌어 살아갈 수는 없을 것이다. 그러나 결과적으로, 우리는 거리에 나가 인상 써서 돈을 번다고 비난받을 필요도 없고, 또한 빈궁해질 필요도 없을 것이다. 우리는 그와는 다른 일을 할 수 있을 것이다.

그러나 이것은, 프로그래머는 소프트웨어를 소유하지 않으면 단 한푼도 벌 수 없다 라는 질문하는 사람의 독단적인 가정을 받아 들였다는 점에서 오답이라 할 수 있다. 아마도, 이런 생각은 극단적일 것이다.

프로그래머가 생계에 지장을 받지 않을 것에 대한 진정한 이유는 지금과 같은 정도는 아니겠지만 여전히 프로그래밍으로 돈을 벌 방법들이 있기 때문이다.

프로그램의 복제를 제한하는 것이 소프트웨어 사업에 있어서 유일한 이윤 창출 방법은 아니다. 이런 방식이 보편화된 것은 이렇게 함으로써 가장 돈을 많이 벌 수 있기 때문이다. 고객들에 의해 이런 방식이 거부되거나 금지된다고 해도, 소프트웨어 사업은 지금까지 흔하지는 않았던 새로운 방식으로 전환해 나갈 길을 모색할 수 있을 것이다. 사업에 있어서 이윤 창출 방법은 무궁 무진한 것이다.

아마 새로운 기반 하에서의 프로그래밍은 지금처럼 수익성이 높은 일은 아닐 것이다. 하지만 이것이 변화의 쟁점은 아니다. 지금의 판매 사원들은 그들의 봉급을 버는 방식이 불합리한 것이라고 생각하지는 않는다. 프로그래머들이 그와 같은 방법으로 소득을 올린다 해도 하등 정당하지 못할 이유가 없다(실제적으로 프로그래머들은 여전히 그들보다 월등히 많은 소득을 올리고 있다)

"창작물의 사용 제한 여부는 창작자 자신이 갖고 있는 권리가 아닐까?"

"특정 창작물에 대한 사용을 통제하는 것"은 결국 다른 사람들의 삶에 대한 통제를 의미한다. 이는 다른 사람들의 삶을 위축시키는 것이기 때문이다."

지적 소유권에 관해 상세하게 공부한 사람들(변호사 등)은 그 자체로서 완벽한 지적 소유물은 없다고 주의 깊게 말한다. 정부가 인정하는 추상적인 지적 소유권들은 특정 목적을 위한 특정 법률 조항으로부터 발생한 것이다.

예를 들어, 특허제도는 발명가가 그의 고안품의 세부 사항을 공개하는 것을 장려하고자 설립된 것이다. 그 목적은 발명한 사람을 돕기보다는 사회를 돕기 위한 것이다. 시간의 측면에서 보면, 특허가 갖는 17년간의 유효기간은 기술이 발전하는 비율과 비교해 볼 때 짧다. 특허권은 생산 업자들 사이의 문제이고 생산을 향상시키는 것과 비교해서 특허권 계약에 드는 비용과 노력은 적다고 보기 때문에 특허권은 일반적으로 그다지 해롭게 작용하지 않는다. 또한, 그것은 대부분의 개인들이 특허 받은 제품을 사용하는 것을 제한하지는 않는다.

고대에는 저작권이라는 것이 존재하지 않았으며 그 시대의 작가들은 빈번하게 다른 이의 작품 상당량을 소설 이외의 작품에 복제하기도 했다. 이런 작업들은 유용한 것이었으며 비록, 그 일부분이기는 하지만 많은 사람들의 작품이 계속해서 전수되는(존재해 나가는) 유일한 방법이었다. 저작권 제도는 작가 의식을 고취시키려는 의도로 만들어진 것이다. 이것이 처음 만들어 질 때 주로 염두에 두었던 책의 범주에서 보면 책은 별도의 비용에 의해서 인쇄기를 사용해서만이 복제가 가능하기 때문에 저작권은 그다지 해롭지는 않았다. 또한, 대다수의 사람들이 책을 읽는 것을 제한하지도 않았다.

모든 지적 소유권은 그것들이 어떻든지 그를 허용함으로써 사회 전체에 이득이 된다고 여겨져서 사회가 허용할 때만 정당하게 되는 것이다. 그러나 어떤 특정 상황에서든 우리는 "그런 허가를 내주는 것이 정말로 우리에게 유익한가? 어떤 종류의 허가를 내줄 것인가?" 하는 질문을 해보아야만 한다.

오늘날의 프로그램들의 경우는 백여년전의 책의 경우와 크게 다르다. 프로그램이 이웃간에 손쉽게 복사될 수 있다는 사실, 소스 코드와 목적 코드로 구분된다는 점, 단순히 읽거나 즐기기 위해서 사용되지는 않는다는 사실들이 묶여져서 저작권을 강요하는 사람들은 사회 전체에 정신적, 물질적으로 해를 끼치는 상황을 만들고 있으며 법적 허용 여부에 상관없이 사용자들의 이용을 제한하고 있는 것이다.

"경쟁함으로써 보다 나은 결과를 얻을 수 있는가?"

경쟁의 기본 원리는 경주(race)이며 승자에게 상을 줌으로써 주자들이 더욱 빨리 달리도록 장려할 수 있는 것이다. 만약 자본주의가 실제로 이런 방식을 따른다면 이는 바람직한 것이다. 그러나 자본주의 옹호론자들은 실제로 항상 이런 방식으로 움직인다고 단정짓는 잘못을 범한다. 만일, 주자들이 상이 주어지는 이유를 망각한 채 승리에만 집착한다면 말할 것도 없이 그들은 다른 주자를 공격한다든지 하는 색다른 전략은 찾게 될 것이다. 주자들이 먼저 싸우기부터 한다면 그들은 결국 모두 늦어질 수밖에 없는 것이다.

독점적이고 비밀에 싸인 소프트웨어는 도덕적으로 먼저 싸우기부터 하는 주자들과 동일하다. 슬픈 일이지만 우리의 유일한 심판은 그다지 공정해 보이지 않으며 "매 10 야드(yard)마다 한번씩 상대방을 가격할 수 있다."는 규정을 적용하는 정도일 것이다. 싸움에 대한 조짐이 있을 때조차도 벌칙을 주어야 하는데도 말이다.

"금전적인 특혜가 없다면 아무도 프로그래밍을 하지 않을 것이다."

실제적으로, 많은 사람들이 분명한 금전적인 특혜가 없이도 프로그래밍을 할 것이다. 프로그래밍은 어떤 사람들에게는 저항할 수 없는 매력인 것이며 보통 프로그래밍에 능숙한 사람에게 더욱 그렇다. 비록 생활의 기반이 될 가망이 없더라도 꾸준히 계속해 가는 직업적인 음악인들이 많이 있다.

그러나 실제로 이 질문은 비록 일반적으로 많이 제기 되지만 조금은 다른 관점의 문제라고 할 수 있다. 프로그래머들의 소득원이 없어지는 것이 아니라 단지 수입이 줄어드는 것이기 때문이다. 따라서, 올바른 질문은 "금전적인 보상이 줄어들더라도 사람들이 프로그래밍을 하게 될까?"일 것이다. 내 경험에 의하면 그렇게 할 것이라고 생각한다.

십년 이상 동안, 세계 정상급 프로그래머들이 인공 지능 연구소에서 일했었지만 그들이 받은 보수는 다른 어떤 곳에서 기대할 수 있는 것보다 훨씬 적은 것이었다. 그들은 사회적 인정이나 명성과 같은 다양한 종류의 비금전적인 보상을 받았다. 그리고 창의력은 그 자체가 이미 보상과 흥미를 내포하고 있는 것이다.

그후, 그들 대부분은 이전의 작업처럼 그들이 흥미롭게 생각하는 일을 높은 보수를 받으며 할 수 있는 기회가 주어지자 연구소를 떠났다.

이 사실에서 알 수 있는 것은 사람들은 부유해지기보다는 나름대로의 어떤 까닭을 위해서 프로그래밍을 한다는 것이며 그런 조건 위에 상당한 보수까지 받을 기회가 주어진다면 그를 예상하고 요구하게 되는 것이다. 보수가 낮은 조직은 높은 보수를 받는 조직과의 경쟁에서 뒤지겠지만 만일, 높은 보수를 받는 조직이 허용되지 않는다면 훌륭하게 활동할 수 있을 것이다.

"우리는 프로그래머가 절대적으로 필요하다. 만일 그들이 우리의 이웃을 돕지 말라 하면 우리는 따를 수밖에 없다."

당신들은 결코 그런 종류의 요구에 복종해야 할만큼 절박하지 않다. 명심하라. 열 장정이 도둑 하나를 막지 못하는 법이다.

"프로그래머들도 어떤 식으로든 그들의 생계를 꾸려 나가야 하지 않은가?"

요컨대 이것은 진실이다. 그러나 프로그램의 사용에 대한 권리를 파는 것 이외에도 생계를 꾸릴 수 있는 수많은 방법들이 있다. 현재 사용에 대한 권리를 파는 것이 보편적으로 받아들여지는 것은 그런 방식으로 프로그래머나 사업자들이 보다 많은 돈을 벌 수 있기 때문이지 결코 이것이 생계를 유지하는 유일한 방법이기 때문은 아니다. 다른 방법을 찾고자 한다면 얼마든지 가능할 것이다. 여기 여러 가지 예들이 있다.

새로운 컴퓨터를 내놓는 제조업자는 새 기계에 운영체제를 이식하기 위한 비용을 지불하게 된다.

교육, 단순 관리 작업, 지속적인 서비스들을 제공하는 회사에서도 역시 프로그래머는 필요한 것이다.

사용자의 마음에 흡족하다면 그에 대한 기부를 지원해 달라고 요구하는 프리웨어(freeware)라는 새로운 아이디어로 프로그램을 배포하는 사람들도 있다. 혹은 단순 관리 서비스를 제공하고 보수를 받는 사람들도 있다. 나는 이미 이런 방식으로 성공한 사람들을 만났다.

도움이 필요한 사용자들은 사용자 그룹을 결성하고 회비를 조성할 수 있을 것이다. 그룹은 프로그래밍 회사와 계약을 맺고 회원들이 원하는 프로그램을 주문 제작할 수 있을 것이다.

모든 종류의 발전에 필요한 기금은 소프트웨어에 대한 세금으로 조성할 수 있을 것이다.

만약, 컴퓨터를 구입하는 모든 사람들이 가격의 몇 퍼센트를 소프트웨어에 대한 세금으로 지불해야 한다면, 정부는 그 돈이 소프트웨어 발전에 쓰여지도록 국립 과학 재단(NSF-National Science Foundation) 같은 단체에 위임할 수 있을 것이다.

여기에는 컴퓨터 구입자가 세금을 납부하는 것 대신에 개별적으로 소프트웨어의 발전을 위해서 특정 부문에 기부하는 형식이 포함될 수 있을 것이다. 그는 스스로 어느 프로젝트에 기부할 것인지를 결정할 수 있을 것이며 때론, 그 결과를 쓸 수 있을 것이란 기대를 품고 결정을 내리게 될 것이다. 얼마를 기부하든 지불해야 할 세금 전액을 대신할 수 있을 것이다.

세금의 전체적인 세율은 납세자들이 투표를 해서 결정할 수 있을 것이며 지불할 액수에 따라 차등 조정될 것이다.

따라서, 결론은 다음과 같다:

컴퓨터 사용자 공동체는 소프트웨어의 발전을 지원한다.

어느 수준의 지원을 할 것인가에 대한 사항을 공동체 모두가 함께 결정한다.

자신의 몫이 어떤 프로젝트에 쓰일 것인가에 관심 있는 사용자들은 이를 스스 결정 할 수 있다.

프로그램을 자유롭게 만든다는 것은 결국, 더이상 생계를 위해 고되게 일할 필요가 없는 풍요로운 세계로 가는 한 단계인 것이다. 사람들은 법률 제정이나 가정 상담, 로보트 수리, 천체 관측 등의 주당 열 시간 정도의 근무 시간을 마친 후에는 프로그래밍과 같은 자신이 흥미를 가질 수 있는 일에 자신을 몰입할 수 있는 자유를 갖게 될 것이다. 더이상 프로그래밍을 생계의 수단으로 삼을 필요가 없게 될 것이다.

우리가 이미 풍요로운 사회를 만들기 위해 많은 일들을 했음에도 불구하고 여가 시간이 아직 충분히 보장되지 않고 있는 이유는 자유 경쟁에 반하는 관료 제도와 저항들에 의해서 생산적인 활동에 많은 비생산적 요소들이 개입되기 때문이다. 자유 소프트웨어는 이러한 문제들을 충분히 개선시켜 나갈 수 있을 것이고 그렇게 함으로써 풍요를 위한 우리의 기술적 성과들이 우리들 자신의 노동을 감소시킬 수 있도록 해야 할 것이다.


각 주 (1) 자유라는 의미를 명확하게 설명하지 못했다. 본래의 의도는 GNU 시스템을 사용 하기 위해서 '사용 허가'에 대한 별도의 비용을 지불할 필요가 없다는 뜻이다. 이러한 점을 명확히 하지 않음으로 해서 GNU 프로그램은 항상 무료나 이에 준 하는 가격에 의해서만 제공된다는 잘못된 해석이 가능할 수 있었다. GNU 선언 문은 이러한 부분에 대해서 이윤 추구를 위한 상업적 배포 업체 또한 충분히 가능할 수 있다는 사실을 뒤에 언급하고 있다. 나는 금전적인 측면의 자유와 구속되지 않는다는 관점에서의 자유를 주의 깊게 구분해서 사용해야 한다는 교 훈을 얻게 되었다. 자유 소프트웨어란 사용자가 배포와 수정의 자유를 갖는 소프트웨어를 의미한다. 자유 소프트웨어는 유료 또는 무료로 구입할 수 있 으며 유료 구입에 의한 기금의 확충은 해당 소프트웨어를 보다 우수하게 향상 시키는데 기여할 수 있을 것이다. 자유 소프트웨어의 핵심은 소프트웨어의 자 유로운 이용을 통해서 사용자 상호간의 협력의 자유를 보장받는다는 데 있다.

(2) 자유라는 두 가지 다른 의미 중에서 본래의 의도를 명확히 제시하지 못한 것 같다. 자유가 다른 의미를 내포할 수도 있지만 여기서는 가격을 지불하지 않는 다는 뜻으로 사용된 것이다. 즉, GNU 소프트웨어는 친구나 네트워크를 통해서 무료로 얻을 수 있다.

(3) 이러한 종류의 몇몇 회사들이 이미 활동하고 있다.

(4) 자유 소프트웨어 재단은 이윤 추구를 목적으로 하지 않음에도 불구하고 대부분 의 운영 자금을 배포본 판매에 따른 수익금에 의해서 충당하고 있다. 아무도 우리로부터 제품을 구입하지 않는다면 우리는 재단을 지탱해 나가지 힘들게 될 것이다. 그러나, 이것이 모든 사용자에게 유료 구입을 강요하는 제한 사항이 될 수는 없다. 제품 구입에 대한 소수의 도움으로도 자유 소프트웨어 재단은 충분히 유지될 수 있으며 우리는 일반 사용자들이 이러한 방식으로 우리를 지 원해 주기를 요청한다.

(5) 최근 들어 컴퓨터 회사들의 모임 중 하나는 GNU C 컴파일러의 개발을 지원하기 위한 기금을 조성했다.
2006. 9. 16. 13:17

배포판 제작하기, Part 1
Gentoo Linux 배포판의 탄생

난이도 : 초급
Daniel Robbins, CEO, Gentoo Technologies, Inc.
2000 년 11 월 01 일
Linux를 경험해본 적이 있다면 각자 나름대로의 이야기 거리를 가지고 있을 것이다. 이 글은 Daniel Robbins의 Linux 이야기이다. 세 개의 시리즈 중 첫번째 순서에서는 필자가 Stampede Linux의 개발자가 된 경위와 Stampede를 떠나 Enoch라는 자신의 배포판을 제작하기 시작한 이유를 설명한다.
Linux 와 나
Linux 라는 "괴짜"를 다루다 보면, Linux가 그 이름이 가지는 의미 이상으로 더 훌륭하고 강력하며 매력적인 부분이 있다는 것을 알 수 있을 것이다. 나는 이 것을 New Mexico 대학에서 시스템 관리자로 일하고 있을 때 체험하였다. 내가 맡고 있는NT 서버는 원활히 가동되고 있었고 따라서 나에겐 여유 시간이 있었다. 그래서 펜티엄 166 서버 박스에 Debian (Linux 배포판에 포함됨)을 설치하고 독학하기 시작했다. 배우고, 배우고 또 배웠다. 그러다가 헤어나지 못할 정도였다.
처음엔 Linux에 대한 기본적인 모든 것을 학습하였다: 이것저것 다루어 보고, 백업하고, Samba 실행하는 방법 등도 학습하였다. 그리고 qmail과 Apache를 설치하고 Python과 shell프로그래밍을 배웠다. 부서의 Intranet을 구축하고, 집에 Linux를 설치했으며 다른 배포판을 시도하기 시작했다. 결국 Stampede Linux로 결정했다. 이 과정이 어떻게 진행되는지 알 것이다. 처음에는 Linux의 기초를 파악하기 위하여 애쓴다. 어느 정도 사용에 익숙해지면, 배워가면서 자신의 Linux를 만들게 된다. Linux는 숨길 것이 없기 때문에, Linux를 기동할 수 있는 테크놀로지와 툴을 익힐 수 있다.

Linux의 잠재성
Linux는 내가 기존에 알지 못했던 무엇인가를 제공했다. 그 마력을 단어로 표현하면 바로 잠재성이라 하고 싶다: 상황을 변화시키고, 개선하고, 결정하며, 또한 파괴시킬 수도 있는 바로 그 잠재성이다. 새로운 커널 버전으로 업그레이드하면서, 눈앞에서 Linux가 향상되고 스스로 변형하는 것을 거의 매일 발견한다. 나는 그 과정 자체를 따라갔다! 이미 나는 변형의 한 부분이 되어 있었다. 유쾌했다.
여러분도 나와 같은 경우라면, Linux와 오픈 소스에 관심을 갖기전에는 여러분이 원하던 일을 실현시켜줄 것 같은 차세대 운영체제를 제공하는 Redmond 와 Cupertino와 같은 대그룹들을 주목했을 것이다. 그러나 그 꿈은 전혀 실현되지 않았다. 그리고 기다리는 동안, Linux가 나타났다. 수정되어야 할 부분이 많지만, Linux는 해커들이 다음의 거물을 기다리는 동안 개선 가능한 것을 제공했다. 그리고 어느날 잠에서 깨었을 때, Linux는 다음의 거물이 되어 있었다.

Linux와 사람.
다음으로 내가 배운 것은 Linux가 사람과 비슷하다는 것이다. 신선하지 않은가? Linux는 소스 코드의 묶음이 아니다. Linux는 커뮤니티다. 질문에 관련 해답을 찾기 위해 이 커뮤니티에 의지하고, 시간과 전문성을 할애하여 다른 사람들을 돕게 되면 커뮤니티의 일부분이 된다.
IRC(Internet relay chat)는 사람들을 만나고 어마어마한 시간이 허비되는 대단한 장소다. irc.openprojects.net의 #stampede 채널은 나의 공식적인 아지트가 되었다. 거기에서 Linux에 관한 질문을 했다. 그곳에서 또한 나는 처음으로 다른 사람들을 도와주었다. #stampede는 이제 막 배포판을 설치한 초보자들을 도울 수 있는 Linux 사용자가 매우 부족했다. IRC에서 대개 그렇듯이, 경험 많은 Stampede 사람들이 newbie관련 질문에 답변하려는 열정을 잃어버렸다. 하지만 나는 사실 질문에 대한 해답을 가지고 있었고, 돕는 일을 중지할 수 없었다! 이렇게 하여 Stampede에 참여하게 되었다. 나는 질문에 답변하기 좋아하는 그런 부류였다. 내가 이타적인 사람이라서 그런 것이 아니라 Linux 관련 지식 전문가가 되고 싶었기 때문이다.

참여
오픈 소스 프로젝트에 참여하는 방법에 대해 질문하면, 비록 기초적인 Linux 관련 질문에 대한 것이라도 사용자가 도움을 줄 수 있는 장소를 먼저 찾으라고 말한다. 타인을 돕고자 하는 진실한 욕구가 Linux 커뮤니티에 참여할 수 있는 훌륭한 입장권이다. 이러한 감정이 Linux를 포함한 모든 오픈 소스 개발의 중심이기 때문이다. 적어도 그렇게 되어야 한다.
시간이 지날 수록 더 많은 해박한 지식을 가진 사용자를 만날 것이다. 여러분은 그들에게서 배울 것이다. 마치 초보자들이 여러분에게 계속 배우는 것 처럼 말이다. 또한 경험이 많아짐에 따라, 새로운 방식으로 도울 기회들을 접할 것이다. 접할 지도 모르는 프로젝트 개발자들이, 어떤 것을 제안하거나 그들 스스로 도움을 요청할 수도 있다. 개발 팀의 일원이 되도록 여러분을 초대까지 할 수도 있다. 다른 사람들을 돕는데 집중한다면, 그들은 어리석게도 여러분을 지나칠 것이다. 많은 사람들을 계속 돕고 있다면, 커뮤니티에서 분명히 눈에 띨 것이다. 바로 이것이 Stampede와 나에게 발생한 일이다.
점차적으로 Stampede 개발에 깊숙하게 참여하게 되었다. 이윽고 공식적인 Stampede 개발자가 되었다. 한 스키광의 찬성을 얻어 (Matt Wood, Stampede의 리더), Stampede의 초기 .slp 패키징 포맷의 새로운 버전 발표를 준비하기 시작했다. 당시 .slp 패키지 포맷은 끝에 붙은 고정 길이의 풋터(fixed-length footer)를 가진 .tar.bz2 아카이브로 구성되었는데, 이 풋터(footer)는 패키지의 저자, 내용 설명, 패키지의 창안자 등에 관한 정보를 제공한다. 이 접근법은 두 가지의 중요한 문제를 가지고 있다. 하나는 필드 길이의 고정이고 다른 하나는 작은 풋터의 사이즈와 포맷에 내장될 확장성이 없다는 것이다 (.slp 포맷에 필드 추가할 수 있는 방법이 없다). 분명히 철저한 정비가 필요했다.
Stampede 선임 개발자들과 일하면서, 이 문제를 해결할 수 있는 방법에 대한 제안서를 작성했다. 그때 Python으로 프로토타입 툴(prototype tools)을 코딩했다. 새로운 포맷은(코드네임 slpv6) Amiga의 IFF 파일 포맷과 어느 정도 유사했다. 이 차세대 .slp 포맷은 232개의 필드, 232개의 필드 카테고리, 그리고 232바이트의 필드 데이터 최대길이를 허용했다. 포맷은 막강한 확장성 뿐만 아니라, 또한 평문(plain text)보다 콤팩트하고 파싱하기가 쉬웠다. 텍스트와 이진 데이터 모두 포맷에 저장이 가능하므로 향후 많은 가능성을 가지고 있었다. 이 차세대 동적 헤더를 아카이브 파일의 끝에 부착하는 아이디어인데, 이로써 수 년간 Stampede 사용자들이 쓸 수 있으며 동시에 유닉스 표준 아카이브 포맷과도 호환성을 유지하는 차세대 .slp 포맷이 나온 것이다.

사람들과의 관계
slpv6의 개발은 순조로웠고 모든 선임 개발자들은 나의 진보를 기뻐했다. 그러나 불행하게도, Stampede 하급 개발자 두 사람이 slpv6 프로젝트를 통제하려고 했다. 그들은 나의 추진 의도에 반대하였고, 오랫동안 새로운 slpv6 시스템을 비난하였다. 몇 시간 동안 열띤 개발 토론에서 그들의 공격을 방어했지만, 어떤 해결점을 찾지 못했다. 본능적으로 논쟁하기를 좋아하고, 그들의 의도대로 진행될 때까지 만족하지 못한다는 것도 발견하였다. 다행스럽게, 나의 프로젝트가 Stampede 선임 개발자들의 승인을 얻었다. 그러나 이러한 토론에 신물이 났고, Stampede 개발을 무미건조하게 만들었다. 윽!
고급 개발자들과 채팅하기 위해서 #stampede 채널을 자주 방문해야 했기 때문에, 그 개발자들을 배제시킬 수 없었다. 내가 그 채널에 있을 때마다, 그들은 곧 전투적인 태세로 나의 일을 폄하하려 했다. 사실상 선임 개발자들 앞에서 나의 작업을 모욕할 절호의 기회인 개발회의 소집을 요구하는 식의 정당하지 못한 수법들을 사용했다. 그들은 또한 Stampede의 통제권을 장악하기 위해 투표를 요구하기도 했다. 물론 그들의 의견에 동의하는 사람들이 많이 있다고 판단될 때만 투표를 요구했다. 이런 과정을 겪으면서 나는 slpv6 개발 작업을 계속했다. 말할 필요도 없이 선임 개발자들은 나의 작업을 인정하여 계속 개발하기를 원했다. (그들의 지지가 없었다면 나는 끝까지 견디지 못했을 것이다).

"괴물(freak)" 이해하기
그 두 개발자들은 "괴짜" 라고 부르고 싶은 개발자 범주에 속한다. 비록 그들이 나의 개발작업을 아주 재미없게 만들었지만, 나 또한 그들을 다루면서 많은 것을 배웠다. 여기에서 여러분에게 괴짜 개발자에 관한 일종의 포괄적인 개요를 제공하고 싶다: 괴짜들의 자질, 그들의 수법, 그리고 개발 프로젝트의 리더인 여러분이 그들과 대결하여 가능하면 많은 노력을 들이지 않고 그들의 마음을 바꾸게 하는 방법.
감정적인 상처를 피하기 위하여, 하나의 전제조건이 필요한데 그것은 지조이다. 정중하지만 단호한 태도로 괴물들을 맞설 수 없다면, 희망이 없다. 괴물들의 목적은 가능한 한 많이 여러분의 프로젝트를 통제하여, 자신이 강력하다고 느끼는 것이다. 이렇게 되기 위하여 괴물들은 몇 가지 수법을 사용할 것이다. 첫째로 그들은 프로젝트와 프로젝트를 수행하는 개발자에 대하여 불공평하게 비평하거나 심하게 불평하기 시작한다. 그때 그들은 어떤 건설적인 대안 제시는 하지 않는다. 그들은 또한 그들이 프로젝트 메니저로 승진되지 않는다면, 그 프로젝트를 도우려고 하지 않는다. 그들의 목적은 그들의 눈에만 보이는 문제들을 그들이 해결할 수 있도록, 여러분의 신임을 얻어 가능한 한 많은 권위를 얻으려는 것이다.
비평과 불평이 효과가 없다면, 그들은 개발자 회의를 요구한다. 이 회의는 여러분의 개발팀을 시험하고 두 패로 나누는 그들의 계획이다. 그들 편으로 충분히 많은 사람들을 섭외 했다고 판단될 때 선거를 요구한다. 당연히 이길 게임이다. 그들이 선거에서 지거나 제압당하면, 다음주의 또 다른 개발자회의를 강행하는데, 여기에서 그들은 다시 여러분의 개발팀을 분열시키려고 한다. 그들은 이러한 과정을 끊임없이 되풀이할 것이다.
개발자회의 접근법이 여의치 않으면, 그들은 개혁가로 변한다. 이 역할을 채택하여 그들은 강압적이고 불공정한 경영 의사결정 과정을 "민주적인"(=그들이 쉽게 좌지우지 할 수 있는) 것으로 변경하는 합리화를 시도한다. 이러한 합리화는 종종 개발자중의 다수가 원하는 것은 무엇이든지 해야 한다는 확신을 갖도록 한다. 그때 여러분은 더 이상 개발자회의 투표를 뒤엎을 수 없기 때문에 괴짜들은 이 방식을 사랑한다. 이런 방식이 허용되면, 근본적으로 Lexus의 열쇠를 괴짜들에게 내준 것이다.
다른 접근법으로, 괴물들은 창조적인 개발자를 내몰 것이다. 괴물들이 프로젝트의 권력구조를 개혁하려고 강력하게 시도함에 따라, 그들은 전체 팀을 광란의 상태로 몰아넣을 것이다. 만약 그들의 노력이 실패한다면, 그들은 결점이 있는 사람들을 가능한 많이 불러 모아 프로젝트에서 분리시키려고 할 것이다.

괴물들 다루기
이러한 녀석들은 꽤 쉽게 구별된다. 그들은 코드를 작성하지 않는 자들이다(하려고 하지도 않는다). 그대신 보다 중요한 것에 대하여 이야기하며 시간을 보낸다. 알다시피 관리상의 이슈들이다. 프로젝트의 리더라면, 그들을 꽤 쉽게 다룰 수 있다. 작업 코드(working code)를 만들지 않으면 어떠한 제안도 고려하지 않겠다고 그들에게 말하라. 그렇지 않으면 그들에게 (건설적인)비평의 기회를 주기 전에, 현재의 프로젝트에 건설적으로 협조하라고 주장하라. 이것은 현재의 프로젝트 메니저에게 복종하는 것을 함축하고 있다. 그들이 약간의 괜찮은 코드를 작성하거나 보다 협조적으로 된다면, 훌륭하다. 그렇지 않다면, 떠나라고 말하라. 그들은 프로젝트를 떠나거나(여러분이 그들을 충분히 오래 무시한다면), 또는 코드를 작성하고, 대개는 좀더 즐거워하게 될 것이다.
애석하게도 Stampede 선임 개발자들은 괴물 관리에 책임을 지지 않았다. 달리 말하면, 그들은 이 두 녀석들이 나를(그리고 다른 사람들을) 끝없이 괴롭히도록 허용했다. 선임 개발자들은 항상 나의 개발작업에 호의를 가졌지만, 이 녀석들을 다스리려고 노력하지는 않았다. 그래서 어느날 나는 이 두 괴물을 참고 지내야 하는 것보다는 내 자신의 배포판을 만드는 것이 더 편할 것이라고 결심했다. 나는Stampede 개발에서 물러나 자체 배포판을 만들 계획을 세우기 시작했다.
두 저급 개발자 때문에 프로젝트를 그만둔 것이 약간 억울하지만, 그들이 사실상 관리되지 않는다는 사실은 그 프로젝트의 심각한 관리상의 문제를 나타내는 것이다. 고급 개발자들이 Stampede 개발 노력은 즐겁고 보람을 보장할 수 없거나 또는 보장하려 하지 않는다면, 그때는 그곳에 있기를 원하지 않는 것이다.

다시 시작하기
떠나고 나니 안심이 될 수 있었다. 마침내 일이 조용해졌다. 이제 배포판의 성격 및 Linux 배포판으로써 어떤 공헌을 할 지를 결정할 때이다. Stampede의 매력은 그것의 가공되지않은 성능이었다(Stampede가 실험적인 팬티엄 최적화 pgcc 컴파일러를 사용한 덕택에). 그래서 성능에 가장 중점을 두기로 결정했다. CPU의 활용을 최소화하는 것에 더하여, 부풀리기(bloat)도 최소화하고 싶었다. 많은 배포판들이(특히 대중적인 수축 포장된 것들) 디폴트로 많은 데몬을 띄움으로써, xterm을 오픈하면 RAM이 거의 남지 않게 된다. 나는 배포판이 가벼우면서도 일반적인 기능을 유지할 수 있기를 원했고, 하드웨어의 성능을 최대화하는데 중점을 두었다. 나는 전체론적인 접근법을 취하여 모든 각도에서 성능 문제에 달라붙기로 결정했다.
그러나 자료가 심각할 정도로 부족했는데 그 이유는 개발자가 나 한 사람뿐 이었기 때문이다! 맨땅에서 나 혼자 힘으로 Caldera 또는 RedHat에 버금가는 어떤 것을 창조해낼 수 있을까? 답은 자동화였다. 모든 것을 자동화하는 스크립트를 작성해야 했고, 그래서 시간이 걸리는, 반복적인 작업을 최소화할 것이었다. 결국 이것이 컴퓨터가 제일 잘하는 일이 아닌가?
나는 필요한 자동화를 위해서 단순한 스크립트 작성으로 충분하지 않으리라는 것을 즉시 발견하였다. Linux 배포판을 처음부터 구성하여 만들어 내는 완전한 시스템을 설계할 필요가 있었다. 나는 시험적으로 그것을 ebuild 시스템이라고 하고 작업을 시작했다. ebuild 시스템은, 소스의 분해(unpacking)와 패치(patching)부터 컴파일, 설치, 그리고 패키징(packaging)까지 모든 것을 자동화하면서, 모든 배포판 바이너리를 자동적으로 생성할 수 있을 것이다. 기본적인 ebuild의 프로토타입이 작동하는 것을 확인한 후, Linux 배포판의 핵심적인 구성 요소들의(gcc, glibc, binutils, util-linux, 그리고 friends같은) ebuild 스크립트를 생성하기 시작했다. 내가 초기설정 스크립트를 다시 설계하고(이전에 설계한 Stampede 초기설정 스크립트를 기본으로 하여) 새로 만든 모든 패키지를 시험하고 설치함에 따라, 나의 Stampede 개발 박스는 점차적으로 나 자신의 시스템으로 되어갔다.
몇 달 후 완전한, 스스로 주인이 된 Linux 배포판을 가지게 되었다. 그것을 Enoch이라 명명하고, 만족의 미소를 지었다. 다음에는 Enoch이 어떻게 Gentoo Linux가 되었는지 그리고 도중에서 만난 많은 새로운 도전에 대해서 이야기 하겠다.

배포판 제작하기, Part 2
Enoch에서 Gentoo로

난이도 : 초급
Daniel Robbins, CEO, Gentoo Technologies, Inc.)
2000 년 10 월 01 일
첫번째 시리즈 에서는 필자가 어떻게 Stampede Linux 개발자가 되었으며 결국 왜 Stampede를 떠나 Enoch Linux배포판을 시작하였는지 말해주었다. 이 글에서 그는 Enoch 개발팀이 불꽃같이 빠른 컴파일러를 발견한 후에 일어난 이상한 사건들을 털어놓는다.
Enoch으로 향한 첫 단계
이전의 글에서, Stampede 개발팀과 겪었던 일과 떠난 이유에 대해서 말했다. 이 쓸데없이 참견하는 구경꾼들의 간섭때문에, Stampede 개발을 계속하기 보다는 나 자신의 Linux 배포판을 만드는 것이 더 쉬우리라고 판단했다. 다행인 것은 Stampede 개발을 통하여 많은 경험을 축적했다는 것이다. Stampede 패키지를 관리했고, 초기설정 스크립트를 설계했으며, 그리고 slpv6(차세대 패키지 관리 프로젝트)를 이끌었다.
작업하기 시작한 코드네임 Enoch 배포판은 패키지 생성과 업그레이드 프로세스를 완전히 자동화하기 때문에 엄청나게 빠른 것이었다. 이것은 배포판 제작에 있어서 대부분을 차지하는 것이라고 인정하고 싶은데, 나는 one-member 팀이었고, 나의 개발용 머신이 나를 위해 자동으로 해 줄 수 있는 반복적인 일을 내가 시간을 소비하면서 할 수는 없었기 때문이다. 그리고 나는 완전한 배포판을 처음부터 구성하는 방향으로 설계하고 있었기 때문에(RedHat같은 배포판에 부수적인 변형을 하기 보다는), 힘에 겨웠고 자유시간을 모두 끌어 모아야 했다.
기본적인 Enoch 시스템을 시동하고 실행한 후, 나는irc.openprojects.net로 돌아가 #enoch라는 나 자신의 채널을 시작했다. 여기에서 점차적으로 약 열명의 팀을 모았다. 초기시절 우리는 모두 IRC(Internet Relay Chat)에서 살았고 여분의 시간에 배포판 작업을 했다. 우리가 공동으로 협동하여, 새로운 버그를 찾아내고 픽스(fix) 하면서, 잘해냄에 따라 Enoch는 나날이 보다 기능적이고 전문화되어 갔다.

첫번째 장애물
어느날, Enoch은 첫번째 장애에 부딪쳤다. Xfree86, glib, 그리고 gtk+을 추가한 후, 나는 xmms(X11/gtk+ 기반의 MP3/CD 플레이어 애플리케이션)를 넣기로 결정했다. 음악과 함께 기뻐할 시간이 왔다고 생각했다. 그러나 xmms를 설치하고 실행시켰을 때, X 윈도우는 먹통이 되었다. 처음엔 잘못된 컴파일러의 최적화 때문이라고 생각했다("-O6 -mpentiumpro" 옵션을 사용했었다.) xmms를 표준 최적화 옵션으로 컴파일해야 겠다는 이 생각은 문제를 해결해 주지 않았다. 그래서 나는 다른 곳에서 원인을 찾기 시작했다. 문제를 해결하기 위해서 일주일의 시간을 몽땅 허비한 후 Enoch사용자인 Omegadan으로부터 메일을 받았다. 그도 역시 비슷한 문제를 경험했던 사람이었다.
그와 잠시 교신하고 여러 시간동안 테스트한 후, 우리는 그것이 POSIX 쓰레드와 관련된 문제라고 결론지었다. 어떤 이유로 pthread_mutex_trylock() 함수의 호출은 리턴하지 않는 것이었다. 배포판의 창시자로서, 이러한 유형의 버그는 정말 만나고 싶지 않은 것이었다. 개발자들이 완전한 소스를 릴리즈할 것이라고 기대하고, 나는 버그가 많은 소스를 작업하기 보다는 Linux 경험을 늘리는데 집중할 수 있었다. 물론 이것은 비현실적인 기대이고, 이와 같은 문제는 언제든지 드러날 수 있다는 것을 곧 깨달았다.
문제는 xmms, gtk+, 또는 glib에 있는 것이 아님이 드러났다. 또한 Xfree86 3.3.5가 쓰레드 안전(thread-safe) 및 잠금(locking up)에 문제가 있다는 것도 쟁점사항이 아니었다. 놀랍게도, 우리는 GNU C 라이브러리(glibc) 2.1.2의 일부인 Linux POSIX 쓰레드 구현(implementation) 자체의 버그라는 것을 알아냈다. 그때 나는 Linux의 이러한 중요한 부분에도 이러한 큰 버그가 있다는 것을 알고 충격을 받았다. (우리는 Enoch에 glibc의 프리릴리즈 또는 CVS 버전이 아닌 공식 릴리즈 버전을 사용했는데도 말이다!)
그러니 어떻게 그 문제를 찾아낼 수 있었겠는가? 사실상 결코 버그 픽스(bug fix)를 모두 처리해 낼 수 없다. 나는 우연히 glibc 메일링 리스트에서 같은 문제를 가진 다른 사람이 보낸 두개의 메일을 발견하였다. 답신을 한 glibc개발자는 우리를 위하여 그 쓰레드 문제를 해결한 패치(patch)를 부쳐주었다. 그러나 패치는 방금 올라왔고 RedHat 6(glibc 2.1.2 사용)은 이미 사용 가능한 상태였는데, 어째서 RedHat은 이 문제로 고민하지 않았었을까 궁금했다. 이것을 알려고 RedHat의 glibc SRPM(소스 RPM)을 다운로드하여 패치를 살펴보았다.
RedHat은 pthread_mutex_trylock 이슈를 해결한 그들 자신의 glibc 패치를 가지고 있었다. 분명히 그들은 같은 문제에 부딪쳤고 그들 자신의 custom fix를 만들었다. 하지만 그들은 이 패치를 glibc 개발자들에게 "upstream" 보내지 않아서 세상 사람들이 그것을 공유할 수 없었다. 그러나 RedHat은 그 패치를 보냈는데 어떤 이유로 glibc 개발자들이 그것을 받아들이지 않은 이유는 아무도 모른다. 또는 컴파일러와 binutils 버전의 특정한 조합하여 유발되는 쓰레드 버그인데, RedHat은 SRPM에 쓰레드 패치를 가졌을지라도 그 버그에 전혀 부딪치지 않았을 수도 있다. 정확한 내막이 무엇인지 전혀 알 수 없을 것이라고 생각한다. 그러나 나는 RedHat SRPMs는 그들만의 많은 버그 픽스와 미조정(tweak)을 포함하고 있으며, 이러한 것들은 처음의 개발자들에게 결코 다시 보내지지 않았다는 것을 알았다. 이것에 대해서 잠깐 큰소리 좀 쳐야겠다.

큰소리치기
Linux 배포판을 만들 때, 만들어낸 버그 픽스를 처음의 개발자에게 거슬러 보내는 것은 정말 중요하다. 내가 알기로는 이렇게 하는 것이 배포판의 창안자가 Linux에 기여하는 많은 방법 중의 하나이다. 서로 다른 모든 프로그램들을 하나의 통일된 환경에서 작동하게 하는 사람은 바로 우리들이다. 사용자 모두가 하나가 되어 픽스를 거슬러 보냄으로써, 다른 사용자와 배포판이 우리가 발견한 것의 이점을 취할 수 있다. 버그 픽스를 자기 혼자만 알고 있겠다고 한다면, 누구도 돕는 것이 아니다. 다만 많은 사람들이 같은 문제를 픽스하는데 되풀이하고 또 되풀이해서 시간을 허비할 것이라는 것을 알 뿐이다. 이러한 방침은 완전한 오픈 소스(whole open source)라는 가치체계에 역행하고, Linux의 개발 성장을 멈추게 한다. 그러한 방침은 모두를 "골탕 먹인다"고 해도 좋을 것이다.
어떤 배포판은 공동체와 작업을 공유하는데 있어서 어떤 배포판(RedHat)은 다른 배포판(Debian)만큼 좋지 않다는 것은 불행한 일이다.

컴파일러 드라마
glibc 쓰레드 문제의 픽스를 시도하는 동안, 나는 Ulrich Drepper(glibc 개발에 깊숙이 참여한 Cygnus사의 개발자)에게 메일을 보냈다. 나는 우리의 POSIX 쓰레드 문제에 대해서,그리고 Enoch은 최적의 성능을 위하여 pgcc를 사용하고 있음을 보냈다. 그리고 그는 다음과 같이 응답했다. "CodeFusion 제품에 포함된 우리의 컴파일러는 뛰어난 x86 백 엔드(backend)를 가지고 있는데, 이 백 엔드는 pgcc로 생성된 것보다 훨씬 빠른 실행 코드를 생성한다." 분명히 나는 Cygnus사람들이 만든 이 신비에 쌓인 "turbo" 컴파일러를 시험해보는데 큰 흥미를 느꼈다.
거기서 바로 나는 Cygnus CodeFusion 1.0의 데모 카피를 요청했고 그것을 시험해볼 수 있었다. 그리고 Omegadan과 나는 이 컴파일러는 Ulrich가 주장한대로 이고 그 이상이라는 것을 알고 놀랐다. x86 백엔드(backend)는 CPU집중적인 실행코드(예를 들어 bzip2)의 속도를 90퍼센트 가까이 까지 끌어올렸다! 모든 애플리케이션은 실제 속도가 최소한 10퍼센트 증가하는 것으로 보였고, 우리가 해야 할 일은 컴파일러를 교체(swap)하는 것이었다. Enoch도 30~40퍼센트 빠르게 부트 되었다. 속도의 증가는 gcc에서 pgcc로 전환하여 얻은 것보다 훨씬 컸다. 스스로 그것을 경험한 후, 분명히 이 컴파일러를Enoch용으로 쓰고 싶었다. 운 좋게도, 그 소스는 CodeFusion CD에 포함되어 GPL 하에서 릴리즈 되었으므로, 이 컴파일러를 마음 놓고 쓸 수 있었다. 아니, 그렇게 생각했다.

이상한 일이 벌어지다
우리의 생각을 알리려고 Cygnus의 마케팅 매니저에게 메일을 보내면서, "네 가져가세요, 이용해주셔서 감사합니다."라는 대답을 기대했다. 하지만 대답은 다음과 같았다. 우리가 Cynus 컴파일러를 사용하는 것은 (기술적으로) 허용되지만, 그 컴파일러 소스를 Enoch과 함께 사용하거나 또는Enoch에 포함시켜서는 안 된다는 것이었다. 나는, 만일 그렇다면, GPL하에서 소스를 릴리스 한 이유가 무엇이냐는 질문으로 응답했다. 추측하건데, 그들에게 선택이 있었다면 GPL을 사용하지 않았겠지만, 그들의 컴파일러는 egcs(GPL하에서 릴리스)로 부터 파생된 것이었기 때문에 선택의 여지가 없었던 것이다.
이것은 GPL이 어떤 회사가 오픈 소스에 근거하여 독점적(proprietary) 제품을 만들지 못하게 하는 상황의 좋은 예가 된다. 내 경험에 의한 추측은 이렇다. Cygnus는 우리가 그들의 컴파일러를 사용하면, 그들의 박스 제품 판매가 약화된다고 우려한 것이다. 그러나 그들의 어떠한 마케팅 기구도(InfoWorld 리뷰 또한) CodeFusion에 포함되는 새로운 컴파일러를 언급하지 않았기 때문에 특히 이상했다. CodeFusion은 컴파일러가 아니라 통합 개발 환경"development IDE"으로만 판매되는 제품이다.
그들의 편집광을 진정시키려고, 나는CodeFusion을 지지하고 그것의 판매를 도울 링크로서 우리의 웹 사이트에 보증선전(endorsement)을 둘 것을 제의하였다. CodeFusion은 IDE로서 출시되었기 때문에, 개인적으로 "turbo" Enoch이 그들의 판매에 부정적인 영향을 미친다고 생각하지 않았다. 그럼에도 불구하고 나는 그들을 기분 좋게 하려고 하였다. CodeFusion의 구성 요소인 IDE는 상품이었고, 우리는 그것을 Enoch과 함께 배포할 어떠한 욕구와 의도(또는 권리)도 없었다.
나의 (관대한?) 제의를Cygnus에 보냈고 또 다른 이상한 응답을 받았다. 그들은 우리의 모든 "marketing materials"에 대한 권한을 요구했다(또한 분명히 우리의 웹사이트의 컨텐츠도 포함했다!). Cygnus의 마케팅 팀은 Linux공동체 또는 GPL의 작업방식을 전혀 파악하지 못한 것 같았다. 그래서 나는 Cygnus와의 교류를 아주 끊어버리기로 결심했다. 그 동안에 우리는 비공개적으로는 "turbo"이면서 공개적으로는 "non-turbo" Enoch 버전을 만들었고, 최종결정을 뒤로 미루었다.
그러나 몇 달 후Cygnus는 CodeFusion x86 백 엔드를 gcc 2.95.2에 통합했다. CodeFusion CD에 포함된 "비밀의 GPL 컴파일러"에 대하여 아는 사람들은 아니지만, 이제 누구나 새롭고 좋은 백 엔드의 이득을 얻을 수 있었다. 하지만 우리는 계속 진행하면서 CodeFusion 컴파일러보다는 gcc를 사용하기로 결정했다. 보다 안정적인 것에 더하여, gcc 2.95.2를 사용함으로써Cygnus를 피할 수 있었는데, RedHat은 이때까지 터무니없는 가격으로 Cygnus를 구입해왔다. (note: gcc 2.95.2의 새로운 x86 백 엔드는 보다 새로운 Linux 배포판에, 우리가 경험했었던 현저한 속도의 증가를 가져 다 주었다. 그것은 또한 FreeBSD 4.0에 3.3.6을 능가하는 괜찮은 속도증가를 제공했다. 차이점이 보이는가?)

나의 생각
여러 경험들을 통하여, 영리 목적의 오픈 소스 회사들에 대하여 많은 것을 배웠다. 영리 목적의 오픈 소스 회사라는 것이 나쁜 것만은 절대로 아니다. 소스가 폐쇄된(closed-source) 소프트웨어를 독점적으로 생산하는 것이 도덕적으로 또한 나쁠 것은 없다. 그러나 오픈 소스 회사들이 GPL을 지원하지 않거나 또는 다른 어떤 방법으로 나머지 오픈 소스 세계와의 협동을 파괴하거나 거절하는 것은 이치에 맞지 않는다. 이것이 실제적인 사업 감각이다.
오픈 소스 회사들은 아이디어와 코드의 자유로운 교환으로부터 이득을 얻는다는 사실을 알아야 한다. 표준적인 GPL 관행 같은 것에 반대함으로써, 그들이 번창하고 성장하기 위하여 의지해야 할 환경을 해친다. 오픈 소스가 여러분의 사업이 자라기 시작하는 토양이라면, 그 토양을 비옥하게 하는 것이 이치에 맞는다.
단기적인 재정적 소득을 위하여 적어도 어느 정보는 비밀을 유지하고 싶은 유혹이 있을 줄 안다. 고급의 코드 또는 특별한 기법들은 잠재적으로 증가된 판매와 이익을 가져올 수 있는 탐나는 경쟁우위를 제공한다. 그러나 목적이 제품을 독점으로 공급하는 것이라면, 그 제품은 오픈 소스이기보다는 상품이어야 한다. 오픈 소스는 어떤 것의 내부적인 작업에 배타적으로 접근하는 것을 허용하지 않는다. 오픈 소스의 의미이다.

다시 Enoch으로
Enoch가 점점 더 정교해짐에 따라서, 이름을 바꾸기로 결정했고 "Gentoo Linux"가 태어났다. 이때까지 우리는 두개의 Enoch(지금은 Gentoo) 버전을 릴리스 했고, Gentoo Linux 버전 1.0에 노력을 경주하고 있었다. 이 무렵 나는 또한 Celeron 300 박스를(아주 안정적으로 오버클러킹(overclocking)하여 450MHz로 쓰고 있는) 갓 태어난 Abit BP6로(인기를 끌고있는 Celeron 듀얼보드) 업그레이드 하기로 결정했다. 나는 구식의 박스를 팔고, 이중 Celeron 366 시스템을 만들었다. 프로세서를 500Mhz 등급으로 오버클러킹 한 후, 나는 순항하고 있었다. 그러나 새 머신은 매우 안정적이지 않다는 것을 알아차렸다.
나의 첫번째 반응은 2x366Mhz로 다시 내려가는 것이었다. 그러나 더 이상한 문제를 체험했다. 머신이 CPUs를 돌아가게 하는 데는 문제가 없었다. 그러나 머신을 밤새 사용하지않고 idle한 상태로 놔두면, 시스템이 완전히 먹통이 될 가능성이 높았다. 그렇다. idle 버그이다. 면밀히 조사한 후, 이 특이한 머더보드에 같은 문제를 가진 Linux 사용자 몇 사람을 찾았다. BP6의 한 칩이(PCI제어기였던가?) 색다른 것이거나 사양이 아닌 것 같았다. 이것이 Linux를 사용하지 않은 상태에서 먹통이 되도록 만드는 것이었다.
나는 심란했고, 부품을 주문할 여유가 없었기 때문에, Gentoo 개발은 사실상 멈추었다. 나는 Linux에 대하여 점점 더 비관적이 되었고, FreeBSD로 전환하기로 결심했다. 3편에 계속.

배포판 제작하기, Part 3
다시 Linux로

난이도 : 초급
Daniel Robbins, CEO (Gentoo Technologies, Inc.)
2001 년 1 월 01 일
이제 "배포판 제작하기"의 마지막편 이다. Gentoo Linux라는 나 자신의 배포 판 만들기를 어떻게 끝맺음 했는지, 어떻게 해서 Linux 세계를 떠나 FreeBSD로 갔다가 Linux 세계로 다시 돌아와, 새로운 전망을 가지고 Gentoo Linux 개발을 다시 시작하였는지를 설명하고 있다. Linux와 FreeBSD를 비교하고, 또한 현재의 Gentoo Linux 개발의 진척을 설명하고, 배포판에 대한 전망에 대해서도 다루었다.
배포판 제작하기,part 2에서, 이상한 idle-lockup 버그에 의하여 어떻게 Gentoo Linux 개발이 중지되었는지 말했다. 이 lockup은 내가 새로운 Celeron 이중 마더보드로 (Abit BP6) 업그레이드 하자마자 시작된 것이다. 나는 잘 작동하는 시스템이 필요했고 Linux는 항상 lockup되기 일쑤였으므로, BSD 운영체제에 익숙해질 절호의 기회였다. FreeBSD를 설치하여 배우기 시작했고, Linux는 몇 달 동안 손도 대지 않았다.

FreeBSD의 인상
정말로 FreeBSD를 좋아했다. 운영체제는 잘 만들어졌고, 시스템의 모든 부분이 조화하여 Linux 세계에서는 거의 볼 수 없는 높은 수준의 정교함을 보여주었다. 많은 프로그램들이 단지 GNU info 문서만을 보여주는 Linux와는 달리, FreeBSD에는 완전한 맨 페이지들이 들어 있었다.
무엇보다도, 시스템을 유지하고 업그레이드 하는 기술인FreeBSD의 포트 시스템이 인상적이었다. Linux의 접근법과는 달리, FreeBSD의 포트는 이진 패키지를 사용하지 않고 대신에 로컬 머신에서 본래의 소스로부터 모든 것을 자동적으로 컴파일했다. Samba를 설치하거나 코어 시스템을 업그레이드하고 있다면, 모든 것이 바로 여러분의 로컬 머신에서 컴파일된다. 이 방식은 마음에 들었고 Gentoo Linux에서 만들었던 방식과 비슷했다. 많은 부분에서 FreeBSD 설계 방식들은 개발자로서 그리고 시스템 관리자로서 나의 감성에 적합했다. 이러한 까닭으로 FreeBSD는 여러 달 동안 편안한 작업환경을 제공했고, 이렇게 뛰어난 운영체제에 익숙해질 수 있어서 기뻤다.

FreeBSD의 장점
Linux와 FreeBSD의 많은 차이점은 다른 개발구조에서 비롯된다. Linux 개발은 매우 분산되어 있어서, 배포 판에 의지하여 Internet 도처에 흩어져있는 Linux의 여러 부분들을 끌어들여 하나로 만든다. FreeBSD와 다른 BSDs(OpenBSD와 NetBSD)에는 하나의 통일된 소스모음을 꾸준히 연구하는 통합된 개발팀이 있다. 이것은 좋은 방법이라고 생각되며, FreeBSD가 많은 Linux 의 "짜깁기식" 느낌을 가지지 않게 한다.
다음으로 기반기술을 비교할 수 있다. FreeBSD를 좋아하는 사람들은 Linux보다 FreeBSD가 서버로 사용하기에 더 적합하다고 주장한다. FreeBSD는 높은 부하에서 더 수행을 잘하고, 더 나은 TCP/IP 스택을 가지고 있다고 그들은 말한다. Linux 2.2 또는 그 이전 버전을 FreeBSD와 비교하는 거라면 나 역시 동의할 것이다. FreeBSD가 훌륭한 서버 OS인 것은 사실이다. 그러나 그것은 Linux 2.2 또는 그 이전 버전에 대해서다. 나는 내가 사용하고 있는 Linux 2.4 테스트 커널에 푹 빠지게 되었다. 이 커널들은 정말로 훌륭하고, 꾀 좋은 TCP/IP 스택과 정말로 넋을 빼는 완전히 재설계된 "netfilter" 시스템을 포함하고 있다. 결론적으로, Linux는 새로운 성능 표준을 제시하고 자유로운 UNIX 서버가 보다 많은 상업적 경쟁력을 가지도록 할 것이다.

FreeBSD의 단점
데스크톱에 있어서는 사실상 비교가 되지 않는다. Linux가 수지가 맞는다. 최신의 모든 데스크톱 개발은 Linux에 먼저 나타나고, 가속된 3D 그래픽과 사운드 카드 지원에서 Linux는 앞서있다. 커널 2.4를 고려해봐도, Linux는 이 분야에서 우월성을 계속 유지할 것이다.
FreeBSD에서 마음에 들지 않는 점은 UFS 파일시스템을 사용한다는 것이다. UFS는 ext2보다 신뢰할 수 있고 튼튼하지만, 마음이 저리도록 느리다 soft updates라는 특별한 확장판을 사용할 수 있는데, 이것은 IO 조작을 더 큰 덩어리(chunk)로 한데 모아서 파일시스템의 속도를 높일 수 있다. soft updates가 UFS를 크게 개선시키지만, UFS가 사실상 ext2보다 성능이 앞선다고 말할 수는 없다. 물론 안정적인 것은 사실이므로, FreeBSD가 파일시스템에 있어서 Linux보다 낫다고 할 수 있다. 반복하지만 이 또한 Linux 2.2 이하 버전의 경우에 해당된다.
어쨌든, 최신의 Linux 2.2와 Linux 2.4를 FreeBSD에 비교하면 형세가 바뀐다. ReiserFS(새로운 Linux용 저널링 파일시스템)은 놀라울 따름이다. Linux는 또한 ext3, IBM의 JFS, 앞으로의 XFS를 가지고 있는데, 뛰어난 성능과 신뢰도가 기대된다. ReiserFS는 속도를 증가 시키고, Linux 2.4가 FreeBSD가 Linux보다 우월하다는 낡은 주장을 뒤엎는다고 믿는 이유 중의 하나이다.

다시 Gentoo Linux 개발로 돌아오다
몇 달 후, 나는 Linux 세계와 재결합하고 Gentoo Linux를 새로운 개발 박스에서 실행하기로 결심했다. 처음에, Gentoo Linux 개발을 재개하기로 한 결정은 사업적인 의사결정 이상이었다. Linux에 박식해지기 위하여 많은 시간을 투자했고, BSD에 집착하여 이 모든 지식들을 날려버리는 것은 낭비일 것이다. 어쨌든, Gentoo Linux 업데이트를 시작하고 나서 Linux의 새로운 몇 가지 가치들을 발견했는데, 위에서 언급한 모든 파일시스템과 커널의 향상된 점이다. FreeBSD는 아늑한 집이었지만 지루했고 너무 침착했다. Linux는 활기가 넘치고 중요한 진척이 이루어지는 곳이었다. 만약 여러분이 흥미와 혁신을 찾고있다면, Linux가 있는 곳이 바로 그 곳이라는 것에 의심의 여지가 없다.
Linux 2.2는 2.0 시대로부터 실망스러운 감퇴의 시대였지만 2.4 시대는 기다릴만한 가치가 있음을 약속했다. 그래서 Gentoo Linux는 다시 태어났고, 나는 들떠있었다.
Gentoo Linux의 재탄생에는 또 다른 열쇠가 있었는데, 바로 개발팀의 리더인 Achim Gottinger이었다. Gentoo Linux 개발을 다시 시작하는데 도움을 준 Achim에게 이 자리를 빌어서 감사의 뜻을 전하고 싶다. 나는 Linux 세계로 돌아오기 바로 전에 Achim으로부터 메일을 받기 시작했다. 거의 모든 메일에 그는 Gentoo Linux용의 새로운 .ebuild(autobuild) 스크립트 또는 몹시 필요한 버그픽스들을 보내주었다. 내가 Gentoo Linux 개발을 재개함에 따라, Achim은 배포 판이 다시 독립할 수 있도록 그의 시간과 리소스들을 계속 기여해주었다. 최근까지 Gentoo Linux의 작업을 Achim과 나 둘만이 해왔는데, 이것은 선택에 의한 것이었다. 우리 둘은 배포 판에 비슷한 비전을 가졌고, 그리고 Achim의 기술 때문에 엄청난 양의 작업을 할 수 있었고, 세 번째 개발자를 추가한다고 해서 작업이 크게 진척되지는 않을 것이었다. 현재 Achim은 Gentoo Linux 개발을 리드하고 있으며, 거의 매일 Gentoo Linux을 크게 개선시키고 있다. 우리는 다른 사람들이 우리의 CVS 트리에서 작업을 시작하도록 할 준비를 마쳤다. 그리고 점차적으로 조심스럽게 Gentoo Linux 개발팀을 확대하기 시작했다.

새로운 비전
나는 BSD세계에서 보낸 시간들이 어떤 식으로든 허비되었다고 느껴지지 않는다. 사실은 Linux 공동체 전체에서 일어나는 사건들과 Gentoo Linux가 여기에서 개선해 나아가야 할 방법을 돌이켜볼 수 있는 굉장한 기회였다.
Gentoo Linux의 새로운 버전에는 pgcc를 더 이상 사용하지 않고, 모든 바이너리(binaries)를 컴파일하기 위한 매우 높은 최적화 또한 적용하지 않기로 결정했다. 안정성이 최우선으로 고려되어야 하기 때문에, 적당한 ("-O2 -mpentium") 최적화를 사용하지만, 사용자들이 autobuild 시스템을 사용하여 최적화를 기호에 맞게 만들 수 있는 쉬운 방법을 제공할 것이다.
FreeBSD는 나에게 autobuild 시스템의 기능에 관한 정말로 좋은 아이디어를 제공했다. 나는 우리의 autobuild 시스템(지금은 Portage로 불리는)을 진정한 차세대 포트 시스템으로 만들기 위하여 FreeBSD의 몇 가지 특징을 더하기로 결정했다.
Portage는 Gentoo Linux의 중심부이고, 단순한 패키지 관리 또는 유지시스템 이상이다. 내장 툴과 내장 스크립트의 모음으로 구성되는 Portage는 배포 판 전체를 본래의 소스로부터 재구축할 수 있다. 그러나 나에게 더 중요한 것은, Portage는 사용자에게 Gentoo Linux가 구축된 방법에 관한 완전한 지식을 제공한다는 것이다. 우리에게 이것은 매우 중요한 의미를 갖는데, 왜냐하면 Gentoo Linux를 개발해 나가는 동시에 배포판 구축에 대하여 문서화를 진행할 수 있기 때문이다. 그리고, Portage는 사용하고 이해하기 쉽기 때문에, Linux의 내부를 보다 많은 사람들에게 열어서, 다른 사람들도 우리의 소스와 스크립트에 기여할 수 있었으면 좋겠다.
Portage는 Linux 기술을 공개하는 우리의 방식이다. autobuild 스크립트를 배움으로써, 모든 다양한 패키지들이 어떻게 서로 하나의 전체로 맞추어지는지 알 수 있다. 필요하다면, 여러분 자신의 배포 판 또는 Linux 기저의 기술을 만들어가면서, 우리의 CVS트리 전체를 움켜쥐고 잘해나갈 수 있다. ?

상업적 이해관계
시초부터, 다양한 배경을 가진 많은 사람들이 Gentoo Linux 개발에 참여해왔다. 그리고 나는 Gentoo Linux의 돈벌이를 위한 방법을 놓고 개발자들 간에 의견의 차이가 크다는 것을 알고 놀라지 않았다. 기본적으로 두 그룹의 개발자가 있다. 한 그룹은 대개 돈벌이 추구에 반대하고, 반면에 다른 그룹은 Gentoo Linux가 성공적인 상품이 되도록 하는데 흥분해있다. 이것은 예상한 갈림이었다. 첫번째 그룹은 상업적 연루를 오염시키는 영향으로 보는 반면, 두 번째 그룹은 부정적인 관련이 없는 것으로 보았다.
Enoch 시절에 나는 이 쟁점에서 흔들리곤 했는데 올바른 방향을 정말 몰랐다. Debian 같은 배포 판은 그들의 소프트웨어의 자유로운 배포에 정말 전념했다는 사실을 인정했다. 나는 Debian을 사랑했다. 다른 상업적인 배포 판과 비교하여, 그들은 웹사이트에 상세한 지식들을 제공함으로써 사용자들을 편하게 해주었다. 그것은 참 훌륭한 일이며, 내가 흉내내보고 싶은 것이었다.
동시에 Gentoo Linux가 상업적으로도 성공하기를 간절히 원했다. 균형 점을 찾으려고 노력했지만, 최근까지도 전혀 찾지 못하였다.

절충방안
상업적인 이익과 비상업적인 이해관계를 어떻게 절충할 수 있을까? 방법은 우리의 기반을 상기하는 것이다. Gentoo Linux의 기반은 오픈 소스 소프트웨어이다. 그래서 우리의 모든 노력의 밑바탕은 오픈 소스에 초점을 맞추어야 한다. 오픈 소스 소프트웨어를 인정하기만 하거나 또는 그것을 사용하는 것만으로는 충분하지 않다. 또한 오픈 소스의 개발과 배포를 격려해야 하고, 상업적 이득을 위하여 이 입장에 반대해서는 안 된다. 보다 중요하게, 소스의 자유로운 배포를 제한하려는 유혹이 도사리는 그러한 사업 모델을 구축해서는 안 된다. 개발팀은 대중에게 공개되고 그들이 접근할 수 있어야 하고, Gentoo Linux의 자유로운 배포는 허용될 뿐만 아니라 격려되어야 한다. 우리는 말 뿐만이 아닌 행동으로도 오픈 소스의 옹호자가 되어야 한다.
어떤 회사가 상업적인 Linux 기반 기술을 위하여 Gentoo Linux를 사용하고 싶다면, 우리의 모든 제작물은 GPL 하에서 배포되기 때문에, 그들은 우리의 CVS 트리의 컨텐츠를 손에 넣어 사용할 수 있다. 모든 이차적인 제품들은 GNU Public Lisence 에 따라야 한다는 것을 제외하고, 우리의 제작물을 사용하는데 어떠한 제한도 두고 싶지 않다.
여러분이 Gentoo Linux를 제품의 기초로 사용하는 회사의 일원이라면, 자유로이 배포될 수 있는 어떠한 개선사항이라도 우리에게 보내어, 우리가 그것을 CVS 트리에 추가할 수 있기를 희망한다. 그러한 방식은 모든 사람에게 이익이 된다. 여러분이 추가한 것을 우리는 계속 관리하고 개선할 수 있으며, 교대로 여러분은 이러한 개선점들을 이용할 수 있다. 우리는 상업적인 것과 비상업적인 것 사이의 협력을 촉진하고 싶다. 이 방식으로 ISP(Internet service provider)에Gentoo Linux를 사용하는 시스템 관리자와 상업적인 서버 제품을 구축하는 기업 모두는 서로의Gentoo Linux 개선점과 픽스에서 이익을 얻을 수 있다. 모든 사람들 사이에서 코드의 자유로운 교환을 촉진할 때인 것이다. 오픈 소스만이 이것을 가능케 할 수 있다.

앞으로의 전망
우리는 Gentoo Linux 1.0을 배포하려고 한다.(여러분이 developerWorks에서 이 글을 읽을 때는 사용 가능할 것이다.) 하지만 앞으로는 어떻게 될까?
우리가 2.0으로 향함에 따라, Gentoo Linux의 핵심 기술인 Portage가 계속 개선되기를 바란다. Gentoo Linux의 중요한 개선은 대개 Portage에서 시작된다. 나는 코드의 대부분을 bash에서 python으로 변환하는 과정을 계속하고 싶다. 이렇게 하여 우리의 autobuild 시스템에 객체지향적 설계와 같은 새로운 특징을 추가할 수 있을 것이다.
Portage의 변화에 더하여, 우리와 비전을 함께하는 숙련된 개발자들을 찾아내어 우리의 개발팀을 서서히 조심스럽게 키우고 싶다. 개발팀이 커감에 따라, Gentoo Linux 용의 autobuild 스크립트의 수를 크게 증대할 수 있을 것이다. 그러나 이보다 더욱 중요한 것은, 조금 더 큰 개발팀은 Linux 기술을 계속 발전시키는데 필요한 리소스를 제공할 것이다. 거기에 즐거움이 있다.
상업적인 Linux 기술 회사들이 그들 제품의 기초로서 Gentoo Linux를 선택하기를 또한 기대한다. 현재 한 회사와 이러한 관계를 맺고 있으며 앞으로 더 많아지기를 기대한다. 이러한 협력은 많은 즐거움과 모든Gentoo Linux 사용자에게 큰 이익을 약속한다.
결국, 우리의 일차적인 목표는 Linux 공동체에 의미 있는 어떤 것을 기여하는 것이다. 비록 선택할 Linux 배포 판들이 많이 있을지라도, Gentoo Linux는 다른 곳에서는 실제로 사용 가능하지 않은 것도 제공한다. 우리는Gentoo Linux 개발의 미래에 대해 기대에 차 있으며, 여러분도 또한 그러리라고 믿고 싶다.

필자소개

Daniel Robbins는 Gentoo Technologies, Inc.의 회장/CEO이고, Gentoo Project의 핵심 설계자이며, Caldera OpenLinux Unleashed, SuSE Linux Unleashed, Samba Unleashed의 저자이다.


2006. 9. 16. 12:42

Making the distribution, Part 3

The author strays from Linux and then returns

Level: Introductory

Daniel Robbins (drobbins@gentoo.org), President/CEO, Gentoo Technologies, Inc.

01 Jan 2001

This article concludes my story -- about how I ended up creating my own distribution called Gentoo Linux. I wrap up the series by telling how I left the Linux world to move to FreeBSD, and then came back to the Linux world, restarting Gentoo Linux development with a fresh perspective. In addition to comparing Linux and FreeBSD in a number of areas, I also describe current Gentoo Linux development progress and share a future vision for our distribution.


At the end of my previous article, I described how Gentoo Linux development had effectively been brought to a halt by a strange idle-lockup bug that I began experiencing as soon as I upgraded to a new dual-Celeron motherboard (an Abit BP6). Because I was unable to fix the problem, and at the time didn't have the funds to replace my motherboard, I decided to halt Gentoo Linux development and switch over to FreeBSD. I needed a working system, and since Linux was locking up all the time, this would be an excellent time to get familiar with a BSD operating system. So I installed FreeBSD, started learning, and didn't touch Linux at all for several months.


FreeBSD impressions

All in all, I really liked FreeBSD. I felt that the operating system was well put together and that nearly every part of the system had a consistently high-level of refinement that's almost never found in the Linux world. I enjoyed the fact that FreeBSD contained a full complement of man pages, unlike Linux where many programs only have GNU info documentation, which I don't particularly like using.

Most of all, I was impressed with FreeBSD's ports system, the technology used to maintain and upgrade the system. Unlike the Linux approach, ports didn't use binary packages but instead automatically compiled everything locally from their original sources. Whether you were installing Samba or upgrading the core system, everything was compiled right on your local machine. This approach appealed to me and was very similar to the one I had been creating under Gentoo Linux. In this and many other ways, FreeBSD's design agreed with my sensibilities as a developer and a system administrator. For this reason, FreeBSD provided a comfortable work environment for many months, and I'm glad I took the time to get familiar with this excellent operating system.


FreeBSD pros

A lot of the differences between Linux and FreeBSD come from their different development structures. Linux development is very decentralized, and we rely on distributions to pull in and unite the various pieces of Linux scattered throughout the Internet. Compare this to FreeBSD and the other BSDs (OpenBSD and NetBSD), where there's a unified development team plugging away at a single, unified set of sources. Well, at least each BSD has its own set of unified sources. This can be a good thing, and results in FreeBSD not having a "patched together" feel like many Linux distributions do.

Next, we can compare the technology under the hood. Many a FreeBSD fan will assert that FreeBSD is better suited to being a server than Linux is. They'll tell you that FreeBSD is better under high loads, and has a better TCP/IP stack. If you're comparing Linux 2.2 or earlier with FreeBSD, I'd have to agree. FreeBSD is a great server OS, that's for sure. But, that's just Linux 2.2 and earlier. I happen to be a big fan of the 2.4 test kernels that I've been running. They're really, really great and contain a nice TCP/IP stack and a totally redesigned "netfilter" system that really rocks. In the end, I think that Linux will be the one to set new performance standards and make free UNIX servers even more competitive versus their commercial counterparts.


FreeBSD cons

As for the desktop, rather than the server world, there's really no comparison -- Linux is where the action is. All the latest desktop developments appear on Linux first, and Linux is ahead in its support of accelerated 3D graphics and sound cards. With Linux 2.4 approaching, Linux will continue its dominance in this area.

The one thing I don't like about FreeBSD is its use of the UFS filesystem. While UFS is more reliable and rugged than ext2, it's also mind-numbingly slow. It's possible to use a special UFS extension called soft updates, which is able to speed up the filesystem by aggregating IO operations into bigger chunks. While soft updates improves UFS tremendously, I can't say that UFS really outperforms ext2 in any way. Of course, it's more reliable, so FreeBSD ends up beating Linux in the filesystem war. Again, at least this is true when comparing older Linux 2.2 distributions to FreeBSD.

However, the tables turn when we start to compare modern Linux 2.2 and Linux 2.4 to FreeBSD. ReiserFS (a new journalling filesystem available for Linux) is just amazing. Linux also has ext3, IBM's JFS, and XFS to look forward to, from which we expect excellent performance and reliability as well. As of now, ReiserFS gives Linux a major speed advantage over FreeBSD, and is one of the reasons I believe that Linux 2.4 overturns many of the old arguments of FreeBSD's superiority over Linux.


Back to Gentoo Linux development

After a few months, I decided to rejoin the Linux world and get Gentoo Linux running on a new development box. At first, the decision to restart Gentoo Linux development was more of a business decision -- I had invested a lot of my time in becoming Linux-knowledgeable, and it would be a waste to throw all this knowledge away by sticking with BSD. However, shortly after I began updating Gentoo Linux, I found several new reasons why Linux was worth switching back to, namely all the filesystem and kernel improvements mentioned above. FreeBSD was a peaceful home, but a little too boring, too staid. Linux is where the action was, where major progress was being made. There's no doubt that if you're looking for excitement and innovation, Linux is the place to be.

To me, the Linux 2.2 era was a disappointing letdown from the 2.0 era, but the 2.4 era promised to be worth the wait. So, Gentoo Linux was reborn, and I was excited.

There was another key to Gentoo Linux's rebirth -- Achim Gottinger, my development team lead. I want to take some space to thank Achim for helping me restart Gentoo Linux development. I started getting e-mails from Achim shortly before my return to the Linux world. In almost every e-mail, he'd include some new .ebuild (autobuild) scripts for Gentoo Linux, or some desperately needed bugfixes. As I restarted Gentoo Linux development, Achim continued to contribute his time and resources to help get the distribution back on its feet. Up until recently, Achim and I have been the only two people working on Gentoo Linux, and this has been by choice. Because we both have a similar vision for the distribution, and because of Achim's skill, we were able to get a tremendous amount of work done and I never really felt that adding a third developer would significantly help our progress. Now, Achim serves as the Gentoo Linux development lead, and continues to make major improvements to Gentoo Linux on an almost daily basis. We've reached the point where we're ready for others to start working on our CVS tree, and have begun to gradually and carefully expand the Gentoo Linux development team.


The new vision

I don't feel that the time I spent in the BSD world was in any way wasted. In fact, it gave me a tremendous opportunity to reflect on the happenings in the entire Linux community and how Gentoo Linux could help to improve things.

In the new version of Gentoo Linux, I made the decision to not use pgcc anymore, nor use very high optimizations to compile all binaries. Since stability was paramount, we would use reasonable ("-O2 -mpentium") optimizations but provide an easy way for users to customize these optimizations to their liking by using our autobuild system.

FreeBSD gave me a really good idea of how an autobuild system should function. I decided to add several FreeBSD features to make our autobuild system (now called Portage) a true next-generation ports system.

Portage is the heart of Gentoo Linux, and is more than a simple package management or maintenance system. Consisting of a set of build tools and build scripts, Portage allows you to rebuild the entire distribution from original sources. But more importantly to me, Portage gives the user full access to the intelligence of how Gentoo Linux was built. To us, this is very important because it means that we are documenting how to build a distribution while at the same time moving Gentoo Linux development forward. And, because Portage is easy to use and understand, we hope that it will open up Linux internals to even more people, so that others can begin to contribute to our sources and scripts.

Portage is our way of opening up Linux technology to others. By studying the autobuild scripts, you can see how all the various packages fit together into a unified whole. If necessary, you can grab our entire CVS tree and hack away at it, producing your own custom distribution or Linux-based technology. We believe that this is a good thing -- we want to give people the knowledge they need to take Linux into new realms.


Commercial concerns

Since its inception, there have been many people of various backgrounds involved with Gentoo Linux development. And I wasn't surprised to find that our developers had wildly different opinions of how we should approach the money-making end of Gentoo Linux. Basically, there were two groups of developers: one group was generally opposed to money-making pursuits, while the other group was excited about helping Gentoo Linux become a successful commercial product. This was an expected split; the first group saw commercial involvement as a corrupting influence, while the second saw no such negative associations.

In the Enoch days, I used to waver on this issue and didn't really know the right approach. I recognized the fact that distributions like Debian were truly committed to free distribution of their software. I liked that. Compared to other commercial distributions, they made things easy for the user by providing detailed instructions on their Web site. That was a good thing, and something I wanted to emulate.

At the same time, I really wanted Gentoo Linux to be commercially successful. I struggled to find a balance, but never really found one until recently.


What to do?

So, how are we planning to balance commercial and non-commercial interests? The key is to remember our foundation -- the foundation of Gentoo Linux is Open Source software. Thus, the foundation for all our endeavors must focus on Open Source. It's not good enough to just acknowledge Open Source software, or just to use it. We must also encourage its development and distribution, and never oppose this stance for commercial gain. More importantly, we must never structure our business model so that there's a temptation to restrict the free distribution of our sources. Our development team needs to be open and accessible to the public, and free distribution of Gentoo Linux must not only be allowed, but encouraged. We need to be Open Source advocates, not just in word, but in action also.

If a company wants to use Gentoo Linux for a commercial Linux-based technology, they can just grab the contents of our CVS tree and start using it, since all our work is distributed under the GPL. We don't want to limit the use of our work in any way, except to ensure that all derivative products comply with the GNU Public License.

We'd like as many people as possible to benefit from our work, but we'd also like to benefit as much as possible from your improvements to Gentoo Linux. If you're part of a company using Gentoo Linux as a base for your product, we hope that you'll send any freely-distributable improvements to us so that we can add them to our CVS tree. That way, everyone benefits. We can continue to maintain and improve your additions, and you in turn can benefit from these improvements. We want to foster collaboration between commercial and non-commercial entities. This way, both the sysadmin using Gentoo Linux at his ISP and the corporation building a commercial server product can benefit from each other's improvements and fixes to Gentoo Linux. It's time to promote the free exchange of code between everyone. Only Open Source makes it possible.


What does the future hold?

Right now, we're at the verge of releasing Gentoo Linux 1.0 (it may be available by the time you read this article on developerWorks.) But what does the future hold?

As we move towards 2.0, I hope to continue to improve Portage, the technology at the heart of Gentoo Linux. Any major improvement to Gentoo Linux generally starts with an improvement to Portage. I'd like to continue the process of converting the majority of the code from bash to python, which will allow us to add new features like object-oriented design to our autobuild system.

In addition to changes to Portage, I hope to continue to slowly and carefully grow our development team by finding skilled developers who share our same vision. As our development team grows, we will be able to vastly expand the number of autobuild scripts available for Gentoo Linux. But even more important than this, a slightly larger development team will give us the resources we need to continue to keep Gentoo Linux on the cutting edge of Linux technology. That's where the fun is :)

We also hope that commercial Linux technology companies will choose Gentoo Linux as a base for their products. We currently have one such relationship and we hope to have many more in the future. These kinds of collaborations promise to be lots of fun and to be a great benefit to all Gentoo Linux users.

In the end, our primary goal is to contribute something meaningful to the Linux community. Although there are many Linux distributions to choose from, we know that Gentoo Linux offers something that really isn't available anywhere else. We're excited about the future of Gentoo Linux development, and we hope you are too.


About the author

Daniel Robbins lives in Albuquerque, New Mexico. He is the President/CEO of Gentoo Technologies Inc., the Chief Architect of the Gentoo Project and a contributing author of several books published by MacMillan: Caldera OpenLinux Unleashed, SuSE Linux Unleashed, and Samba Unleashed. Daniel has been involved with computers in some fashion since the second grade when he was first exposed to the Logo programming language and a potentially lethal dose of Pac Man. This probably explains why he has since served as a Lead Graphic Artist at SONY Electronic Publishing/Psygnosis. Daniel enjoys spending time with his wife Mary and his new baby daughter, Hadassah. You can contact Daniel at drobbins@gentoo.org.

2006. 9. 16. 12:13

Making the distribution, Part 2

From Enoch to Gentoo, via minor setbacks and corporate run-ins

Level: Introductory

Daniel Robbins (drobbins@gentoo.org), President/CEO, Gentoo Technologies, Inc.

01 Dec 2000

In his previous article, Daniel Robbins told the story of how he became a Stampede Linux developer and why he eventually left Stampede to start the Enoch Linux distribution. In this go-round he lets you in on the strange events that happened after the Enoch development team discovered a little-known, blazingly fast compiler.

First steps to Enoch

In my previous article, I gave you the low-down on my days with the Stampede development team and why I left (to get away from lower-level politically-minded, project-controlling "freaks"). Because of the interference from these meddlesome by-standers, I figured it would be easier to put together my own Linux distribution than to continue improving Stampede under such dirty conditions! Fortunately I took with me a considerable amount of experience based on my (may I say substantial?) work for Stampede, including maintaining several of their packages, designing the initialization scripts, and leading the slpv6 (next-generation package management project).

The distribution I began working on, code-named Enoch, was going to be blazingly fast because it would completely automate the package creation and upgrading process. I have to admit that this was in large part because I was a one-member team and couldn't afford to spend my time on repetitive work that my development box could be automated to do for me. And since I was designing a complete distribution from scratch (rather than "spinning off" from someone like RedHat), I had my work cut out for me and needed all the free time I could scrounge up.

After getting my basic Enoch system up and running, I headed back to irc.openprojects.net and started my own channel called #enoch. From there I gradually assembled a team of about ten developers. In those early days we all hung out on IRC and worked on the distribution in our spare time. As we communally and cooperatively hacked away at it, finding and fixing new bugs, Enoch became more functional and professional every day.

The first roadblock

One inevitable day, Enoch hit its first roadblock. After adding Xfree86, glib, and gtk+, I decided to get xmms (an X11/gtk+-based MP3/CD player app) working. I figured it was time to celebrate with some music! But after installing xmms, I tried to start it... and X locked up! At first I thought xmms locked up because I used insane compiler optimizations ("-O6 -mpentiumpro", in case you were wondering). My first thought, to compile xmms with standard optimizations, didn't solve the problem. So I started looking elsewhere. After spending a full week of development time trying to track down the problem, I got an e-mail from an Enoch user, Omegadan, who was also experiencing xmms lockups.

We corresponded for a while, and after many hours of testing we determined that the problem was a POSIX threads-related issue. For some reason, a pthread_mutex_trylock() call did not return the way it should. As the creator of a distribution, these were the types of bugs I really didn't want to encounter. I counted on the developers to release perfect sources so I could focus on enhancing the Linux experience rather than getting buggy sources to work. Of course I soon learned that this was an unrealistic expectation, and that problems like will always pop up from time to time.

As it turned out, the problem wasn't with xmms, gtk+, or glib. And it wasn't an issue with Xfree86 3.3.5 not being thread-safe and locking up. Surprisingly, we found the bug in the Linux POSIX threads implementation itself, part of the GNU C library (glibc) version 2.1.2. I was shocked at the time to find that such a critical part of Linux had such a major bug. (And we used a release version of glibc in Enoch, not a prerelease or CVS version!).

So how did we track down the problem? Actually, we never were able to come up with a bug fix, but at one point I stumbled across a couple of e-mails on the glibc developer mailing list from another person who had the same problem. The glibc developer who replied posted a patch that solved the thread problem for us. But I was curious why RedHat 6 (which also used glibc 2.1.2) didn't suffer from this problem since the patch was just posted and RedHat 6 had been available for some time. To find out, I downloaded RedHat's glibc SRPM (source RPM) and took a look at their patches.

RedHat had their own homegrown glibc patch that solved the pthread_mutex_trylock() issue. Apparently they experienced the same problem and created their own custom fix. Too bad they didn't send this patch "upstream" to the glibc developers so it could be shared with the rest of the world. But who knows, maybe RedHat sent the patch upstream and for some reason the glibc developers didn't accept it. Or maybe the thread bug was triggered by a specific combination of compiler and binutils versions, and RedHat never ran into it (although they did have a thread patch in their SRPM). I suppose we'll never know exactly what happened. But I did learn that RedHat SRPMs contain a lot of private bug fixes and tweaks that never seem to make it upstream to the original developers. I'm going to rant about this for a little while.

Rant

When you put together a Linux distribution it's really important that any bug fixes you create are sent upstream to the original developers. As I see it, this is one of the many ways that distribution creators contribute to Linux. We're the guys who actually get all these different programs working as a unified whole. We should send our fixes upstream as we unify so that other users and distributions can benefit from our discoveries. If you decide to keep bug fixes to yourself, you're not helping anyone; you're just ensuring that a lot of people will waste time fixing the same problem over and over again. This kind of policy goes against the whole open source ethic and stunts the growth of Linux development. Maybe I should say that it "bugs" us all.

It's unfortunate that some distributions (ahem) aren't as good (RedHat) as others (Debian) about sharing their work with the community.

Compiler drama

During the time we were trying to fix the glibc threads problem, I e-mailed Ulrich Drepper (one of the guys at Cygnus who is heavily involved with glibc development). I mentioned the POSIX thread problem we were having, and that Enoch was using pgcc for optimum performance. And he responded with something like this (I'm paraphrasing here): "Our own compiler included with the CodeFusion product has an excellent x86 backend that produces executables far faster than those generated with pgcc." Obviously, I was very interested in testing out this mystery "turbo" compiler the Cygnus guys had created.

I thereupon requested a demo copy of Cygnus Codefusion 1.0 so that I could test it out, and Omegadan and I were amazed to find that this compiler was everything that Ulrich claimed and then some. The x86 backend increased the performance of some of the CPU-intensive executables (like bzip2) by close to 90%! All applications seemed to benefit from at least a 10% real-world performance increase, and all we did was swap out compilers. Enoch even booted 30 - 40% faster. The performance gains were far, far greater than what we gained by switching from gcc to pgcc. Obviously, after experiencing it for ourselves, we wanted to use this compiler for Enoch. Fortunately, the sources were included on the CodeFusion CD and were released under the GPL, so we were fully permitted to use this compiler... or so we thought.

Let the freakiness begin

I sent an e-mail to the marketing manager at Cygnus to let them know our intentions, expecting a "yeah, go for it, thanks for using our compiler" response. Instead the reply was that although we were (technically) allowed to use the Cygnus compiler, we were strongly urged not to use or include the compiler sources with Enoch. I responded by asking why they had released the source under the GPL, if that was the case. It's my guess that if they had a choice, they wouldn't have used the GPL, but because they derived their compiler from egcs (released under the GPL), they had no choice.

This is a good example of a situation where the GPL prevented a company from creating a proprietary product based on open sources. My educated guess is that Cygnus was afraid that if we used their compiler we would undermine their boxed product sales, which would be especially strange because none of their marketing materials (nor the InfoWorld review) mentioned the new compiler included with CodeFusion. CodeFusion was marketed solely as a "development IDE" product, not as a compiler.

In an attempt to put some of their paranoia to rest, I offered to endorse CodeFusion and place the endorsement on our Web site with a link to help spur CodeFusion sales. Personally I didn't think that a "turbo" Enoch would negatively affect their sales, since CodeFusion was marketed as an IDE. But I tried nevertheless to make them happy. The IDE component of CodeFusion was a commercial product, and we had no desire or intention (or right) to distribute it with Enoch.

I e-mailed my (generous?) offer to Cygnus and received another strange response. They wanted authority over all of our "marketing materials" (apparently, this also included the content of our Web site!) Another shocker. The Cygnus marketing team seemed to have no grasp of how the Linux community or the GPL worked, so I decided to cut off communication with Cygnus for the indefinite future. In the mean time, we created a private "turbo" and public "non-turbo" version of Enoch, leaving the final decision for later.

But after several months they integrated the CodeFusion x86 backend into gcc 2.95.2. Now everyone could benefit from the nice new backend, not just the people who knew about the "secret GPL compiler" included on the CodeFusion CD. But we decided to go ahead and use gcc rather than the CodeFusion compiler. In addition to being more stable, gcc 2.95.2 also allowed us avoid Cygnus, which by this time had been purchased by RedHat for a ridiculous sum of money. (Note: the new x86 backend in gcc 2.95.2 is what gave newer Linux distributions the significant speed boost that we all got to experience. It also gave FreeBSD 4.0 a nice speed boost over 3.3.6. Notice the difference?)

On the soapbox

Thanks to this and other experiences, I've learned a lot about for-profit open source companies. There's absolutely nothing bad about being a for-profit open source company. Nor is there anything morally wrong with producing proprietary closed-source software, if that's what you'd like to do. But it doesn't make any sense for open source companies to subvert or refuse to cooperate with the rest of the open source world, either by not supporting the GPL or by any other means. This is a practical point that clearly makes business sense.

Open source companies should realize that the free exchange of ideas and code is what they profit from. By opposing things like the standard GPL practices, they undermine the environment they rely upon to prosper and grow. If open source is the soil from which your business has sprouted, it makes sense to keep the soil healthy.

I understand that there's a temptation to keep at least some information secret for short-term financial gain. Advanced code or special techniques provide a coveted competitive advantage, which could potentially result in increased sales and profit. But if the goal is to be the sole provider of a product, the product should be commercial rather than open source. Open source does not allow for exclusive access to the inner workings of anything. That's what it means.

Back to Enoch

Now, I'll step down from my soapbox and continue my story.

As Enoch became more and more refined, we decided that a name change was in order, and "Gentoo Linux" was born. By this time we had released a couple of versions of Enoch (now Gentoo), and were racing to get to Gentoo Linux version 1.0. Around this time I also decided to upgrade my old Celeron 300 box (overclocked and rock-solid at 450Mhz) to a brand-new Abit BP6 (a dual Celeron board that had just hit the market). I sold my old box and put my dual Celeron 366 system together. After overclocking the processors to something on the order of 500Mhz, I was cruising. But I noticed that my new machine wasn't very stable.

Obviously my first reaction was to go back down to 2x366Mhz. But now I experienced an even stranger problem. As long as my machine kept the CPUs chugging away, the machine didn't lock up. But if I left the machine idle overnight, there was a good probability that the system would lock up completely. Yes, an idle bug -- argh! After some research, I found several other Linux users with the same problem on this particular motherboard. A chip on the BP6 (was it the PCI controller?) seemed to be flaky or out of spec, which caused Linux to lock up at idle.

I was more than a wee bit upset, and because I couldn't afford to order more PC parts, Gentoo development effectively halted. I became more and more pessimistic about Linux and decided to switch over to FreeBSD. Yes, FreeBSD. And that's where I'll end this installment -- see you in Part 3. :)

2006. 9. 16. 12:09

Making the distribution, Part 1

Birth of the Gentoo Linux distribution

Level: Introductory

Daniel Robbins (drobbins@gentoo.org), President/CEO, Gentoo Technologies, Inc.

01 Nov 2000

Each of us has a story to tell about our experiences with Linux. This is Daniel Robbins' Linux story. In this first of three articles, he talks about how he became a Stampede Linux developer, and why he eventually left Stampede to start his own distribution called Enoch.

Linux and me

For every Linux geek there's a time when Linux becomes more than just a name and reveals itself as something more wonderful, powerful, and intriguing than anything a developer has ever encountered. My revelation came while I was working at the University of New Mexico as a sysadmin. Our NT server was running pretty well and I had some extra time on my hands. So I got Debian set up on a Pentium 166 server box and started learning ... and learning and learning and learning. And then I was hooked.

First I learned the basic ins and outs of Linux: how to get around, perform backups, get Samba running, etc. Then I set up qmail and Apache and learned python and shell programming. I built a departmental Intranet. I got Linux installed at home and began trying different distributions. Finally I settled with Stampede Linux. You know how the progression goes: first you struggle with grasping Linux basics; then, when you have a decent grip, you customize your Linux, learning as you go. Because Linux has nothing to hide, you can explore the technology and tools that make it tick while you grow in Linux fluency.

Linux is about potential

Linux offered something I had never seen before. If I had to put that magical something into words, I'd call it potential: the potential to change, to improve, to fix things, and yes, even to break things. As I upgraded to new kernel versions I saw Linux improve before my eyes and transform itself almost daily. And I was along for the ride! I was a part of the transformation. It was fun.

If you're anything like me, before you were exposed to Linux and open source you looked to those big companies in Redmond and Cupertino to provide a next-generation operating system that finally worked exactly the way you wanted it to. But alas, that dream never became reality. And while we were waiting, Linux came along. And although it had a lot of rough edges, it provided something for us hacker guys and gals that we could improve upon while we waited for the next big thing. Then one day we awoke to find that Linux had become the next big thing. And smiling all the while, we continued to hack away.

Linux is about people

The next thing I learned was that Linux is about people. Isn't that refreshing? Linux isn't just a bunch of source code. It's a community. We rely on this community to get our questions answered, and we become part of the community when we start helping others by contributing our time and expertise.

IRC (Internet relay chat) is a great place to meet people and waste a tremendous amount of time. The #stampede channel on irc.openprojects.net became my official hangout. That's where I'd ask my Linux questions. It's also where I first began to help other people out. #stampede desperately needed experienced Linux users to help out newbies who had just gotten the distribution installed. As is common on IRC, many of the experienced Stampede people had lost their zeal for answering (yet another) newbie question. But I was so excited that I actually knew the answer to newbies' questions, that I couldn't resist helping out! And that's how my involvement with Stampede began. I was just another guy who liked to answer questions. Of course, it wasn't entirely altruistic, because I also helped myself to expert Linux knowledge that the more experienced people on the channel (not to mention the Stampede developers themselves!) had to offer.

Getting involved

When people ask me how to get involved in an open source project, I tell them to find a place where they can be helpful, even if it's just by helping with basic Linux questions. A sincere desire to help others is a great ticket into the Linux community because this sentiment is at the heart of all open source development (including Linux). At least, it should be.

Along the way you'll inevitably run into people who know more than you. And you'll learn from them just as newbies continue to learn from you. It's also likely that as you gain more experience you'll come across opportunities to help in new ways. Maybe some of the project developers you come across will suggest something, or they'll ask for help themselves. They may even invite you to become part of the development team. If you're focused on helping others, they'd be foolish to pass you by. If you're helping a lot of people out, you will definitely be noticed in the community. That's sort of how it happened with Stampede and me.

Gradually I became more and more involved in Stampede development. Before long, I was an official Stampede developer. With the blessing of skibum (Matt Wood, Stampede's head honcho), I began working on a new version of Stampede's primitive .slp packaging format. At the time the .slp package format consisted of a .tar.bz2 archive with a fixed-length footer stuck on the end that contained information about the package author, a description of the contents, the package creator, etc. This approach had two major problems: the fields were a fixed length and the footer really wasn't that big, and there was no extensibility built into the format (there was no way to add any additional fields to the .slp format in the future). Obviously this thing needed a major overhaul.

Working with the senior Stampede developers, I wrote up a proposal of how to deal with the problem. Then I started coding the prototype tools in Python. The new format (codenamed slpv6) was somewhat similar to the IFF file format from the Amiga world. This next-generation .slp format allowed for 2 32 fields, 2 32 categories of fields, and a maximum field data length of 2 32 bytes. Not only was the format very extensible, it was also more compact than plain-text and easy to parse. Both text and binary data could be stored in the format, which allowed for a lot of possibilities for the future. The idea was to stick this next-generation dynamic header on the end of the archive file, thereby producing a next-generation .slp format that would serve Stampede users for years to come and at the same time maintain compatibility with standard UNIX archive formats.

People can get ugly

slpv6 development was going well and all the senior developers were happy with my progress. But unfortunately, two lower-level Stampede developers wanted to control the slpv6 project. They didn't like the direction I was taking, and they spent most of their time insulting the new slpv6 system. Though I spent hours in heated development discussions defending the proposal against their attacks, we weren't able to resolve anything. Eventually it became clear that they were just naturally argumentative and wouldn't be happy until they had their way. Fortunately for me, my project had the approval of the senior Stampede developers. But these discussions began to wear on me and made Stampede development very unpleasant. Ugh!

I couldn't avoid these guys since I had to hang out on #stampede to chat with higher-level developers. And every time I was on the channel they became combative, trying to undermine my work. They'd use devious techniques like calling for development meetings (really just an opportunity to insult my work in front of the senior developers). They'd also try to call for votes, attempting to seize control of Stampede. Of course they'd only call for a vote when they thought they had convinced enough people to agree with them. Throughout all of this I continued my slpv6 development. Needless to say, the senior development loved my work and wanted me to continue (without their support I wouldn't have been able to stick it out).

Understanding the freak

These two guys belong to a category of developer I like to call "the freak". But although they made my development work very unpleasant, I also learned a lot from having to deal with them. At this point I'd like to offer you an expos?f the freak developers, a sort of comprehensive overview: the qualities that make a freak, the freak's modus operandi, and how you, the development project leader, can confront and possibly reform the freak without exerting a lot of effort.

In order to avoid emotional damage, you'll need one prerequisite: a backbone. If you're unable to confront the freak in a respectful but firm manner, there's no hope. The freak's goal is to control as much of your project as possible so that he or she will feel powerful. The freak will use several techniques to make this happen. First they'll start unfairly criticizing or bitterly complaining about a project and/or the developers working on a project. Then they will refrain from offering any constructive solutions. They will also not be willing to help with the project in any other way unless they are promoted to the role of project manager. Their goal is to convince you to give them as much authority as possible so that they can solve problems that only they, with their finely trained freak eyes, can see.

If the criticism and complaining aren't effective, they'll request a developer meeting. This will be their opportunity to try and divide your development team into two factions. When they think that they've gotten enough people on their side, they'll request a vote (knowing they will win). If they don't win the vote or they are overruled, they'll push for another developer meeting next week in which they'll again try to divide your development team. They'll repeat this process endlessly.

If the developer meeting approach doesn't work, freaks will become reformers. By adopting this role they will try to streamline (read: undermine) the oppressive and unfair executive decision-making process by attempting to replace it with something more democratic (read: easily manipulated.) This will often involve convincing you that you should do whatever the majority of your developers want. Freaks love this because then you can't override those developer meeting votes anymore (muhahaha!). If you allow this to happen, you've basically given the freak the keys to your Lexus. You're powerless.

In another approach, freaks will irritate and drive away your productive developers. Then they'll work your entire team into a frenzy as they forcefully try to reform the project's power structure. If their efforts are finally defeated, they'll try to rally as many defectors together as possible and fork from your project. Ouch!

Managing the freak

You can identify these guys pretty easily. They're the ones who aren't writing any code (nor do they have any intention to). Instead they spend their time talking about more important things. You know, those managerial issues. If you're a project leader, it's pretty easy to deal with them. Just tell them that you won't consider any proposal unless they produce working code. Or insist that they constructively help the current project, which includes obeying the current project manager, before giving them the opportunity to offer any (constructive) criticism. If they write some nice code or start being more helpful, great. If not, tell them to go away. They'll either leave the project (if you ignore them long enough), or they'll get their act together and start writing some code and generally become more pleasant.

Unfortunately the senior Stampede developers didn't take on freak management. In other words, they allowed these two guys to pester me (and others) to no end. While the senior developers were always in favor of my development work, they didn't do much to get these guys under control. So one day I decided that it would be easier to create my own distribution rather than have to put up with the two freaks. I resigned from Stampede development and started making plans to produce my own distro.

While I felt a bit weird about leaving a project because of two lower-level developers, the fact that they weren't dealt with really indicated that the project had severe managerial problems. If the higher-level developers weren't able or willing to make sure the Stampede development effort was pleasant and rewarding, then I didn't want to be there.

Starting afresh

Once I left I breathed a big sigh of relief. Wow! Finally, things were calm and quiet. Now it was time to define what my distribution would be about and what it would contribute to the Linux distribution scene. One of the things that attracted me to Stampede was its raw performance (thanks to its use of the experimental Pentium-optimized pgcc compiler). So I decided to focus first on performance. In addition to minimizing CPU utilization, I also wanted to minimize bloat. Too many distributions (especially those popular shrink-wrapped ones) enable so many daemons by default that you barely have any RAM left after opening an xterm. I wanted my distribution to be lean and mean, and focused on maximizing the performance of the hardware that it ran on. I decided to take a holistic approach and tackle the performance problem from all angles.

But I had a serious lack of resources, since I was the only developer for my distribution! How could I possibly create something that was comparable to Caldera or RedHat off the ground on my own? The answer was automation. I had to write scripts to automate everything, so that I would have a minimal amount of time-consuming, repetitive labor. After all, that's what computers do best, right?

I quickly saw that writing simple scripts for the kind of automation I needed wasn't going to be enough. I needed to design a complete system for generating a Linux distribution from scratch. I tentatively called it the ebuild system and got to work. The ebuild system would be able to automatically create all the distribution binaries, automating everything from unpacking and patching the sources to compilation, installation and packaging. After getting a basic ebuild prototype working, I started creating ebuild scripts for the key components of a Linux distribution (like gcc, glibc, binutils, util-linux, and friends). My Stampede development box was gradually turning into my own system, as I redesigned the initialization scripts (basing them on the Stampede initialization scripts that I had previously designed) and testing and installing every new package that I created.

A few months later I had a complete, self-hosted Linux distribution. I named it Enoch and sat back and smiled contentedly. But what became of Enoch, and how did Gentoo Linux evolve? Join me in my next article as I tell the story of how Enoch became Gentoo Linux, and the many new challenges I faced along the way.

prev"" #1 next