Ubuntu gnu что это
Семейство Ubuntu
Содержание
Семейство Ubuntu
Любой дистрибутив GNU/Linux позволяет заменять практически каждую свою часть на другую, и Ubuntu не исключение. Поэтому существует множество вариантов Ubuntu, отличающихся в первую очередь окружением пользователя и предустановленными программами.
Важной и основной особенностью всех этих систем является полная совместимость между собой, поскольку все они используют общую огромную базу программ, созданную для Ubuntu. То есть в процессе работы с любой из перечисленных ниже систем вы сможете легко доустановить нужные вам программы и компоненты, пусть даже присущие другому варианту Ubuntu.
Поддерживаемые Canonical варианты системы
Базовая версия операционной системы, сочетающая простоту, удобство и функциональность. Основана на фирменной оболочке Unity и компонентах рабочей среды GNOME.
Серверный вариант операционной системы, включающий средства быстрого развёртывания облачной инфраструктуры, создания серверов LAMP, LTSP и прочих.
Поддерживаемые сообществом варианты системы
Вариант Ubuntu, нацеленный на использование в образовательных учреждениях. Содержит самые востребованные образовательные приложения.
Ubuntu с рабочим окружением KDE и программами, типичными для него.
Минималистичный вариант Ubuntu, основанный на рабочем окружении LXDE.
Ubuntu c рабочим окружением MATE, являющимся дальнейшим развитием окружения gnome2, и программами, типичными для него.
Мультимедийный вариант Ubuntu, содержащий программное обеспечение MythTV для создания домашних кинотеатров.
Вариант Ubuntu, предназначенный для людей, активно занимающихся редактированием и созданием мультимедийного контента.
Ubuntu с рабочим окружением Xfce. Отлично подходит для старых, маломощных компьютеров.
Ubuntu с максимально интегрированным рабочим окружением GNOME. Только то, что нужно: современное GNОME окружение и «классический» режим.
Ubuntu Budgie предоставляет среду рабочего стола Budgie, которая ориентирована на простоту и элегантность.
Проект Ubuntu Kylin настроен на потребности китайских пользователей, обеспечивая продуманную и элегантную китайскую атмосферу из коробки.
Другие производные Ubuntu
На этой странице представлено официальное семейство Ubuntu. Однако очень много других дистрибутивов GNU/Linux основано на Ubuntu. Они не входят в официальное семейство, но большинство из них совместимо между собой и с основной Ubuntu.
© 2018 Ubuntu-ru — Русскоязычное сообщество Ubuntu Linux.
© 2012 Canonical Ltd. Ubuntu и Canonical являются зарегистрированными торговыми знаками Canonical Ltd.
Ubuntu gnu что это
Многие пользователи компьютеров каждый день запускают модифицированную версию системы GNU, даже не осознавая этого. В силу особого поворота событий версия GNU, которую сегодня широко используют, часто называется “Linux”, и многим из ее пользователей не известно, что в основном это система GNU, разработанная проектом GNU.
Дополнительные сведения можно найти на страницах “Вопросы о GNU/Linux” и “Почему GNU/Linux?”
Там действительно есть Linux, и эти люди используют ее, но это только часть системы, которой они пользуются. Linux — это ядро — системная программа, которая выделяет ресурсы машины другим программам, которые вы запускаете. Ядро — важная часть операционной системы, но само по себе оно бесполезно; оно может функционировать только в составе полной операционной системы. Linux обычно применяют в комбинации с операционной системой GNU: вся система представляет собой в основном GNU с добавлением Linux, то есть GNU/Linux. Все так называемые дистрибутивы “Linux” на самом деле являются дистрибутивами GNU/Linux.
Многие пользователи не понимают, в чем разница между ядром, то есть Linux, и целой системой, которую они также называют “Linux”. Неоднозначное употребление названия не способствует пониманию этого. Эти пользователи часто думают, что Линус Торвальдс разработал целую операционную систему в 1991 — году, ему только немного помогли.
Программисты, в сущности, знают, что Linux — это ядро. Но поскольку они нередко слышали, как всю систему тоже называют “Linux”, они часто представляют себе историю, которая оправдала бы наименование всей системы по ядру. Например, многие думают, что как только Линус Торвальдс написал Linux (ядро), его пользователи оглянулись вокруг в поисках других свободных программ, чтобы работать с ним, и обнаружили, что (без какой бы то ни было особой причины) почти все необходимое для построения системы типа Unix уже под рукой.
То, что они обнаружили, не было случайностью — это было не совсем полной системой GNU. Доступные свободные программы сложились в полную систему, потому что проект GNU работал над этим с 1984 года. В “Манифесте GNU” мы поставили целью разработать свободную систему типа Unix под названием GNU. “Первоначальное объявление” проекта GNU также очерчивает некоторые из начальных планов по системе GNU. К тому времени, когда началась разработка Linux, GNU была почти завершена.
Цель большинства проектов по созданию свободных программ — разработка определенной программы для определенной задачи. Например, Линус Торвальдс решил написать Linux, ядро типа Unix; Дональд Кнут решил написать TeX, программу верстки текста; Боб Шейфлер решил разработать оконную систему (систему X Window). Естественно измерять вклад такого рода проекта по конкретным программам, которые пришли из этого проекта.
Если бы мы попытались измерить таким образом вклад проекта GNU, к какому бы выводу мы пришли? Один из поставщиков компакт-дисков установил, что в их “дистрибутиве Linux” программы GNU — самый крупный единый массив — около 28% всего исходного текста; в их состав входят некоторые существенные компоненты, без которых системы не могло бы быть; собственно Linux составляет около 3%. (В 2008 году пропорции сходны: в разделе “main” gNewSense Linux составляет — 1,5%, а GNU — 15%.) Итак, если бы вы собирались выбрать название системы на основании того, кто написал программы в этой системе, наиболее подходящим выбором одного компонента было бы “GNU”.
Но на вопрос можно взглянуть глубже. Проект GNU не был и не является проектом по разработке определенных пакетов программ. Это не был проект по разработке компилятора C, хотя мы сделали это. Это не был проект по разработке текстового редактора, хотя мы разработали его. Проект GNU постановил разработать полную свободную операционную систему типа Unix: GNU.
Многие сделали серьезный вклад в свободные программы этой системы, и все они заслуживают признательности за свои программы. Но причина, по которой это является целостной системой — а не только набором полезных программ — то, что проект GNU постановил сделать это такой системой. Мы составили список программ, необходимых, чтобы свободная система была полной, и систематически отыскивали, писали или отыскивали людей для написания всего, что стояло в списке. Мы написали существенные, но не впечатляющие[1] компоненты, потому что без них нельзя получить систему. Некоторые из компонентов нашей системы (средства программирования) стали популярны сами по себе среди программистов, но мы написали много компонентов, не являющихся средствами разработки(2). Мы даже разработали программу для игры в шахматы, GNU Chess, потому что в полной системе игры тоже должны быть.
К началу девяностых мы сложили всю систему, кроме ядра. Мы приступили и к ядру, GNU Hurd, которое работает на Mach. Разработка этого ядра шла гораздо труднее, чем мы ожидали; ядро GNU Hurd стало надежно работать в 2001 году, но оно далеко не готово для общего пользования.
К счастью, благодаря Linux нам не пришлось ждать Hurd. Когда Торвальдс освободил Linux в 1992 году, это заполнило последний серьезный пробел в системе GNU. Тогда люди смогли сочетать Linux с системой GNU [1], чтобы составить полную свободную систему: версию GNU, которая содержала также Linux; другими словами, систему GNU/Linux.
Заставить их как следует работать вместе не было простой задачей. Некоторые компоненты GNU[3] требовали существенных изменений, чтобы они работать с Linux. Объединение в полную систему в едином дистрибутиве, который работал бы “без подгонки”, было тоже большой работой. Это требовало решения вопросов, связанных с установкой и загрузкой системы — проблема, за которую мы тогда еще не ухватились, потому что у нас дело до этого пока не дошло. Таким образом, люди, разработавшие различные дистрибутивы системы, проделали большую и важную работу. Но это было работой, которую, по самой природе вещей, обязательно кто-нибудь выполнил бы.
Проект GNU поддерживает системы GNU/Linux так же хорошо, как саму систему GNU. ФСПО финансировал доработку расширений библиотеки C GNU, связанных с Linux, так что теперь они хорошо пригнаны друг к другу, и самые новые системы GNU/Linux используют текущий выпуск библиотеки без изменений. ФСПО финансировал также на ранней стадии разработку Debian GNU/Linux.
Сегодня есть много разных вариантов системы GNU/Linux (часто называемых “дистрибутивами”). Большинство из них включает несвободные программы — их разработчики следуют философии “открытого исходного текста”, ассоциирующегося с Linux, а не философии “свободных программ” GNU. Но есть и полностью свободные дистрибутивы GNU/Linux. ФСПО предоставляет технические ресурсы для нескольких из них.
Чтобы создать свободный дистрибутив GNU/Linux, недостаточно просто исключить различные несвободные программы. В настоящее время обычная версия Linux тоже содержит несвободные программы. Эти программы предназначены для записи в устройства ввода-вывода, когда загружается система, и они включаются в виде длинных последовательностей чисел в “исходный текст” Linux. Таким образом, поддержка свободных дистрибутивов GNU/Linux сейчас включает также и поддержку свободной версии Linux.
Пользуетесь вы GNU/Linux или нет, пожалуйста, не вводите общественность в заблуждение двусмысленным употреблением названия “Linux”. Linux — это ядро, одна из необходимых составляющих системы. Система в целом — это в основном система GNU с добавлением Linux. Когда вы говорите об этом сочетании, пожалуйста, называйте его “GNU/Linux”.
Если вы хотите сослаться для справок на “GNU/Linux”, эта страница и https://www.gnu.org/gnu/the-gnu-project.html — хорошие примеры. Если вы упоминаете Linux (ядро) и хотите добавить ссылку для справок, http://foldoc.org/foldoc/linux — хороший адрес для этого.
Дополнения
Кроме GNU был еще один проект, который независимо произвел свободную операционную систему типа Unix. Эта система известна как BSD, она была разработана в Калифорнийском университете в Беркли. Она была несвободной в восьмидесятые, но стала свободной в начале девяностых. Любая из свободных операционных систем, существующих сегодня,[4] почти наверное является либо вариантом системы GNU, либо разновидностью системы BSD.
Иногда спрашивают, является ли BSD тоже версией GNU, подобно GNU/Linux. Разработчики BSD сделали свои программы свободными, следуя примеру проекта GNU, и открытые призывы активистов GNU помогли убедить их, но в исходных текстах программ мало общих мест с текстами GNU. Сегодня системы BSD используют некоторые программы GNU, точно так же, как система GNU и ее варианты пользуются некоторыми программами BSD; однако в целом это две различных системы, которые развивались отдельно. Разработчики BSD не добавили ядро в систему GNU, разработав его, так что название типа “GNU/BSD” не подошло бы к ситуации[5].
GNU или Linux?
Просматривая статьи для перевода на translated.by я наткнулся на предложение перевести статью GNU or Linux? за авторством David Chisnall. Автор предлагает разобраться чего же больше в ОС — GNU или же Linux? Собственно перевод этой статьи и предлагается Вашему вниманию.
GNU или Linux?
Ни одна другая система не испытывала таких споров вокруг своего имени. Огромное количество флейм войн началось после заявления FSF о том, что такие дистрибутивы как Ubuntu и Fedora должны называться GNU/Linux, вместо Linux. Пытались ли они просто заработать на чужом труде, или их аргументы небезосновательны?
Чтобы разобраться в этом вопросе давайте взглянем на то, что происходит, когда вы запускаете GNU/Linux систему — сколько используется GNU кода, а сколько Linux кода. Разработчик использует огромное количество GNU кода, к примеру GCC и GNU Make, но насколько это справедливо и для конечного пользователя?
Что делает Ядро?
Перед тем как начать разбираться где же GNU биты, а где Linux, важно понять, что именно делает ядро. Ядро выполняет две главные задачи:
* Освобождает разработчиков от необходимости изучать низкоуровневую архитектуру. Для этого необходимо наличие большого количества драйверов к устройствам и единых интерфейсов к этим драйверам. Хорошим примером служит Сокет-интерфейс. Когда вы пишете сетевой код, вы просто открываете сокет и пишите в него данные. Вам не надо заботится о типе сетевого оборудования пользователя и низлежащих протоколах.
* Изолирует запущенные программы друг от друга. Изолировать процессы платформо-независимым методом просто: Позволить процессам использовать только непривилегированные инструкции процессора. К сожалению, такой подход сделает невозможным любые операции ввода/вывода для программ, что делает все программы бессмысленными. Для снятия этого ограничения существует системный вызов — механизм, который позволяет запущенному процессу запрашивать ядро для совершения привилегированной операции от имени запрашивающего процесса. Обычные примеры — запись в файл (виртуальный диск), выделение памяти, или доступ к экрану или клавиатуре.
Механизм, который используется системным вызовом, платформо-зависим. На x86 платформе распространенным методом был вызов исключения, хотя новые процессоры от AMD и Intel предоставляют инструкции, позволяющие выполнить это еще быстрее. При этом управление переходит к ядру, которое решает, как интерпретировать значения в регистрах и на стеке, а также, какие действия предпринять.
Взгляд со стороны разработчика.
Важным стандартом при программировании для *NIX или в *NIX является единая спецификация UNIX — супермножество POSIX, которое включает всё, что должно быть в UNIX системе. Код, написанный согласно этому стандарту, переносим среди ряда UNIX-подобных систем.
Стандарт не описывает системные вызовы. Наоборот, он описывает Cи-функции, которые служат оберткой для системных вызовов. Когда программист хочет вызвать функцию open (), ему не надо знать, что он поместит указатель в EBX и значение 2 в EAX, а затем вызовет прерывание 80h; стандартная библиотека Cи реализует все эти функции. Любая нетривиальная программа на Linux будет обращаться к библиотеке Си (libc, для краткости). Существует несколько вариантов реализации стандартной библиотеки Си. У каждого члена семейства BSD есть своя реализация, впрочем как и у любой коммерческой UNIX системы. Какой вариант стандартной библиотеки С используется в Linux зависит от использования; существует несколько версий для встроенных систем, но большинство декстоп дистрибутивов Linux используют GNU libc.
По количеству кода ядро и libc практически равны. На двоих они предоставляют интерфейс разработчика к системе. Поскольку стандарт определяет только Cи-интерфейсы, а не системные вызовы, то и большинство кода написано с использованием стандартной библиотеки Cи. Это правило справедливо и для других языков; если вы, к примеру, запускаете некий java или python код, то он будет получать доступ к ядру через библиотеку Cи. Для некоторых языков существует своя стандартная библиотека от GNU Project. Например, любой С++ код будет использовать GNU libstc++ на GNU/Linux платформах. Некоторые дистрибутивы также включают GNU-реализации для Java библиотек, хотя такая практика уже не так популярна, учитывая, что Sun-версии стали open source. Даже если вы используете Sun Java библиотеки, вы по-прежнему используете GNU libc на этих платформах для любого Java приложения.
C C++ нюансов еще больше, чем с другими языками. Когда вы линкуете два модуля (к примеру, исполняемый файл и библиотеку), то сразу несколько стандартов описывают модель взаимодействия этих двух модулей. При вызове функции из другого модуля необходимо явно определить порядок аргументов на стеке и в регистрах, кто очистит память впоследствии и так далее. В С++ много чего должно быть явно определено для использования классов в различных модулях. Этот набор стандартов называется Бинарный Интерфейс Приложений (Application Binary Interface, ABI). В Linux, С++ ABI определен в GCC, который является пакетом GNU, как упоминалось ранее. Скомпилированный С++ код, независимо от того, какой компилятор использовался, должен подчиняться стандартам GNU, в противном случае такой код не сможет быть повторно использован другим С++ кодом.
Загрузка системы.
Современные GNU/Linux дистрибутивы начинают процесс загрузки с GRUB (GRand Unified Bootloader), который также является частью проекта GNU. (Хотя, технически, загрузка начинается в BIOS или другой прошивке, и это применимо для всех систем, которые запускаются на аппаратной платформе.) GRUB не создавался специально для Linux. Он может запускать и другие ОС и является стандартом для запуска некоторых систем на архитектуре x86, включая OpenSolaris и гипервизор Xen.
Затем GRUB передает управление ядру, которое продолжает инициализировать систему и конфигурирование драйверов. Ядро в свою очередь передает управление процессу init. Этот процесс отвечает за создание других процессов.
На Linux системах, init это очень маленькая программа, которая делает нечто большее, чем просто запуск скрипта. В некоторых дистрибутивах init заменен на Upstart, программу, которая не является ни частью Linux, ни частью GNU, и имеющая более сложную управляемую событиями модель. Скрипты, запущенный init’ом или Upstart’ом — это просто набор команд, интерпретируемых командной оболочкой (shell).
Спецификация POSIX содержит описание минимальной функциональности оболочки. Если вы хотите писать портативные shell-скрипты, то можете оставаться в рамках данной ограниченной функциональности, и, в итоге, получите скрипты, которые будут идти на всех UNIX-подобных системах.
Однако, большинство init скриптов не портируемы. Они используют расширенную функциональность командной оболочки, присутствующей в большинстве Linux дистрибутивов — Bash, командная оболочка от GNU.
Что в стандарте?
Единая Спецификация UNIX содержит намного больше, чем просто набор Cи-функций. В частности, стандарт определяет набор пользовательских утилит, которые обязаны присутствовать в UNIX-подобных системах. Многие программы используют эти утилиты через shell-скрипты или другие вызовы. Большинство из них содержатся в пакете корневых утилит GNU. Опять-таки, сравнивая количество строк кода, размер корневых утилит сравним с размером ядра.
Можно предположить, что эти утилиты не столь важная часть системы, однако это не так. Без утилит большинство init скриптов просто не запустятся (даже при наличии Bash), а система будет непригодна к использованию. Большинство инсталляторов также не запустятся, а это значит, что вы не сможете установить ни одной программы. Даже базовая функциональность, такая как копирование файлов использует корневые утилиты.
Единая UNIX Спецификация предоставляет список из 175 программ, которые должны присутствовать в каждой UNIX системе. Большинство из которых (с некоторыми исключениями, типа vi) созданы GNU и присутствуют в большинстве Linux дистрибутивов. Часть из них никогда не используются обычными пользователями; к примеру, стандарт предписывает наличие c99 и fort77 утилит для компилирования программ написанных на C и Fortran (обе утилиты предоставляются GNU).
На что еще следует обратить внимание?
Ранее я говорил, что у ядра две роли. Главная роль в предоставлении программам пользователя доступ к аппаратной части. Поэтому большинство Linux кода (и кода большинства других ядер) состоит из драйверов устройств. Но, отдельно стоит упомянуть о графике.
Старая модель драйвера XFree86 слабо зависела от ядра. Х-сервер запускался как привилегированный процесс и получал прямой доступ к аппаратной части. Я сам видел живой пример этого при попытке использования бинарного Linux драйвера Matrox под FreeBSD. Хоть драйвер и был написан для Linux, он прекрасно встал на FreeBSD, т.к. он напрямую взаимодействовал с Х-сервером и железом, а вовсе не с ядром FreeBSD.
Новые драйвера используют Инфраструктуру прямого рендеринга (Direct Rendering Infrastructure (DRI)). Эта система состоит из двух компонентов, называемых DRI и DRM. DRI — это драйвер пользовательского окружения, который снабжает командами аппаратную часть и предоставляет API другим пользовательским программам. DRM, в свою очередь, является маленьким модулем ядра, который проверяет команды и передает их аппаратной части.
Часто при холиварах на тему «готов ли Linux для десктопа» люди спрашивают, а как хорошо работает 3D в Linux? Вообще-то, обработка 3D это не задача Linux на большинстве системах. Linux всего-лишь предоставляет прямой интерфейс к аппаратной части, а уже X.Org пишет драйвера. Эти же драйвера могут быть запущены на FreeBSD, OpenBSD и еще ряде систем. В мире GNU/Linux систем Linux не занимается разработкой драйверов для одной из сложнейших частей аппаратной составляющей современного дектопа/лэптопа.
С изобретением FUSE, которая также работает на FreeBSD, NetBSD, and Mac OS X, ядро часто перестает предоставлять все драйвера для файловых систем, что еще больше умаляет роль «Linux» в системе.
Удаление GNU или Linux.
Возможно самый правдивый тест на важность того или иного компонента системы состоит в том, насколько просто обойтись без данного компонента в системе. Некоторые Linux платформы используют не так много GNU программ; например использование busybox для утилит командной строки и uclibc для стандартной библиотеки. Часть GNU платформ, такие как Nexenta или Debian GNU/kFreeBSD не используют ядро Linux.
Чтобы оценить важность Linux, давайте взглянем на Linux совместимое окружение в FreeBSD. При запуске Linux программ на FreeBSD, происходит установка модифицированного обработчика системного вызова, который вызывает функции ядра FreeBSD, в ответ на системные вызовы Linux. Этот поход позволяет запускать программы, написанные под Linux, без их изменения.
Для того чтобы данный метод работал, часто устанавливают урезанную версию Linux в отдельном окружении. Программы написанные под Linux в итоге смогут найти все необходимые библиотеки и утилиты, включая GNU утилиты, GNU grep, Bash и другие пакеты.
О чем это говорит? Это говорит о том, что если вы хотите запустить GNU/Linux программу на другой системе, то это легко выполнимо без Linux, а вот без GNU обойтись не так-то просто.
Безусловно, большинство программ успешно запустятся без всяких режимом совместимости, если вы их перекомпилируете. В этом случае они не будут использовать GNU libc, GNU утилиты или bash. Некоторые программы для успешной компиляции требуют GNU компилятор или GNU Make, однако, после компиляции эти программы больше не потребуют никаких GNU утилит, кроме:
Так что удаление GNU из GNU/Linux видится намного более сложным, нежели удаление Linux. PC-BSD или Nexenta — это хорошие десктопные ОС без капли Linux кода внутри, но с большим количеством GNU кода. Те Linux системы, которые не так сильно зависят от GNU кода — это сплошь интегрированные системы, названия которых не знакомы пользователям десктопных и серверных вариантов Linux.
Так как же стоит говорить, Linux, GNU или GNU/Linux? Я называю GNU, потому что, как программист и пользователь, я пользуюсь, в большинстве своем, теми инструментами, которые разработаны GNU. Когда я портирую код из FreeBSD, проблемы возникают только в корневых утилитах или в стандартной библиотеке Си. Если бы я хотел запустить этот же код на HURD или любой другой GNU системе, то я бы использовал те же самые интерфейсы.
История создания Ubuntu
История Ubuntu берёт своё начало в апреле 2004-го. Но прежде чем рассказать о самой Ubuntu, стоит упомянуть о некоторых ключевых фигурах и событиях, которые предшествовали её появлению.
Марк Шаттлворт
Ни одна история Ubuntu не может быть полной без истории своего основателя — Марка Шаттлворта.
Марк Шаттлворт родился в 1973-м году, в городе Велком провинции Фри-Стейт, ЮАР. Он посещал авторитетный колледж Diocesan и получил докторскую степень в области финансов и информационных систем в Университете Кэйп-Тауна. В этот период, Марк был страстно увлечён компьютером и стал активным участником сообщества Open Source. По крайней мере косвенно, он принимал участие в проектах Apache и Debian, и был первым человеком, который загрузил веб-сервер Apache, вероятно наиболее важное серверное приложение для платформы GNU/Linux, в архивы проекта Debian.
Увидев возможности и потенциал интернета, Шаттлворт основал в своём гараже центр сертификации и компанию по интернет-безопасности, названную Thawte. За несколько лет он вырастил Thawte во второй по величине центр сертификации во всём интернете, уступив лишь киту безопасности — компании Verisign. К слову, продукты и сервисы Thawte были построены и обслуживались свободным программным обеспечением. В декабре 1999-го, Шаттлворт продал Thawte компании Verisign за сумму, которая не разглашается, но которая, по слухам, составила порядка нескольких сотен миллионов американских долларов.
С такой фортуной в молодом возрасте, Шаттлворт мог бы наслаждаться безбедной жизнью. Но вместо этого, он решил реализовать свою заветную мечту — отправиться в космическое путешествие. После оплаты порядка 20 миллионов долларов русской космической программе и посвятив около года на подготовку, включая изучение русского языка и тренировки в Звёздном городке, Шаттлворт реализовал мечту в качестве гражданского космонавта на борту русского Союза TM-34. Шаттлворт провёл 2 дня в ракете Союз и 8 дней на Международной Космической Станции, где принимал участие в экспериментах, посвящённых изучению СПИДа и генома. В начале мая 2002-го, Марк Шаттлворт вернулся на Землю.
В дополнение к исследованию космоса и увеселительной поездке в Антарктику, Шаттлворт играл активную роль как филантроп и венчурный капиталист. В 2001-м, Шаттлворт основал Фонд Шаттлворта (Shuttleworth Foundation, TSF), некоммерческую организацию, расположенную в Южной Африке. Фонд был основан для финансирования, разработки и внедрения инноваций в области образования. Разумеется, в качестве средств, с помощью которых TSF пытался достичь своих целей, применялось и свободное программное обеспечение. В рамках этих проектов, организация стала одним из самых видных сторонников СПО в Южной Африке и вообще в мире. В области венчурного капитала, Шаттлворт оказывал содействие научным исследованиям, разработкам и предпринимательству в Южной Африке со стратегическими инъекциями денежных средств в стартапы через новую фирму венчурного капитала, названную HBD, что означает «Here Be Dragons» («Тут Драконы»). В этот период, Шаттлворт был занят мозговыми штурмами для своего следующего крупного проекта, который в конечном счёте станет Ubuntu.
Никакого недостатка в проектах, которые пытались объединить GNU, Linux и другие кусочки открытого и свободного ПО в аккуратную, работоспособную и дружелюбную к пользователю оболочку, не было. Марк Шаттлворт, как и большинство других людей, верил в то, что философские и прагматичные выгоды от использования свободного программного обеспечения определят курс дальнейшего успеха. Тем не менее, ни одно существовавшее предложение не было особо впечатляющим. Чего-то недоставало в каждом из них. Шаттлворт увидел в этом перспективу.
Шаттлворт, как и множество других технарей, был большим фанатом проекта Debian. Однако, существовало множество вещей в Debian, которые не совпадали с его виденьем идеальной ОС. Некоторое время Шаттлворт рассматривал возможность стать лидером проекта Debian для реформирования проекта изнутри. Чуть позже стало ясно, что лучшее решение не состоит в том, чтобы работать внутри проекта Debian, который во многих ситуациях имел веские причины оставаться на том пути, по которому он развивался. Вместо этого, Марк решил построить новый проект, который бы работал в симбиозе с Debian, для создания новой, лучшей системы GNU/Linux.
Что означает «Ubuntu»?
«Бородавочники», как они сами себя называли, были отличной командой, имели набор чётких целей и идеи о том, как достичь большинства из них. С другой стороны, у команды не было названия для своего проекта. Шаттлворт сильно настаивал на том, чтобы назвать проект «Ubuntu».
Ubuntu — это концепция и термин из нескольких южноафриканских языков, включая зулу и коса. Определение «ubuntu» сложно перевести на русский, но в общих чертах это означает «человечность по отношению к другим» или «я есть, потому-что мы есть». Некоторые описывают ubuntu как «вера во вселенскую силу, которая связывает всё человечество ».
Ubuntu оказалось термином, который ёмко выражал откуда пришёл проект, куда он идёт и каким образом планирует это сделать. Название было идеальным и оно окончательно закрепилось.
Создание Canonical
Чтобы платить основным разработчикам за работу над Ubuntu, Шаттлворту понадобилось создать компанию. Он хотел собрать некоторых лучших людей для работы с глобальными opensource-сообществами. Эти сообщества не знают национальных и географических границ. Вместо того, чтобы перемещать каждого работника в какое-то одно место или офис, Шаттлворт принял решение объединить их в «виртуальную компанию». Хотя у такого решения были очевидные недостатки в виде большой задержки и низкой пропускной способности соединений, разных временных зон и многого другого, это также сулило выгоду в конкретном контексте проекта. Распределённая природа сотрудников означала, что новая компания может нанимать лиц, не требуя их переезда в новую страну. Каждый сотрудник компании мог использовать IRC, почтовую рассылку и разнообразные онлайн-коммуникации для того, чтобы делать свою работу. В первый год существования, самое похожее на офис было личной квартирой Шаттлворта в Лондоне.
Со временем, компания разрослась и получила название Canonical. Название было данью оптимистическим прогнозам — стать каноническим местом поддержки свободного программного обеспечения, Ubuntu в частности. И это также распространённое слово в сленге программистов. Важно заметить, что в отличие от монополии, быть каноническим не означает эксклюзивное право на что-либо. Другие компании будут поддерживать Ubuntu и разрабатывать операционные системы на её основе. Но пока Canonical делает хорошую работу, её роль будет оставаться центральной.