от Ричард Столман(12-12-2001)

рейтинг (35)   [ добре ]  [ зле ]

Printer Friendly Вариант за отпечатване

GNU операционната система и движението за отворен код (Free Software Movement) [Част 2]
Превод: Андрю Иванов
Адрес на оригинала: http://www.oreilly.com/catalog/opensources/book/stallman.html


Поддръжка на свободния софтуер

Философията на свободния софтуер отхвърля определени, широкоразпространени бизнес-практики, но не е срещу бизнеса. Когато бизнесмените уважават свободата на потребителите, ние им пожелаваме успех.

Продажбата на копия на Emacs е пример за подобен бизнес със свободен софтуер. Когато, обаче, FSF пое този бизнес, аз трябваше да потърся друг начин да си изкарвам прехраната. Открих го в продажбата на услуги свързани със свободния софтуер, който бях разработил. Това включваше обучение по теми, като например, как да се програмира GNU Emacs или как да се настрои GCC, а също и разработване на софтуер (главно пренасяне на GCC на нови платформи).

В днешно време, всеки от тези варианти за правене на бизнес се практикува от множество компании. Някои разпространяват колекции със свободен софтуер на CD-та; други предлагат поддръжка, като услугите варират от отговаряне на въпроси на потребителите, през корекции на грешки, до добавяне на значими нови функции. Вече дори има компании основани върху разпространяването на нови безплатни софтуерни продукти.

Все пак внимавайте -- някои компании, които се окачествяват с термина "Open Source", всъщност основават бизнеса си върху не-свободен софтуер, който работи заедно със свободен. Това не са компании, които се занимават със свободен софтуер. Те се занимават със собственически софтуер, а продуктите им примамват потребителите далеч от свободата. Това са "услуги с добавена стойност", които отразяват ценностите, които искат да ни натрапят: "удобството е над свобдата". Ако наистина ценим повече свободата, би трябвало да ги наречеме услуги "с отнета свобода".

Технически цели

Основната цел на GNU беше да бъде свободен софтуер. Дори ако GNU нямаше технически преимущества пред Unix, той щеше да има социално преимущество, позволявайки коопериране на потребителите, а и етични предимства, поради факта, че уважава свободата на потребителите.

Но естествено беше да бъдат приложени познатите стандарти, отличаващи се с добра приложимост в работата -- например, динамично разпределяне на структурите с данни за избягване на произволното определяне на размерите, и работата с всички възможни 8 битови кодове, където това има смисъл.

В допълнение, отхвърлихме фокусирането на Unix върху малките обеми памет, решавайки да не поддържаме 16 битови машини (беше очевидно, че 32 битовите машини ще станат стандарт докато завършим GNU системата), а също така решихме и да не се стараем да намалим ползването на памет, освен ако не надвиши 1 мегабайт. При програми, за които обслужването на големи файлове не е критично, ние насърчавахме програмистите да изчетат целият входящ файл в паметта, а след това да сканират съдържанието му без да се тревожат за I/O (входно-изходни операции).

Всичко това позволи на много GNU програми да надминат техните съответстващи под Unix по надеждност и скорост.

Дарени компютри

С увеличаването на репутацията на проекта GNU, хората започнаха да предлагат да дарят машини работещи с Unix на проекта. Тези машини бяха много полезни, защото най-лесният начин да се разработят компонентите на GNU беше да се работи върху Unix система, чиито компоненти да бъдат заменяни един по един. Но това повдигна един етичен въпрос: правилно ли беше да притежаваме копие на Unix.

Unix беше (и си е) собственически софтуер, а философията на проекта GNU казваше, че не трябва да използваме такъв софтуер. Но, прилагайки същата аргументация, която оправдава извършеното при самозащита, реших, че е допустимо да се използва собственически софтуерен пакет, когато това е от особена важност за разработването на свободна програма-заместник, която да помогне на другите да не използват собственическия пакет.

Но, въпреки оправданието, това все още си беше погрешно. Днес вече не използваме копия на Unix, понеже ги заместихме със свободни операционни системи. Ако се окажеше невъзможно да заменим операционната система на машината със свободна, заменяхме машината.

Списъкът със задачи на GNU

С напредването на проекта GNU, и увеличаването на системнити компоненти, които създавахме и разработвахме, стана необходимо да направиме списък със оставащите "пролуки". Използвахме този списък, за да набираме разработчици, които да напишат липсващите "парчета". Този списък стана известен като Списъкът със задачи на GNU. В добавка към липсващите Unix компоненти, ние включвахме и различни други полезни софтуерни проекти и такива по документацията, които смятахме, че една завършена система трябва да притежава.

Днес, едва ли може да се каже, че все още има някакви Unix компоненти в списъка на GNU -- тези задачи са вече приключени, с изключение на няколко без особено значение. Но списъкът е пълен с проекти, които някои могат да нарекат "приложения". Всяка програма, която се харесва на по-широк кръг потребители, би била полезно допълнение към една операционна система.

В списъка са включени дори игри и са били включени още от самото начало. Unix включваше игри, така че GNU естествено също трябваше да ги включва. Но съвместимостта не беше цел при игрите, така че не следвахме стриктно списъка с игрите, включени в Unix. Вместо това, ние включихме в списъка набор от различни видове игри, които потребителите биха харесали.

Library GPL на GNU

Това не е въпрос на принципи: Няма такъв принцип, който да казва, че на собственическите софтуерни продукти е дадено правото да включват в себе си наш код. (Защо да допринасяме за проект, основаващ се на отказа да се споделя с нас?) Използването на LGPL за Си-библиотеката или за която и да е библиотека е въпрос на стратегия.

Си-библиотеката има несъществена функция; всяка собственическа система или компилатор идва със Си-библиотека. Ето защо, ако направим нашата Си-библиотека достъпна само за свободния софтуер, това не би му дало никакво предимство. Това не би спомогнало за използването на нашата библиотека.

Една система, обаче, е изключение: при GNU (а това включва и GNU/Linux), Си-библиотеката на GNU е единствената такава. И така, условията за разпространение на GNU C определят дали е възможно да се компилират собственически програми за GNU системата. Няма етична причина да бъдат допуснати собственическите програми до GNU, но стратегически погледнато изглежда, че ако не бъдат допуснати, това по-скоро би съдействало за неизползването на GNU, отколкото за създаването на повече свободен софтуер.

Ето защо, използването на Library GPL е добра стратегия за Си-библиотеката. За други библиотеки, при всеки конкретен случай трябва да бъде вземано стратегическо решение. Когато библиотеката изпълнява специфична функция и може да помогне при написването на определен тип програми, лицензирането й под GPL, ограничаването на употребата й само до свободни програми, е начин да се подпомогне свободният софтуер, като му бъдат дадени предимства пред собственическия.

Помислете за GNU Readline, библиотека разработена да осигури редактиране в командния ред на BASH. Readline е лицензирана под GNU GPL а не под Library GPL. Това вероятно ограничава използването на Readline, но това за нас не е голяма загуба. Междувременно, поне едно полезно приложение беше превърнато в свободен софтуер, специално, за да използва Readline и това е истинска придобивка за Общността.

Разработчиците на собственически софтуер разполагат с предимствата на парите; разработчиците на свободен софтуер трябва да си осигуряват взаимно предимства. Надявам се, че един ден ще имаме богата колекция от 'GPL библиотеки', които няма да имат аналог сред собственическия софтуер и които ще осигуряват полезни модули, от които да се изгражда новия свободен софтуер; които ще допринасят за преимуществото на свободния софтуер при бъдещите разработки.

Задоволяване на лични прищевки?

Ерик Реймънд казва, че "Всеки добър софтуер е започнат зaрaди личните прищевки на някoй програмист". Може би това става понякога, но много от важните GNU програми бяха разрaботени, зa дa имаме цялостна свободна операционна система. Те произхождат от зaмисъл, от план, а не от някакъв импулс.

Така например, ние рaзрaботихмe: библиотеката GNU C, зaщото една Unix-пoдобна система се нуждае от Си-библиотека; BASH - защото една Unix-пoдобна система се нуждае от обвивка (shell); и GNU tar - защото една Unix-пoдобна система се нуждaе от подобна програма. Същото може дa се каже и зa моите програми - компилаторът GNU C, GNU Emacs, GDB и GNU Make.

Някои GNU програми бяха разработени, зa дa се справят със определени заплахи за нашата свобода. Така например, ние разработихме gzip, за да заменим програмата Compress, която беше загубена за Общността поради LZW патентите. Намерихме хора да разработят LessTif, а по-късно - GNOME и Harmony, заради проблемите с определени собственически библиотеки (виж по-долу). Разработваме GNU Privacy Guard, за да замести популярните, но несвободни, програми за криптиране, за да не се налага потребителите да избират между свободата и личната неприкосновеност.

Разбира се, хоратa пишещи тези програми се "зaпалиха" по рaботата и много допълнителни функции бяха добавени от различни хора, зa зaдоволяване на техните собствени нужди и интерeси. Но не зaрaди тези интереси съществуват програмите.

Неочаквани разработчици

В началото нa проекта GNU аз си мислех, че ще рaзрaботим цялата GNU системa и след това ще я разпространим като цялостен пакет. Не така се случи.

Тъй като всеки компонент от системата GNU беше реализиран на Unix система, то всеки от компонентите можеше да работи на Unix системи, много преди цялостна GNU система да съществува. Някои от тези програми станаха популярни и потребителите започнаха да ги дообогатяват и пренасят към всякакви несъвместими помежду си версии на Unix, а понякога дори и за други системи.

Този процес направи тези програми по-мощни и привлече повече средства и разработчици за проекта GNU. Но това, вероятно, също така забави създаването на първата работеща система с няколко години, тъй като разработчиците на GNU отделяха повече време на тези пренесени версии и на новите функции в съществуващите компоненти, отколкото на все още ненаписаните компоненти.

GNU HURD

През 1990 системата GNU беше почти готова; единственият важен компонент, който липсваше, бе ядрото. Бяхме решили да реализираме нашето ядро като съвкупност от сървър-процеси, работещи върху Mach. Mach е микроядро, разработено в Carnegie Mellon University, чиято разработка е била продължена в Университета в Юта; GNU HURD е съвкупност от сървъри (иначе казано "стадо от гнута"), които работят върху Mach и изпълняват различните задачи на Unix ядрото. Началото на разработката беше забавено от очакването Mach да бъде "пуснат" като свободен софтуер, според както ни беше обещано.

Една от причините да изберем този дизайн беше желанието да се избегне това, което изглежда бе най-трудната част от работата: да се дебъгва ядрото без source-level debugger, с който да се направи това. Тази част от работата беше вече извършена в Mach и ние очаквахме да можем да дебъгваме HURD сървърите като обикновени потребителски програми с GNU debugger (GDB). Но ни отне много време да реализираме това, а многонишковите сървъри, изпращащи съобщения един на друг, се оказаха много трудни за дебъгване. Да направим HURD стабилен - изпълнението на тази задача се проточи в продължение на много години.

Alix

Първоначално GNU ядрото не беше наречено HURD. Първоначалното му име беше Alix - по името на тогавашната ми приятелка. Тя беше Unix системен администратор и беше споменала как името й би паснало на някоя версия на Unix система. Веднъж тя се пошегува с приятели: "Някой трябва да кръсти ядро на мое име." Не казах нищо, но реших да я изненадам с ядро наречено Alix.

Е, не стана точно така. Michael Bushnell (сега Thomas), главният разработчик на ядрото, предпочете HURD като име и предефинира Alix, така че да се отнася до част от ядрото - частта, която щеше да прихваща системни извиквания и да ги обработва, т.е. да изпраща съобщения до HURD сървърите.

В края на краищата, Alix и аз скъсахме и тя си смени името. Заедно с това, дизайнът на HURD беше променен, така че Си-библиотеката да изпраща съобщения директно до сървърите, а това предизвика изчезването на компонента Alix.

Но преди всичко това да се случи, един приятел попаднал на името Alix в сорса на HURD и споменал това на Alix. Така името изпълни предназначението си.

Linux и GNU/Linux

GNU HURD не е готов за употреба. За щастие друго ядро е на разположение. През 1991, Linus Torvalds разработи Unix-съвместимо ядро и го нарече Linux. Около 1992, комбинирайки Linux с не-съвсем-готовата система GNU получихме цялостна свободна операционна система. (Комбинирането на тези два компонента беше голяма задача, разбира се.) Благодарение на Linux днес можем да използваме версии на GNU системата.

Тази версия на системата я наричаме GNU/Linux, за да обозначим състава й - комбинация от GNU система с Linux ядро.

Край на част 2

Част 1 може да прочетете от тук



<< GNU операционната система и движението за отворен код [3] | Историята на BSD(част 1) >>