Различия между версиями 19 и 20
Версия 19 от 2008-08-22 03:51:52
Размер: 48010
Редактор: Allena
Комментарий:
Версия 20 от 2008-08-22 04:18:25
Размер: 45592
Редактор: Allena
Комментарий: первые 3 мини-куска done
Удаления помечены так. Добавления помечены так.
Строка 34: Строка 34:
Здесь начинается одна совершенно замечательная возможность. Программный продукт -- операционная система, а уж тем более пользовательский программный продукт, перестал быть полностью ориентирован не только на один конкретный компьютер (а было и такое), но даже на конкретный тип компьютеров. Программный продукт стал портируемым. Это значит, что появилась возможность один раз его создавать, после чего сравнительно несложными операциями переносить с компьютера на компьютер, если они одинаковой архитектуры (буквально -- перенес, запустил, а она все еще работает), но даже если они разной архитектуры, то использовать компилятор с того же самого языка, перекомпилировать заново, и всё. Портируемость программных продуктов стала, в определенном смысле, революционным событием. Появилась возможность создать программный продукт один раз, и после этого использовать его на различных компьютерах. В случае одинаковой архитектуры достаточно было простого копирования, в случае разных --- перекомпиляции. Жизненный цикл программного продукта полностью отделился от жизненного цикла компьютера и даже класса компьютеров. Это начало происходить в 70-ые годы. Стало ясно, что производство программных продуктов отличается от производстав глинянных горшков: для того, чтобы сделать в два раза больше горшков надо потратить в два раза больше времени, сил, глины; для того, чтобы сделать две копии программы достаточно вызвать утилиту копирования. Стало очевидно, что переносимые программные продукты не являются материальными.
Строка 36: Строка 36:
Здесь возникает одна очень важная вещь. В тот момент, когда жизненный цикл программного продукта полностью оторвался от жизненного цикла компьютера и даже класса компьютеров, стала очевидна пропасть, связанная с понятиями собственности на материальный объект и на программный продукт. Это началось в 70-е. В какой-то момент стало ясно, что в отличие от горшков, которые -- сколько хочешь произвести горшков, столько и нужно запасти глины, а если ты хочешь произвести в два раза больше одинаковых горшков, тебе нужно в два раза больше глины и энергии на обжиг, и т.д., а еще в два раза больше времени, чтобы их слепить, если ты их руками лепишь, то в программном продукте это все не так, и для того, чтобы сделать две копии одного и того же программного продукта, который будет работать на любой машине -- не нужно вообще ничего. Нужно вызвать утилиту копирования, она скопирует, и на этом расходы закончатся. Еще важнее то, что выяснилась еще одна вещь: для создания хорошей программы целесообразно привлечь к её разработке разных людей, заинтересованных в немного разных задачах.
Строка 38: Строка 38:
Стало очевидно, что, с одной стороны, переносимые программные продукты нельзя мерить той же меркой, что и материальные, тут явно какой-то продукт нематериальный, интеллектуальный, а с другой стороны, стала очевидной еще более важная вещь. Для того, чтобы написать хорошую программу, почти всегда разумно для этого привлечь усилия нескольких разных людей, каждому из которых нужно разное от этой программы. Вы написали программу, которая берет некий текст и форматирует его для печати на принтере IBM-(какой-то, под который впервые в мире была сделана такая отдельная программа), потом выяснилось, что Например, кто-то пишет программу для форматирования текста для печати на принтере IBM. Благодаря портируемости, эту программу могут использовать еще в десятке организаций. В одной из организация сотрудник хочет напечатать поздравление секретарше шефа в стихотворной форме и добавляет в программу возможности центрирования и использования красивых шрифтов.
Строка 40: Строка 40:
 * этот принтер стоит в десяти организациях, где тоже стоит этот принтер, илюди думают, что им делать, а тут вы написали программу,

 * вы не собирались с помощью ее выводить поздравление секретарше шефа в стихотворной форме, а ваш коллега собирается, и он хочет, чтобы в этой программе была функция форматирования с центрированием посередине, красивым шрифтом или что-нибудь в этом духе.

То есть, есть пользователи, которым от программного продукта нужно одно. есть пользователи, которым от него нужно другое и эти пользователи согласны дописать кусок программы, чтобы она стала делать и то, что им нужно, тоже.
Суть в том, что пользователи модифицируют программный продукт, приспосабливая его к своим нуждам.
Строка 111: Строка 107:
||21 || 1 || 1 || 1 || || 1 || PavelSutyrin, [[Allena]], VsevolodKrishchenko || || || ||35 || 1 || 1 || 1 || || 1 || PavelSutyrin, [[Allena]], VsevolodKrishchenko || || ||

История

Когда компьютеры были очень большие, а программы очень маленькие... Разработка ПО была неотъемлемой частью разработки компьютера. Программное обеспечение было жестко привязано к аппаратному обеспечению конкретной машины. Именно тогда и появились сами термины "аппаратное обеспечение", "программное обеспечение".

Простая мясорубка состоит из железяк, и работает сама по себе. Элементы компьютера, даже правильно собранные, сами по себе не заработают. Для работы компьютера необходимы программы. Аппаратное обеспечение должно быть скреплено прораммным.

В те времена, когда программное обеспечение было состоявляющей частью компьютера, оно разрабатывалось с той же скоростью и в то же время, что и апаратное обеспечение. Время проектирования ЭВМ Мир, начиная с теоретических разработок и заканчивая эксплуатационным образцом, составило 12 лет. И на протяжении всего этого времени параллельно с аппаратным разрабатывалось программное обеспечение, именно для "скрепления" аппаратуры, а не для решения пользовательских задач. Пользователи для решения своих задач писали программы сами. Заграницей использовались аналогичные подходы. Надо заметить, что в то время, в отличии от нынешней ситуации, Советский Союз опережал весь мир в области разработки вычислительной техники.

Неотъемлемость программного обеспчения от аппаратного можно наблюдать и в некоторых современных устройствах. Например,в неуправляемых свитчах. В них нет операционной системы, это почти что просто хабы, тем не менее, в них есть регистры для хранения MAC-адресов, реализация технологии защиты от spoof'инга, и т. п.

Исторической и идеологической предшественницей GNU/Linux является операционная система UNIX. История UNIX весьма обширна и интересна, но мы заострим вниманиt лишь на трех вещах, её касающихся.

Для себя

Исторически операционная система UNIX разрабатывалась "для себя". После того, как Bell Labs отказались от участия в проекте MULTICS группа исследователей из Bell Labs, задействованная в этом проекте, хотела продолжить работу над созданием операционной системы с разделением времени. Название UNIX предложил Брайан Керниган, по ассоциациям с MULTICS. Предложение купить компьютер для проекта было отклонено и поначалу для экспериментов использовался найденный в подвале старый PDP-7.

Немного ранее Кен Томпсон создал игру Star Trek(в мемуарах используется названии Space Travel, так как Star Trek является зарегестрированным торговым знаком), и был ею весьма увлечен. Дениса Ритчи интересовали больше научные, теоретические вещи --- он разрабатывал языки программирования(A, B). Таким образом, имелась необходимость в обеспечении работы нескольких пользователей на одной машине. Чтобы на одном компьтере могли одновременно выполняться несколько процессов и работать несколько пользователей рабочей среде нужно было ядро, отвечающее за грамотное распределение ресурсов --- машинного времени, оперативной памяти, внешних устройств. Уже тогда было очевидно, что такое ядро должно быть обособлено от пользовательсктих задач, и должно лишь предоставлять возможность разделения ресурсов.

По сути, ядро операционной системы --- это всего лишь большая библиотека, предоставляющая функции для управления ресурсами. Ресурс можно заказать, освободить, можно получить отказ в доступе к ресурсу, и т.п. Доступ к программному интерфейсу ядра предоставляется в виде системных вызовов(system calls, 2-ая секция man). Программы, позволяющие воспользоваться функциями ядра называют утилитами. По замыслу разработчиков набор утилит должен реализовывать командный интерфейс ядра на основе прораммного. Утилиты позволяют манипулировать файлами, производить печать, и т. д.

[ПРИКРЕПЛЁННЫЙ ФАЙЛ] Кен Томпсон и Денис Ритчи продвинулись в реализации этой концепции. В начале 70-ых задачей начал заниматься целый отдел, началось внедрение. Начальник отдела увлекался макроязыками и предложил идею конвейера, то есть, потоковую передачу данных вместо макроподстановок и скобочек как в лиспе.

В этой технологии отсутствует способ нормальной реализации механизма ветвления, однако, при использовании командной строки механизмы сложнее конвейер могут запутать пользователя.

Затем в разработке начал принимать участие известный поупляризатор науки Брайан Керниган. Он предложил две вещи:

  • Добавить в язык B некоторые высокоуровневые средства из PL/I, например, структуры.
  • Переписать операционную систему на языке C. Идея состояла в том, что при написании большей части операционной системы на неком языке программирования, этой ОС потенциально можно оснастить любой компьютер, для которого существует компилятор использовавшегося языка.

В то время уже существовали языки программирования, такие как PL/I и FORTRAN. Но они были ориентированы больше на решение пользовательских задач, чем системных. FORTRAN(FORmula TRANslator), первый высокоуровневый язык, был придуман математиками и ориентирован на решение математических задач. ALGOL-60 имел некоторые особенности, не позволявшие создавать нормальные реализации. PL/I только начинал приобретать законченную форму, и также был ориентирован скорее на пользовательские задачи, хотя и содержал много интересных идей. Керниган предложил реализовать язык прогрраммирования ориентированный на системные задачи.

Потенциальным результатом использования подобного подхода была возможность портирования операционной системы на компьютер с принципиально отличающейся архитектурой. В 1972 ОС была портирована на 32-разрядный Interdata-32 с 16-разрядного PDP-11. Небольшая часть ядра, отвечающая за работу с аппаратурой, разумеется, реализовывалась и реализовывается на ассемблере в любом случае, однако вся логика операционной системы была написана на языке C.

Переносимость программ

Портируемость программных продуктов стала, в определенном смысле, революционным событием. Появилась возможность создать программный продукт один раз, и после этого использовать его на различных компьютерах. В случае одинаковой архитектуры достаточно было простого копирования, в случае разных --- перекомпиляции. Жизненный цикл программного продукта полностью отделился от жизненного цикла компьютера и даже класса компьютеров. Это начало происходить в 70-ые годы. Стало ясно, что производство программных продуктов отличается от производстав глинянных горшков: для того, чтобы сделать в два раза больше горшков надо потратить в два раза больше времени, сил, глины; для того, чтобы сделать две копии программы достаточно вызвать утилиту копирования. Стало очевидно, что переносимые программные продукты не являются материальными.

Еще важнее то, что выяснилась еще одна вещь: для создания хорошей программы целесообразно привлечь к её разработке разных людей, заинтересованных в немного разных задачах.

Например, кто-то пишет программу для форматирования текста для печати на принтере IBM. Благодаря портируемости, эту программу могут использовать еще в десятке организаций. В одной из организация сотрудник хочет напечатать поздравление секретарше шефа в стихотворной форме и добавляет в программу возможности центрирования и использования красивых шрифтов.

Суть в том, что пользователи модифицируют программный продукт, приспосабливая его к своим нуждам.

Коллективная разработка

Фактически, после того, как система UNIX стала более или менее успешной, именно так шло ее развитие в течение порядка десятка лет. Люди что-то писали, какие-то программы, записывали их на магнитные ленточки, встречались на конференциях, передавали друг другу эти ленточки, дома они эти ленточки распаковывали, там оказывались программы, они их компилировали, находили в них ошибки, дорабатывали, снова записывали на ленточки, и так друг с другом обменивались. В особенности это касалось даже не столько того проекта, за которым стояли Кен Томпсон и Денис Ричи, все-таки это была Bell Labs, и то что ни делали было производственным продуктом и принадлежало компании AT&T. В большей степени это касалось UNIX-подобной операционной системы, которая разрабатывалась американскими университетами -- BSD (Berkley System Distribution). То есть, уже подразумевалось, что много людей пишут много программ, потом программы собираются в блок, этот блок называется distribution и распространяется. Авторы программ распространяли их затем, чтобы к ним присоединились те, кто хочет что-то подправить. Эта формы разработки программного продукта даже в те времена, когда для того, чтобы передать друг другу исходный текст, нужно было записать его на ленточку и ее передать друг другу в материальном виде, например, встретиться на конференции, переписать, или послать бандеролью, даже в те времена эта форма активно показывала себя с положительной стороны, потому что программами занимались ученые, их было немного, они встречались и постоянно тусовались на всяких конференциях, и на них обменивались не только идеями, но и неким содержанием.

Это счастье продолжалось до начала 80-х годов (или конца 70-х), в течение которых стало очевидно, что нарождающася операционная система UNIX, и ее всякие подобия, обладают двумя очень важными с точки зрения бизнеса свойствами:

  • кросс-платформенность. Если появляется новый компьютер, то достаточно легко придать ему операционную систему, если она написана, условно, вся на языке Си, кроме той части, которая аппаратно-зависима. Для того, чтобы создать ОС для этого компьютера, нужно не 5 лет, а грубо говоря, полгода, со всеми расходами. Совсем другое дело, и понижаются расходы и все такое;
  • она достаточно технологична по архитектуре и позволяет гибко конструировать всевозможные решения пользовательских задач. Идея в том, что ядро + утилиты + вокруг утилит какие-то приложения, которые в основном, перерабатывают пользовательскую информацию, пользуются утилитами для доступа к ядру (или сами вызывают системные вызовы), главное -- они смотрят на пользователя, решают его, пользовательские задачи. Эта архитектура оказалась достаточно гибкой, чтобы с помощью ее решать практически любую задачу, которую предложит пользователь, причем, в том числе, решать силами самого пользователя. Конструктор такой.

Лицензионно-правовые аспекты

Это все привело к т.н. unix wars, войнам в стане правообладателей. Тут-то выяснилось, что большинство программного кода, который написан в этой ОС, кому-нибудь да принадлежит, более того, выяснилось, что по большей части он принадлежит работодателю. Если работник пишет программу не в свободное от работы время где-то в подвале, а в рабочее время за деньги работодателя, то, по определению, если иного не оговорено в контракте, программа является собственностью работодателя. Это вошло в резкое противоречие с упомянутым академическим стилем разработки программ. Разработчики UNIX-систем не привыкли к тому, что они не имеют права показать ту программу, которую они сейчас разрабатывают, то есть еще не доделали, двум-трем десяткам своих коллег, чтобы кто-нибудь из них заинтересовался и предложил свою помощь и что-то там доделал. Одно дело, когда у тебя целое сообщество заинтересованных, другое дело, когда ты один на эти деньги все пишешь.

Мало того, выяснилось, что большая часть людей, участвовавших в разработке, не давали себе труда об этом задуматься, поэтому очень много исходного кода, который вошел в разные UNIX'ы, он то ли принадлежит кому-то, то ли не принадлежит никому, совершенно неизвестно, сделан он в рабочее или в свободное время, копирайта нигде не стоит, люди просто занимались своим делом, вот чего-чего а про копирайт они не думали.

В результате произошло в 80-х годах как произошёл стремительный рост UNIX-подобных систем как коммерческих, так и продолжалось развитие университетской ветки. Родовое дерево UNIX-систем занимает 24 листа A4, или даже больше (картинка).

Всё это совпало с тремя вещами:

  • Стала стремительно повышаться информационная связность. По крайней мере в Америке и в крупных центрах Европы, появился Интернет, хотя и еще маленький. Компьютеры можно было объединять в группы, и работающие на них люди могли обмениваться информацией уже не путем посылки магнитных ленточек бандеролью, а путем сетевых протоколов -- скачать файл, послать сообщение, и т.п. Эффективность работы команды заинтересованных людей, находящихся в разных местах, сильно повысилась.
  • Стало ясно всем, что без строгого разделения на свободное ПО, про которое известно, что с ним можно делать что угодно, без каких бы то ни было обязанностей к какому бы то ни было отдельному правообладателю, должно быть строго отделено от несвободного, иначе не миновать беды вроде тех же самых unix wars. Для свободного и несвободного ПО характерны разный способы разработки. Люди, которые хотели сохранить академический стиль разработки и настаивали на том, что программный продукт должен оставаться свободным, должна сохраняться возможность привлекать к его разработке кого угодно, когда угодно, на каких угодно условиях, чтобы продукт вообще жил. С другой стороны:
  • Появилась группа людей, которые быстро сообразили, с какой стороны у этого бутерброда масло (я расскажу, с какой стороны и сколько масла), и сказали: вы что-то путаете, вы можете зарабатывать немыслимые бабки на ваших

программах, только этого не делаете. Вы сидите и программируете, вместо того, чтобы брать потом с этой программы 1000% дохода, из которых за вычетом налогов, 100% дохода положите себе в карман, вместо этого вы занимаетесь какой-то академической ерундой. Из этого можно сделать такой бизнес, от которого мир ахнет. И они тоже были в своём праве, любое место, где можно совершенно законным способом сделать много денег -- это место хорошее.

То есть, произошёл очевидный раскол на людей, которые хотели сохранить академический стиль разработки и продолжать заниматься исследованиями, как в остальном научном мире. Ученые собираются, что-то исследуют, публикуют статьи, и это всё, на что они претендуют. "Я первый опубликовался, это я придумал". А все остальные пользуются результатами их исследований. Иначе ученый сам не продвинется дальше, бывает нужна помощь исследователей совершенно из других областей, так оно все и продолжается. Это не просто ностальгия по старым временам, а сохранение научного подхода в области программирования. С другой стороны, в этом расколе другую сторону приняли люди, которые сказали, что это большие деньги, и бессмысленно их транжирить, вы можете организовать очень эффективное производство на эти 100% дохода, гораздо более эффективное, чем забесплатно.

К этому вопросу мы ещё вернёмся.

Указанные события имели место в 80-е года. С точки зрения развития программного производства, чтобы было понятно, 80-е годы выглядели как годы если не закостенения, то сильной остановки в плане стороны системно-технологической. Фактически 80-е почти все прошли под флагом "компьютер в каждый дом", разработки интерфейсной части, Макинтоши, DOS'ы с играми, потом Windows'ы, были еще отдельно игровые компьютеры. Технологически это топталось на месте или даже спускалось вниз, т.к. все домашние компьютеры были 8-битные, на которых даже полноценной ОС не было, там было "программное обеспечение". Почему? Потому что технология без исследований так вот не живет, она стоит, а исследования имеют академическую структуру. Что же касается другой стороны, то работа была из области: нарисовать кнопочку, заплатить художнику, заплатить мировому специалисту в области usability (Макинтош известен тем, что в нем работали за деньги практически все самые крупные на сегодняшний день специалисты в области usability).

К концу 80-х выполнилось необходимое условие для того, чтобы сформировалось свободное сообщество вокруг программных продуктов -- информационная связность, чтобы люди, которые хотят работать вместе, могли делать это так и тогда, как и когда им это удобно, без особенных расходов со своей стороны, чтобы не приходилось платить за свой энтузиазм.

К концу 80-х -- началу 90-х информационная связность дошла до того, что потихонечку стали вымирать такие вещи, как система UUCP, FIDO, какое-нибудь, у нас оно еще долго жило, но мы немножко в этом опоздали, телефонные BBS-системы, когда нет сети, а только модем, на который можно звонить. В какой-то момент даже перестали выпускать подборки свободного софта -- GNU distributions, потому что никому не было нужно, но в России всем этим вымирающим еще долго пользовались, т.к. в 90-е с было довольно туго с интернетом.

Связность возросла, и оппозиция между свободным и несвободным возросла еще сильнее, просто появились случаи серьёзного преследования копирайта, по поводу программного продукта, и т.п.

В конце 80-х такая же судьба накрыла одного из самых известных людей в области свободного софта, а именно Ричарда Мэтью Столлмана, который работал над lisp-машиной (это такой компьютер, у которого вместо языка ассемблера внутри lisp), он делал к ней "программное обеспечение" (именно его), а потом выяснилось, что все, что он написал, в том числе и текстовый редактор EMACS, который он писал, вообще-то, для себя и для своих нужд, принадлежит компании-работодателю, просто потому, что так или иначе это было сделано в рабочее время. Он не просто задумался о том, что ПО должно быть свободным, но и, и это главное его достоинство, и главное действие, которое он для нас всех сделал -- изобрёл свободное лицензирование программных продуктов.

Свободное лицензирование программ

Когда вы начинаете распространять свой программный продукт, вы его сопровождаете некоторыми условиями распространения, которые вы как правообладатель на него накладываете. При этом, ровно так, как наши коллеги (или оппоненты) к своему программному продукту прикладывают условие, что нельзя его копировать, модифицировать, дизассемблировать, ровно тем же способом на своей программе можно написать: "программу можно дизассемблировать, распространять, модифицировать, что угодно с ней делать, но ни в коем случае нельзя то, что вы будете распространять потом, закрывать, делать его менее свободным, чем то, что вы получили сами".

Путем некоторых упражнений с юристами (в Америке есть такое понятие -- авторская лицензия: человек может написать любую бредятину, ее подписать у нотариуса и она будет иметь законную силу, у нас такого нет), усилиями RMS и его коллег и соратников по Free Software Foundation эта лицензия была доведена до статуса юридической значимости в США и в очень многих других странах (либо сама лицензия значима, либо она принимается во внимание, как у нас в России). И вы распространяете свой программный продукт не просто, а с законной лицензией, которая запрещает делать с ним то самое, от чего способ разработки и ваше понимание того, как дОлжно пользоваться вашим программным продуктом, пострадает. У этого есть всякие бизнес преимущества, но об этом попозже.

Движение FSF было достаточно обширно, не хватало сущей малости -- ядра. Было BSD-ядро, я не знаю, почему оно не приглянулось ребятам из FSF. Никто не мешал его перелицензировать под GPL. Есть же Debian GNU/kFreeBSD. Это какие-то личные заморочки. Нужно понимать, RMS замечательная личность, он очень красноречив, харизматичен и говорит очень много правильных вещей, вместе с тем у него очень много всяких исторических наслоений очень странных, и периодически он начинает изрекать всякие глупости типа: "все про Линуса (Торвальдса) знают, считают, что свободные программы это Линус а мы, значит, типа, ничего не сделали. На самом деле все сделали мы, а Линус так только, ядро написал."

Непонятно, чем BSD-ядро не подошло FSF. Хотя, надо понимать, что к конца 80-х началу 90-х в BSD ситуация была абсолютно такая же, там тоже были свои unix wars, помните, почему закрыли ветку FreeBSD 1, потому же, почему был отозван BSD 4.4. В нем нашли большой кусок кода, который оказался кому-то принадлежащим, и этот кто-то сказал -- только через мой труп или через ваши деньги, и BSD 4.4 отозвали вышел BSD4.3-Reno, это BSD 4.4 + весь код, который можно было включить, и там произошли большие всякие перетряхи, а может лично с McKusick'ом RMS что-то не поделил...

Дело резко сдвинулось с мертвой точки, когда один финский парнишка, тогда еще студент (этнически, вроде бы не финн), Линус Торвальдс, экспериментировал с еще тогда несвободной (сейчас уже она свободная) учебной ОС MINIX, написанной столпом этого дела, Э. Танненбаумом. В мире программирования есть Кнут, в мире ОС есть Танненбаум, такого же масштаба величина, разве чуть-чуть меньше. Линус написал очень маленький unix, складной, умещающийся на дискете, но, в традициях тогдашнего времени она была несвободная, ее можно было изучать, но нельзя было на основе ее ничего делать, но нельзя было распространять, по университетам можно, а дальше не надо. Это было вполне в академическом стиле, потому что, в конце концов, никто не предполагал, что на основе этого кто-то будет что-то делать. Он это дело изучал, а у него была идея сделать свободную систему, чтобы оторваться от ограничений университетских обучающих систем, а сделать систему, на которой можно делать все. И вот он изучал-изучал, потом решил написать целое ядро на этот счет, свое собственное, т.к. свободные утилиты уже были в большом количестве, люди их писали и пользовались ими, а ядра не было, и, начав в 1991 году, за год он так преуспел, ему удалось написать ядро достаточно работоспособное, которым можно было пользоваться в реальности (уточнить даты и версии)

Первоначально там были взяты куски из MINIX'а, которые потом были выброшены по лицензионным соображениям (дольше всего держалась файловая система, которую нужно было переписывать от начала до конца, но её тоже переписали, слишком уж она была учебно-тренировочная).

В этом же 1991 (уточнить!) году научный руководитель сказал Патрику Фолькердинку: вот тебе ядро, вот утилиты, сделай операционку. И в качестве дипломной работы он сделал дистрибутив. Фактически совершилось то, что раньше делалось десятилетиями. За год было создано ядро имелось достаточно нормальное окружение (утилиты), и вот из этого ядра и этого окружения, которые взяты из очень разных мест, собраны по всему миру, некий студент дипломник за год создал то, что называется дистрибутив -- комплект ПО с ядром. Нечто, что можно засунуть в компьютер на сидюке, установить, и получится операционная система. Эта штука была беспрецедентная, потому что до тех пор, все-таки, производство операционных систем как таковых было уделом крупных производителей или доставалась вам по университетской программе, как BSD. В 1992 году он сдал диплом и забыл про него, хотелось человеку работать, бабки зарабатывать, а не собирать из свободных программ какие-то операционные системы. И что вы думаете, в течение всего 1992 года его все стали клевать: "Мужик, ты тут сделал свободную операционную систему, мы тут ее у себя уже поставили, вот оно уже у нас стоит. Ты куда вообще делся, давай, продолжай. Ты ж понимаешь, что ничего другого нету". В 1993 году вышел первый плановый релиз дистрибутива Slackware (так он стал называться к тому моменту). Еще двое там было у истоков.

После этого процесс производства и выдачи программного продукта под названием ОС перешел из многолетней практики в практику месяцев, потому что тут же начали появляться другие дистрибутивы, вторым, по-моему, был сразу RedHat, Там американцы сказали: "там в Европе с этим Линуксом что-то такое делают интересное, а у нас тут только унылое BSD, щас мы тоже что-нибудь сделаем." Пришла некая команда со словами: "о, это же новая технология, щас мы ею воспользуемся, у нас же все программируют, нам ничего не надо делать, только продавай себе услуги". В течение всех 90-х наблюдался рост числа различных дистрибутивов, получивших название "операционная система GNU/Linux", и теперь понятно, что дистрибутив -- это не сами эти свободные программы, которые и без того одинаковые, и безусловно не ядро (а Linux -- это как раз ядро). Дистрибутив и компания, которая его производит, это те люди, которые собираются и делают из разрозненного набора операционную систему со своими присущими ей свойствами (например, вы могли заметить, что Ubuntu и ALT Linux отличаются, хотя оба Линуксы).

По статистике заметно, что активный рост дистрибутивов Линукс начинается всякий раз, когда выходит очередная версия Windows. Вышла Windows 95 в 94 году, 94-95 год -- это время зарождения многих дистрибутивов. Когда люди поняли, что им нужно переучиваться (с DOS, Win 3.1, и т.п.), они решили, что будут переучиваться на Линукс, а не на Windows 95. То же самое происходило в 99-2000 году, то же самое происходило с выходом XP, когда это было, а уж с выходом Vista я уже вообще молчу, даже самые унылые люди смотрят в сторону чего угодно, накопить денег и купить Mac вместе с MacOS, или плюнуть на все и перейти на этот ужасный Линукс, но только бы не Vista.

В этой длинной истории есть несколько важных пунктов, которые будут помогать нам въехать в то, почему Линукс так ужасен и что нам с этим делать.


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

35

1

1

1

1

PavelSutyrin, Allena, VsevolodKrishchenko


PspoClasses/080716/01History (последним исправлял пользователь DmitryChistikov 2008-11-15 00:49:40)