Линукс — это Юникс? / Habr
Часть 1
В первой части истории о взаимоотношениях Линукса и Юникса вы узнаете о богатой истории Юникса, которая определяет, чем он является и кому принадлежит.
Линукс это Юникс?
Если вы задаетесь этим вопросом, значит вы находитесь в одном ряду с многочисленными Линукс и Юникс разработчиками, администраторами и пользователями. Каков приговор? Суд так и не может принять окончательное решение. С виду это простой вопрос, но задайте его 10 людям, и вы получите 10 разных ответов. Суть проблемы заключается в том, как каждый человек по-разному представляет эти понятия. Некоторые думают, что это наборы стандартов, другие, что это сообщества, третьи — вообще торговые марки. Откровенно говоря, Линукс и Юникс — это все эти вещи одновременно.
Многие пытаются использовать старый «утиный тест» при поиске ответа — «Если предмет выглядит как утка, плавает, как утка и крякает, как утка, то это, вероятнее всего, и есть утка». Несмотря на то, что пример с уткой вряд ли сопоставим со сложными системами, рассуждения в общем где-то созвучны. Линукс действительно напоминает Юникс почти в каждом аспекте. На самом деле, первоначальное ядро Линукс было построено по образцу Юникса, и даже его создатель(!) в свое время связывал ядро с Юниксом.
Означает ли это, что Линукс — это Юникс? Не обязательно. Если бы вас клонировали, был бы ваш клон вами? Многие бы поспорили, что то, что определяет какой-то предмет — это не только его состав, но и история. В случае с клоном, у него не было бы вашей памяти, так что он не был бы по-настоящему вами.
Краткая история Юникс
Развитие Юникс по-настоящему началось в 1960-х годах проектом под названием Multics, который не принес большой прибыли и был брошен одной из крупнейших компаний, вносившей основной вклад в его развитие. Тем не менее, работа над проектом была продолжена энтузиастами, что в конечном итоге привело к рождению UNICS (игра звучаний с «Multics», позже переименованной в UNIX) в 1970-х годах.
В 1980 году компанией AT&T был разработан пакет коммерческих лицензий на все дистрибутивы UNIX, и сведение всех версий в одну: UNIX System V. Университет Калифорнии, Беркли продолжал разрабатывать свою собственную версию Unix под названием BSD. Многие из важнейших разработок в UNIX изначально пришли из BSD, к примеру, включение TCP/IP в основную версию UNIX.
В течение 80-х и 90-х, многие компании приобрели и залицензировали свои собственные версии UNIX, в том числе Sun Microsystems, Microsoft, и SCO. Примерно в это же время группы разработчиков и компаний осуществили рывок в сторону «открытого» Юникса, создавая отдельную ветвь его развития. В начале 90-х, AT&T продала все свои права на UNIX компании Novell. В 1995 году уже Novell продает часть своих прав на Юникс, включая право на дальнейшую разработку, компаниям System V и SCO.
Все эти покупки, продажи, лицензирования, делицензирования и независимое развитие в 90-е привели к многочисленным искам, спорам, а также драмам по поводу владения частями Юникса. Линукс также фигурировал в иске SCO, как содержащий код Юникса, который принадлежал им. Когда все поутихло, Novell выиграла дело в отношении SCO, и заставила SCO отозвать иски против IBM и Sequent, а также Linux. Они даже пошли на то, что сказали «Мы не верим, что в Линуксе есть что-то от Юникс».
Сегодня ОС Solaris компании Sun Microsystems является крупнейшей Юниксовой операционной системой. BSD продолжает свое развитие и породил бесплатные версии, такие как FreeBSD. В 2005 году Sun опубликовала большинство кода OpenSolaris, что привело к еще большему количеству версий с открытым исходным кодом на основе Юникс.
Часть 2 — история Линукса
Во второй части этой серии вы узнаете о пути Линукса от скромного начала к славе и богатству!
Краткая история Linux
В 1991 году в Хельсинки, Финляндии, Линус Торвальдс начал работу над проектом, который был, по его словам, «просто для удовольствия». Этот проект в конечном счете стал ядром Linux. Он никогда не был предназначен для чего-то особенного, просто инструмент, который позволил бы студенту получить доступ к UNIX-серверам в соседнем университете. Он написал его специально для железа, на котором он работал на тот момент, и оно не зависело от операционной системы. Через некоторое время Линус понял, что то, что он нечаянно создал — и есть само ядро операционной системы. Торвальдс смоделировал его на основе разновидности UNIX под названием Minix. Код Minix был открытым, но изменения и дальнейшее распространение не были разрешены, поэтому ядро Торвальдса не защищалось авторским правом. Хотя оно было смоделировано по образу Юникса, оно не было Юниксом. После того как он осознал, что создал, он написал на Usenet:
«Привет всем, кто использует MINIX — Я делаю (бесплатную) операционную систему (просто хобби, это не будет большой и профессиональной системой, как GNU) для 386 (486) AT моделей. Я занимаюсь этим с апреля, и сейчас завершаю работу. Я бы хотел получить какие-либо отзывы о тех вещах, которые вам нравятся и не нравятся в MINIX, так как моя система несколько напоминает ее (то же физическое расположение файловой системы (из практических соображений) среди всего остального). „
Очевидно, в то время Торвальдс не понимал, насколько его ядро было важным для движения открытого программного обеспечения, которые постепенно начинало распространять свое влияние к тому времени. Фонд свободного ПО(Free Software Foundation), наиболее известный своим проектом GNU, начавшим развитие в 1983 году, искал ядро, чтобы осуществить свою мечту о “достаточном количестве свободного программного обеспечения, чтобы вообще можно было обходиться без какого-либо ПО, которое не свободно». Да, целью была полноценная операционная система плюс дополнительные программные средства с открытым исходным кодом и защищенные GPL. В 1992 году они обнаружили Linux, и GNU/Linux начала свой путь, который привел ее именно туда, где «существует достаточное количество свободного программного обеспечения, что можно обходиться без какого-либо ПО, которое не свободно».
В заключении …
Является ли Линукс Юниксом? Вы все еще не знаете? Я тоже, но по крайней мере теперь у вас есть факты. С этого момента, выбор позиции является исключительно вашим личным решением.
Внутреннее устройство Linux или как работает Linux
В течение года мы издали три книги по Linux, которые положительно приняли:
Linux. Установка, настройка, администрирование
Ubuntu и Debian Linux для продвинутых: более 1000 незаменимых команд. 2-е изд.
Linux. Системное программирование. 2-е изд.
Сейчас мы планируем сделать новую книгу и остановились на варианте — How Linux Works: What Every Superuser Should Know. Мы хотим узнать ваше мнение и принять решение делать ли книгу.
Небольшая рецензия на прошлое издание:
Эта книга познакомит вас с внутренней организацией операционной системы Linux. Если вы новичок (книга отлично написана даже для новичков), программист, системный администратор, обычный пользователь или исследователь — впрочем, если вы просто всегда интересуетесь, как именно работает та или иная штука, то это книга для вас. Например, я — программист, прочитал ее, чтобы лучше изучить Linux, так как ранее мое знакомство с этой системой ограничивалось чтением онлайновых руководств. Книга разделена на три части. В части 1 описываются общие принципы конструкции и функционирования Linux. Во второй части рассматриваются инструменты программирования, доступные в Linux. В третьей части собраны специализированные темы, в частности, разъясняется работа с ядром, печать и т.д.
Часть 2. Вторая часть начинается с вводного курса по написанию скриптов для командной оболочки (Shell scripting). Правда, следует вновь оговориться о целевой аудитории данной книги — далеко не все аспекты написания таких скриптов можно рассмотреть в столь небольшом пособии. Темы GCC и Make объяснены очень хорошо (в сущности, я разобрался в Make, только прочитав эту книгу). Более того, скрипты в этой книге пишутся на Python! Далее автор переходит к самой интересной (для некоторых, правда, самой несносной) теме в Linux – компилированию ядра. Работе с ядром посвящена целая глава, прочитав ее, я совершенно уверен, что смогу сам перекомпилировать мою систему.
Часть 3: Эту часть можно читать отдельно от всей книги. В ней рассматриваются специализированные темы, каждую из которых можно изучать независимо. Например, как настроить сетевой принтер? Как работать с CUPSd? Как пользоваться Ghostscript для преобразования Postscript в PDF? Ответы на все эти вопросы вы найдете здесь. Так, мне было просто необходимо научиться работать с файловой системой SAMBA. Моя домашняя сеть состоит из компьютеров с Windows, и мне периодически приходилось обращаться к тем или иным файлам, расположенным на них. Теперь все изменилось! Я без труда могу просматривать все домашние каталоги прямо с ноутбука, который подключается к сети по беспроводному соединению.
Пользователи часто сетуют, что в Linux возникает множество багов при работе с аппаратным обеспечением. В этой книге есть целая глава, рассказывающая, как покупать оборудование, совместимое с Linux. Этот материал очень вам пригодится, особенно если вы стараетесь оснастить свой компьютер по последнему слову техники. Кроме того, эта глава очень поможет системным администраторам, занятым обслуживанием больших корпоративных сетей.
Итак, я рекомендую эту книгу всем читателям, которых интересует внутренняя организация Linux. Вы найдете ответы на все интересующие вас вопросы и отлично освоите все механизмы Linux. Конечно, после ее прочтения вы не станете экспертом по Linux, но она поможет вам ответить на многие вопросы «как»? и «почему»? В дальнейшем она послужит вам солидным базисом для профессионального роста в области Linux.
GNU или Linux? / Habr
Просматривая статьи для перевода на 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 libstdc++.
- программ, явно использующих одну из многих GNU библиотек.
Так что удаление GNU из GNU/Linux видится намного более сложным, нежели удаление Linux. PC-BSD или Nexenta — это хорошие десктопные ОС без капли Linux кода внутри, но с большим количеством GNU кода. Те Linux системы, которые не так сильно зависят от GNU кода — это сплошь интегрированные системы, названия которых не знакомы пользователям десктопных и серверных вариантов Linux.
Так как же стоит говорить, Linux, GNU или GNU/Linux? Я называю GNU, потому что, как программист и пользователь, я пользуюсь, в большинстве своем, теми инструментами, которые разработаны GNU. Когда я портирую код из FreeBSD, проблемы возникают только в корневых утилитах или в стандартной библиотеке Си. Если бы я хотел запустить этот же код на HURD или любой другой GNU системе, то я бы использовал те же самые интерфейсы.
В общем, я предпочитаю выделять дистрибутивы, типа Fedora или Ubuntu, и не упомянать GNU или Linux. Система включает в себя огромное количество кода из различных источников. Среди самых больших поставщиков кода фигурируют Проект GNU и X.org, но Ubuntu GNOME/X.Org/GNU/Linux звучит слегка длинновато. А включая в названия системы такую небольшую и без проблем удаляемую часть, как Linux, поступают несправедливо по отношению к множеству разработчиков, чей код также присутствует в системе.
— translated.by/you/gnu-or-linux/into-ru/trans
Оригинал (английский): GNU or Linux? (http://www.informit.com/articles/article.aspx? p=1339466)
Как я внедрял Linux в учебном заведении / Habr
Описываемый проект внедрён и используется уже лет пять. Пришло время рассказать, как всё было и поделиться опытом.
Давным-давно работал я техником (что-то вроде лаборанта, но более узкоспециализировано) в одном из учебных заведений среднего профессионального образования нашей необъятной родины. Смотрел, как проходят занятия, видел, как неаккуратно обращаются с хрупким программным обеспечением студенты и преподаватели, участвовал в массовых рутинных операциях, таких как: «переустановить некую самую популярную ОС на 30 и более разных компьютеров», «ой, нам для нужд учебного процесса срочно нужно поставить вот этот программный пакет, но аудиторию ещё не знаем» и далее в таком же духе.
Был я не совсем доволен положением вещей. Казалось мне, что всё должно быть проще, легче, изящней и вообще работать чуть ли не само (знакомое чувство?). В итоге взрывоопасная смесь из юношеского максимализма, студенческой неопытности и желания изменить мир сотворили в моей голове «идеальную» картину, как оно всё-таки должно быть.
Под катом много текста c картинками, технические подробности, одна тяжелая гифка и 6-ти минутная видео презентация.
А идея была проста, ставлю везде дистрибутив Linux, ведь все знают, что они (линуксы) безопасны, красивы и вирусов там нет. Пишу небольшой велопарк, для автоматизации рутины… Профит!
На самом деле, к тому времени с Linux и открытым ПО я был знаком достаточно хорошо и вполне осознавал отсутствие привычных программ для преподавателей и/или учебных материалов по открытым аналогам. Насколько мне было известно, об эти проблемы разбились многие внедрения. Но я все продумал! Надо было только сесть, быстренько всё написать и настало бы всеобщее счастье. Неужели такие мелочи, как человеческие привычки и нежелание учиться чему-то новому могут остановить дотошного студента? В общем-то, они могли бы остановить, но начальство было благосклонно к моему энтузиазму, за что ему большое спасибо. Пока я копошился с написанием своих велосипедов, о которых ниже, в нашей стране в сфере образования стали усиленно бороться с нелегальным ПО. Тут мои идеи пришлись кстати.
Помимо чисто эгоистического «облегчить работу себе», я искренне желал сделать обучение в компьютерных классах проще и плодотворнее как для студентов, так и для преподавателей. Простая замена «самой популярной ОС» на дистрибутив Linux, с моей точки зрения, — это «шило на мыло». Такой переход упрощает жизнь бухгалтерам и юристам, а обслуживающий персонал как бегал от компьютера к компьютеру, так и продолжит бегать (ну, может чуть меньше). Собственно, вот список проблем, которые я вознамерился решить. И решил.
ПО в компьютерных классах требует обслуживания. Его надо устанавливать и обновлять на многих машинах
Могу поставить одну программку на один компьютер, на два — уже не могу: однообразная работа меня пугает. Тут очень кстати пригодилась пакетная система установки. Собрал пакет, положил в репозиторий, на компьютерах прописал обновление при загрузке. Репозиторий от Ubuntu скачал целиком и разместил в локальной сети. Часть пакетов заменил, часть добавил. Написал несколько скриптов для сборки пакетов и копирования обновлённого репозитория на сервер.
Теперь, если нужно обновить ПО, достаточно кинуть пакет в репозиторий и перезагрузить компьютеры.
Красивый, лёгкий внешний вид без возможности его поменять
Студенты любят проявить свою индивидуальность и подкрутить внешний вид общественных компьютеров под себя. Иногда у них это получается не совсем политкорректно, тогда преподаватели прибегают в панике, ведь через политики псевдобезопасности «самой популярной ОС» заблокировано меню для смены обоев. Это обстоятельство ничуть не пугает студентов, они ведь в курсе, какую картинку надо заменить… И далее в том же духе. Фантазия молодого поколения и стремление «выделиться» не знает преград. То есть не знала.
Будучи фанатом KDE, я бы с удовольствием поделился радостью использования этой чудесной среды, но здесь легендарная KDE-шная настраеваемость как раз совсем не нужна, поэтому выбор пал на оконный менеджер OpenBox и pypanel. И почти всё. Вот такой минимализм. Поработала такая связка и выяснилось, что c OpenBox не дружит Lazarus (клон Delphi) и некоторые программы из-под wine.
Итоговый вариант, работающий по сей день, был постороен на оконном менеджере KWIn и панели tint2. KWin умеет рисовать и «современные красивости» через OpenGL, и «по старинке» без проблем работать на старом железе, которое на тот момент имело место быть.
Внимательный читатель уже заметил недостающий компонент в этом «рабочем столе-описании» — собственно рабочий стол, на котором рисуются иконки. Вот и велосипед номер один. «Рабочий стол» я написал сам. Были у меня к этому компоненту специфичные требования, да и писать его просто. Нужно только правильные X11 флаги назначить окну, а флаги эти быстро смотрятся в реализации KDE-шного рабочего стола (вот она, сила open source!). Мой рабочий стол должен был быть предельно простым: уметь отображать .desktop-файлы (аналог .lnk в Windows, только текстовый) из конкретной папки и показывать «нескучные обои» из конкретного файла. Вот только запускать программы он должен был не самостоятельно, а по DBUS (это такой IPC) через «клиента для управления», о котором ниже. Последняя версия рабочего стола была переписана с использованием QML, и стало всё совсем весело и анимировано.
Безопасность и здоровье всем компьютерам!
Многие студенты и преподаватели относятся к этим понятиям по принципу «не моё — не жалко». Такое отношение пользователей крайне расстраивает обслуживающий персонал. Я подумал немного и сделал из студенческих машин «терминалы», возвращающиеся к своему исходному состоянию при смене пользователя или перезагрузке. Сделано это было обычным скриптом на баше, зачищающем home и tmp. Просто и эффективно.
Свои данные везде или наше персональное облако
Если просто стирать все студенческие наработки и заставлять их делать каждый раз всё заново… Это было бы круто! Наверное, скорость и качество их работ сильно возросли бы, и уже ко второму курсу они могли бы… Но этому плану по улучшению качества образования не суждено было сбыться. Отчасти потому, что мне хотелось поиграть с FUSE и написать свою кеширующую файловую систему. Написал. Некоторое время она поработала, но потом мне надоело с ней возиться. На баше набросал скрипт, который при выходе пользователя избирательно сжимает файлы из домашнего каталога и бросает на сервер через rsync, а при входе загружает и распаковывает. Побочный эффект: студенты больше не привязаны к конкретным компьютерам и аудиториям. Ура!
Хотим указывать, какое ПО можно использовать
Пользователи в основной своей массе юридически безграмотны. Объяснить, что ряд программ нельзя использовать в учебном процессе, не заплатив крупную сумму, очень сложно, так ещё и ряд этот периодически пополняется без ведома сотрудников, ответственных за вопросы легальности установленных программ.
Для начала я подошёл к решению этого вопроса классически: работать все будут из-под ограниченного аккаунта. Именно все, как студенты, так и преподаватели из-под одного обычного аккаунта, заведенного на всех машинах. Это, а также самоудаляющиеся данные, да и сам по себе Linux делают установку стороннего неодобренного софта затруднительной.
Кнуты без пряников внедрению не подлежат
Ограничить теперь можно всё и вся и почувствовать себя настоящим злодеем. Но такой задачи не стояло, поэтому нужно было сделать что-то приятное… Сначала преподавателям и учебному процессу. Ради этой благой цели я написал «Панель управления» компьютерным классом. Зачем писать своё, когда уже есть неплохие и даже открытые решения? Мне хотелось веб-интерфейс. Ведь так здорово зайти с любого компьютера (смартфона, планшета) и порулить компьютерным классом. И преподаватель не привязан к конкретной машине.
«Панель управления» — это сервер, принимающий команду с веб-интерфейса и пересылающий всем выделенным компьютерам. HTTP- и сетевой IPC-сервер я объединил в одной программе (сейчас я бы так не делал, совсем не масшабируется) ради удобства обработки событий и общей памяти.
Клиент для упомянутого сервера я установил на все машины под управлением Linux. Клиент подключается к серверу при включении компьютера и ждёт команд. Большинство команд просто запускают bash-скрипты.
Концентрация внимания студентов
Функционал «Панели управления» расширялся постепенно. Но первой и, пожалуй, главной «фичей» было разрешение на использование программ. Выглядит это так: студенты садятся за компьютеры, вводят свои логины и пароли и видят пустой рабочий стол. Преподаватель садится за компьютер, вводит свой логин и пароль и видит на рабочем столе иконку «Панели управления». При нажатии на иконку открывается браузер со страницей «Панели управления». На этой странице из списка установкой галочек выбираются программы, которые нужны преподавателю для занятия. Иконки выбранных преподавателем программ появляются на рабочих столах студентов. Теперь студенты могут запустить программы, щелкнув по иконкам, или сам преподаватель может со своего компьютера запустить нужные программы на всех или на выделенных компьютерах студентов.
Работает эта магия следующим образом. Сервер посылает клиентам команду «установить application_name». Клиент, получив команду, скачивает с HTTP-сервера файл «application_name.desktop». В этом файле к стандартным полям я добавил ещё несколько, в которых перечислены пакеты для установки, основные файлы и директории приложения и т. д.
Когда desktop-файл загрузится, клиент попытается установить перечисленные в нём пакеты и задать права на чтение/запуск указанным файлам приложения. Если преподаватель решает, что хватит студентам работать с какой-то из разрешенных программ, он снимает галочку в «Панели управления». Клиентам приходит команда «удалить application_name», программа закрывается, desktop-файл удаляется, с указанных файлов снимаются разрешения на чтение и выполнение. Установленные пакеты остаются нетронутыми. Переустанавливать каждый раз слишком накладно.
Пока программа ставится и настраивается, на рабочем столе весело подпрыгивает полупрозрачная иконка приложения.
Когда выходит новая интересная программка, я кидаю пакет в репозиторий, а на сервер desktop-файл, и в «Панели управления» появляется программа, доступная для выбора преподавателем.
Наблюдение за работой
Студенческие машины раз в несколько секунд посылают на сервер уменьшенный скриншот рабочего стола. Эта картинка демонстрируется преподавателю в «Панели управления». Но этого мало. Все конкурентные решения умеют смотреть и управлять удаленным рабочим столом. А чем я хуже?
Тут возникла ещё одна «хотелка»: режим показа одного рабочего стола всему классу. Была такая задача и подумал, что неплохо бы встроить и этот функционал. Обычный x11vnc из поставки Ubuntu сильно тормозил при подключении 25 экранов, да и при 10 было уже некомфортно. Спас положение TurboVNC, который показал приемлемую производительность. На «Панель управления» добавил ещё две кнопки: «Посмотреть рабочий стол (и поуправлять)» и «Показать выделенный всем». При нажатии идёт команда на сервер «Покажи компьютер X компьютерам Y1..Yn», а сервер уже указывает, кому запустить VNC-сервер, а кому — просмотрщики, панель управления ведь обычная web-страница и напрямую общаться с другими компьютерами ей сложно.
Ограничение Интернета
Когда студенты видят браузер, мысли об учёбе покидают и во вкладках обосновываются социальные сети и прочие не связанные с обучением ресурсы развлекательного характера. Ну и ладно, вернемся к диктаторским мерам и введём белые списки. Только пусть управляют ими преподаватели. Хотят, пусть всё разрешают, а надо, так указывают разрешенные адреса. Добавил ещё одну кнопку в «Панель управления». По нажатии открывается диалог, куда можно добавить URL.
Эти сайты сохраняются в профиле преподавателя, и доступны в списке программ, откуда легко назначаются студентам, установкой галочки. При назначении URL выделенным компьютерам приходит команда: добавить в список разрешённых указанный адрес и перенастроить установленный на каждой машине tiniproxy.
Структура WWW сейчас такова, что разрешенный сайт X скорее всего тянет скрипты, стили и картинки с других неразрешенных ресурсов, и страницы выглядят грустно или работают некорректно. Поэтому. когда приходит команда «добавить разрешенный URL», сайт скачивается, парсится, из него вынимаются ссылки на скрипты, стили и картинки и добавляются в разрешённые. Cрабатывает не всегда корректно, но это лучше чем ничего.
Еще некоторым приложениям нужен доступ к определенным сайтам для корректной работы. Для таких случаев в desktop-файл я добавил параметр с перечислением сайтов. Когда преподаватель выбирает приложение, указанные для него сайты автоматически разрешаются. Если нужно разрешить всем или некоторым студентам полный доступ, преподаватель выбирает в списке «Полный доступ в Интернет» и ограничения снимаются.
Изучение операционных систем или виртуальные машины
Поначалу, когда все это затевал, я успокаивал преподавателей наличием «самой популярной ОС XP» в виртуальной машине. Забегая вперёд, скажу, что больше эта опция недоступна и у нас плавно, не без стрессов, но сформировалась среда исключительно из свободного ПО (в нескольких компьютерных классах).
Возвращаясь к визуализации, я выбрал VirtualBox и реализовал управление виртуальными машинами в духе всей системы — делаю один раз и тиражирую для всех. В «Панели управления» в разделе с приложениями теперь перечисленны и FreeDOS (не спрашивайте зачем), и ReactOS, и тот же Ubuntu Linux с root-доступом. Эти псевдоприложения запускают скрипт, который загружает с сервера образ виртуальной машины и кладёт его в кеш. Если образ не изменился и уже в кеше, заново скачиваться он не будет. Тот же скрипт настраивает VirtualBox и запускает виртуальную машину в режиме снапшота, т. е. студент может делать с запущенной виртуальной машиной что угодно, но всё вернётся к изначальному состоянию.
А как же Gnome и KDE?
Преподаватели хотят показывать студентам разные «рабочие среды», мол, существует не только одна кнопка Пуск (которая то есть, то её нет). Сначала я пошёл по простому пути и подготовил несколько виртуальных машин с Linux: одна — на KDE, другая — на Gnome. Но в таком режиме эти требовательные окружения работали очень неторопливо. И когда выдалась свободная минутка, написал скрипты, которые «просто» запускают выбранное окружение рабочего стола поверх моего, а преподаватель с «Панели управления» может в любой момент закрыть «KDE» или «Gnome». Теперь менять рабочие столы можно без перезагрузок. Быстро и удобно!
Анонимный вход
В компьютерных классах иногда проходят мероприятия со сторонними участниками (презентации, курсы, олимпиады и т.д.). Заводить для каждого из гостей логин и пароль неинтересно, поэтому в панели есть кнопка «Анонимный вход». Это очень удобная и важная кнопка! Нажатие на неё откроет на выбранных компьютерах чистый рабочий стол без единой иконки. Если потом выбрать в «панели управления» из списка всё, что необходимо и нажать «запустить утомительный процесс запуска одинаковых программ или открытия сайтов, связанный с перебеганием от компьютера к компьютеру будет заменён несколькими кликами.
Ограничивать так по полной
Ещё в „Панели управления“ есть кнопка „Заблокировать экран“. Она запускает самописный блокировщик с анимированным замочком (да, потому что мне хотелось анимированный замочек) и блокирует экран выбранным студентам.
Флешки отключены запретом чтения /media. Раньше способ был радикальнее, правильнее и эффективнее, но он перестал работать после очередного обновления Ubuntu. Преподаватель может разрешить студентам использовать флешки, выбрав в списке „Сменные носители“.
Установка дистрибутива должна быть предельно простой
Все компоненты системы я собрал в репозиторий. Теперь, чтобы настроить рабочее место моей мечты, нужно выполнить три простых действия: установить Kubuntu, подключить репозиторий, скомандовать apt-get install integration-client. И так на каждой машине. Это долго и нудно, особенно когда компьютеров 100+. Поэтому я воспользовался чудесным дистрибутивом SystemResсueCD. У него есть простое руководство по пересборке и добавлению скриптов в автозапуск. Теперь для установки дистрибутива нужно загрузиться с подготовленных мною флешки или диска, выбрать тип сети (DHCP, NAT или общая), указать номер аудитории и номер компьютера, выбрать тип установки: на одну машину или массовую установку во всём классе (поднимется сервер сетевой загрузки). Когда все параметры введены, скрипт размечает диск через parted, монтирует на самбе директорию с заранее подготовленным образом системы, распаковывает через fsarchiver на жесткий диск и устанавливает загрузчик. Весь процесс занимает 5-10 минут в зависимости от мощности компьютера и загруженности сети, а главное — не требует особых технических навыков.
Для тех, кто добрался до этих строк и располагает еще шестью минутами свободного времени есть изобилующая 3D эффектами презентация описанного проекта, которую я готовил для одной профильной конференции. К сожалению, по наивности, я сделал упор на то, что Linux это хорошо, а не Linux — плохо, а надо было отстраниться от священных воин и просто демонстрировать свои наработки. Но если смотреть с определённой долей иронии то вполне забавно.
Почему нельзя было тоже самое сделать на „самой популярной ОС“?
В принципе можно, но намного сложнее. Разрабатывать придётся намного больше. Для многих задач решаемых одной строкой на Bash в Windows придётся писать полноценную программу (PowerShell в те времена не было). И самое главное реализовать описанную массовую установку для большинства Windows программ легально не получится. В тексте лицензий такой подход, часто явно запрещён. А если ограничиться только open source приложениями, то зачем вообще Windows? По поводу совместимости с железом, дистрибутив Linux смотрится намного выигрышнее. За долгие годы апгрейдов в компьютерных классах собрался зоопарк материнских плат, видео и прочих карт. Ubuntu без проблем и долнительных настроек ставится практически на все машины (c учётом обновления установочного образа системы раз в два года). Установить класс на Windows и что бы сразу всё заработало — это очень редкий случай, и приходится по долгу колдовать над каждой машиной по отдельности.
Выводы
На вопрос — улучшилось или ухудшилось качество образования после внедрения всего вышеописанного — ответ такой: ничего не изменилось. Качество образования, как оказалось, целиком зависит от квалификации преподавателя. Однако процессы обучения и обслуживания компьютерного парка стали значительно более удобными, дешевыми, защищенными и контролируемыми.
Сейчас многие ограничения потеряли актуальность в связи с обилием мобильной техники у студентов. Интернет и игры от учебных компьютеров уже не нужны, они есть на планшетах и телефонах. (Вот сынок/дочка тебе планшет, учись хорошо… Много раз видел такую сцену… О чём эти родители вообще думают?!)
P. S. По поводу игр. Совершенно случайно получился интересный эксперимент. Когда я только развернул первую версию системы, в ней не было доступных игровых приложений. Через несколько дней один из преподавателей попросил меня добавить хоть какую-нибудь игру. Ну, я и добавил… шахматы. Вы когда-нибудь видели, как ещё недавно непреклонные фанаты Conter Strike c тем же задором играли в шахматы? Студенты собрались у компьютера (к сожалению, не было сетевого режима), кричали, махали руками, играя в эту игру!
P. P. S. Наработки по проекту здесь: http://sourceforge.net/p/int/code/ci/master/tree/. Внимание! Очень много страшного студенческого кода и глупых архитектурных решений, на JS вообще без слёз смотреть нельзя. Может когда-нибудь я всё же вернусь к этому проекту и перепишу, как надо (мечтательно).