Свободные программы и системы в школе
Добавить в закладки К обложке
- Введение. Зачем программам быть свободными? - Страница 1
- 0.1 Право и экономика ПО - Страница 2
- 0.2 Применимость СПО при реализации «Обязательного минимума...» - Страница 3
- 0.3 Логика и последовательность освоения СПО - Страница 4
- Глава 1. Краткое введение в открытые ОС - Страница 5
- 1.1 Операционные системы - Страница 6
- 1.2 Практическая интеграция - Страница 9
- 1.3 Почему командная строка? - Страница 16
- 1.4 Сеанс работы и команды - Страница 18
- 1.5 Файлы и файловые структуры - Страница 22
- 1.6 Процессы - Страница 31
- 1.7 Переменные - Страница 35
- 1.8 Конвейер - Страница 38
- 1.9 Элементы обработки текста - Страница 40
- 1.10 Элементы программирования оболочки - Страница 45
- 1.11 Справочник по наиболее употребительным стандартным командам ОС - Страница 50
- 1.12 Перечень стандартных команд ОС - Страница 56
- Глава 2. Графический пользовательский интерфейс - Страница 60
- 2.1 Оконная система «Икс» и XFree86 - Страница 61
- 2.2 Цветной сэндвич - Страница 62
- 2.3 «Чистая» «Икс» - Страница 63
- 2.4 Окноводы - Страница 64
- 2.5 Столоначальники - Страница 65
- 2.6 Триумф интерфейса над пользователем? - Страница 66
- 2.7 От какого наследства нам не стоит отказываться? - Страница 67
- 2.8 Зачем нужны «легкие» среды? - Страница 68
- 2.9 Базовая функциональность оконного менеджера - Страница 69
- 2.10 «Виджеты» - Страница 70
- 2.11 Расширенная функциональность оконного менеджера - Страница 71
- 2.12 Оконные менеджеры «BlackBox» и «FluxBox» - Страница 72
- 2.13 Оконный менеджер «WindowMaker» - Страница 73
- 2.14 Оконный менеджер «IceWM» - Страница 74
- 2.15 Интегрированные графические среды - Страница 75
- 2.16 Плюсы и минусы интегрированных сред - Страница 76
- 2.17 Общие черты интегрированных сред - Страница 77
- 2.18 «Гном» (Модельная среда сетевых объектов GNU) - Страница 78
- 2.19 «КДЕ» (Настольная среда K) - Страница 80
- Глава 3. Пакет «Мозилла» - Страница 81
- 3.1 Базовая функциональность «Мозилла»66 - Страница 82
- 3.2 «Мозилла»: как это сделано - Страница 84
- Глава 4. «Открытый Офис» - Страница 85
- 4.1 Словарный процессор «OpenWriter» - Страница 86
- 4.2 Редактор электронных таблиц «OpenCalc» - Страница 90
- 4.3 Редактор векторной графики «OpenDraw» - Страница 93
- Глава 5. Редактор растровой графики «ГИМП» - Страница 97
- 5.2 Источники и параметры и форматы представления растровой графики - Страница 98
- 5.3 Общие сведения о «ГИМП» - Страница 99
- 5.4 «ГИМП» – программируемый графический редактор - Страница 100
- 5.5 Фильтрация и синтез изображений - Страница 102
Информационная и ценовая политика разработчика. При прочих равных, преимущественно стоит входить в отношения с поставщиком, придерживающимся полной прозрачности разработки дистрибутивов. Технически это означает свободный доступ (на чтение) к дереву разработки через cvs или ftp или, по крайней мере, простую регистрационную процедуру для получения такого доступа. Разработчики, закрывающие процесс и лишь периодически сбрасывающие его результаты в релизы, скорее всего, готовят сюрпризы своим пользователям, и редко такие сюрпризы оказываются приятными
Цена изданий на дисках обычно не играет большого значения (поскольку приобретается один-два комплекта на десятки компьютеров) и варьирует незначительно из-за конкуренции между промышленно тиражированными дистрибутивами и альтернативой самостоятельного переписывания с одолженных дисков или через Интернет. Цена «компактного» (один-три диска плюс брошюрка) дистрибутива в России – порядка 200-300 р., «обширного» (шесть-десять CD плюс несколько томов документации) – от одной до трех тыс. р. Публикация дистрибутивов на DVD, возможно, уничтожит феномен «компактного» малодискового дистрибутива и приведет к дальнейшему снижению цен12.
Альтернативным способом получения дистрибутива является его полная или попакетная загрузка через Сеть (на сайтах разработчиков практически всегда они есть), что может оказаться дороже, но оперативнее приобретения дисков. Чаще всего пользователи сочетают приобретение комплектов дисков по мере выхода очередных релизов и загрузку по Сети исправлений и обновлений в периоды между релизами.
Технические параметры дистрибутивов.
Бинарная установка или установка из исходников? В сообществе «БСД» в качестве штатной процедуры установки принято «портирование», т.е. автоматизированная компиляция и сборка пакетов для целевой машины из исходников. В сообществе «ГНУ/Линукс» в качестве штатной процедуры установки принята распаковка бинарных (прекомпилированных) пакетов, и до недавнего времени (появления так называемых source-based дистрибутивов) все дистрибутивы технически поддерживали именно этот способ установки (хотя, разумеется, администратор мог и пересобрать любой пакет).
Преимущество установки из исходников – оптимизация под конкретную машину и меньший объем пакетов. Преимущество бинарной установки – более высокая ее скорость. Следует иметь в виду, что сборка некоторых пакетов на компьютере персонального класса может длиться более десяти часов, и пересборка всех часто использующихся программ может занять несколько суток.
Программа установки, управление пакетами и утилиты настройки. Как уже замечено, большинство дистрибутивов «ГНУ/Линукс», включая самые популярные, предусматривают установку с первоначальной настройкой и обновление с использованием прекомпилированных программ, собранных в пакеты. Пакет, который может включать одну или более программ, файлы конфигурации, документацию и т.п. является минимальной единицей установки или обновления штатными для дистрибутива средствами. В отдельные пакеты составителями собираются также исходные коды, соответствующие прекомпилированному пакету. Процедуры установки, удаления, обновления пакетов называются управлением пакетами.
Стандарта на пакетирование и управление пакетами не существует. Распространение получили три формата пакетов: rpm (впервые появившийся в дистрибутиве RedHat и применяемый сегодня большинством составителей дистрибутивов), deb (применяемый Debian) и tgz (применяемый Slackware). На формат пакета завязаны программа установки и управления пакетами («rpm» для rpm, «setup» для tgz и «dpkg» для deb), способная отслеживать зависимости между пакетами (ситуации, когда для нормальной работы программы из одного пакета требуется программа (возможно, определенная версия) из другого пакета, или, наоборот, когда программы из разных пакетов являются взаимоисключающими в рамках одной системы).
В последние годы развиваются усовершенствованные средства управления пакетами, позволяющие преодолевать некоторые ограничения, свойственные «rpm» и «dpkg» (в частности, отслеживать ситуацию смены имени (в отличие от номера версии) пакета). В качестве примеров таких средств можно назвать «apt» (дистрибутивы Debian, ALT Linux и Conectiva) и «yum» (дистрибутив ASPLinux).