•   Миф: systemd является монолитом.
  
  - Леннарт считает что это неправда, поскольку при полной сборке всех компонентов systemd создаётся 69 различных исполняемых файлов, каждый из которых отвечает за решение своей задачи. При этом большая часть данных исполняемых файлов может использоваться обособленно, без привязки к systemd. Целью разбиения функциональности на отдельные исполняемые файлы произведено, например, для решения таких задач, как более полное разделение привилегий (каждый процесс снабжается привилегиями только для выполнения узких задач) и обеспечение параллельного выполнения операций в процессе загрузки.
  
  
•   Миф: главной целью systemd является скорость.
  
  - По мнению Леннарта, высокая скорость systemd - это всего лишь побочный результат правильного дизайна и архитектуры проекта. Разработчики специально не занимались выжиманием всей возможной производительности из кода. Более того в некоторых ситуациях разработчики предпочитают более читаемый код, чем немного более быстрый и запутанный.
  
  
•   Миф: скорость загрузки, предоставляемая systemd, не востребована на серверах.
  
  - Леннарт отмечает что многие системные администраторы напротив желают минимизации простоев (downtime) при выполнении обслуживания серверов. Кроме того, скорость старта востребована в облачных системах и на виртуальных машинах. Также критична скорость восстановления после сбоя систем высокой доступности.
  
  
•   Миф: systemd не совместим с shell-скриптами.
  
  - На самом деле он совместим, просто сами разработчики systemd не пользуются shell-скриптами в процессе загрузки, чтобы не терять преимущества systemd. Тем не менее, systemd позволяет запускать скрипты, написанные на любых языках программирования, как сервисы systemd.
  
  
•   Миф: освоить systemd сложно.
  
  - По мнению Леннарта это не так, поскольку это унифицированная платформа, язык файлов конфигурации прост и предоставляется типовой набор утилит. Тем не менее, Леннарт согласен с тем, что некоторое обучение работе с systemd все-таки требуется.
  
  
•   Миф: Systemd не модульный.
  
  - Это не так: в сборочном скрипте configure есть ряд ключей, позволяющих указать какие именно части systemd требуется собрать. Таким образом выбор предоставляемых возможностей осуществляется на этапе сборки.
  
  
•   Миф: Systemd только для десктопов.
  
  - Systemd охватывает примерно те же области использования, что и ядро Linux. Разработка Systemd одинаково позиционируется для десктопов, серверов и встраиваемых систем. Автопроизводители уже используют Systemd для автомобильных информационно-развлекательных платформ, Red Hat будет использовать Systemd в промышленном серверном дистрибутиве, проект GNOME задействует многие из интерфейсов Systemd для десктопа.
  
  
•   Миф: Systemd появился как результат синдрома NIH (Not Invented Here, создание собственного решения вместо использования уже существующих аналогов).
  
  - Изначально у разработчиков была идея использовать проект Upstart от фирмы Canonical, однако постепенно разработчики пришли к выводу, что у него есть ряд значительных недостатков в базовых основах дизайна, которые достаточно проблематично исправить. Наиболее крупным просчетом по мнению Леннарта является то, что upstart сам по себе не заботится о зависимостях сервисов и переносит заботу об этом аспекте на плечи администраторов и разработчиков.
  
  
•   Миф: systemd - проект FreeDesktop.org.
  
  - FreeDesktop.org используется в основном как инфраструктура хостинга.
  
  
•   Миф: systemd далёк от философии UNIX.
  
  - В systemd используется множество концепций UNIX, напрмер, идея "всё есть файл" реализована в доступе ко всем сервисам systemd осуществляется через файловую систему cgroupfs. Встроенная поддержка подключения нескольких рабочих мест к одному компьютеру выражается в поддержке multi-seat и возможности автоматической настройки подключаемого оборудования. Основу systemd составляет набор связанных через стандартные интерфейсы утилит, каждая из которых решает свою задачу.
  
  
•   Миф: Systemd сложно устроен.
  
  - Леннарт частично согласен с этим тезисом, однако отмечает, что это связано с тем что современные компьютеры стали сложными. Тем не менее, Леннарт считает, что systemd проще и содержит меньше избыточности и зависимостей, чем эквивалентные по возможностям решения.
  
  
•   Миф: Systemd чрезмерно тяжелый и перегруженный.
  
  - Systemd вероятно является как раз обратным примером. Он модульный, предоставляет много функциональности, а требуемые зависимости включают в себя лишь Glibc, libcap и DBus.
  
  
•   Миф: Systemd создан только для Linux и не может использоваться в BSD-системах.
  
  - По мнению Леннарта, основной причиной данной ситуации является то, что разработчики систем на основе BSD не заинтересованы в данной системе инициализации, так как исторически ядра BSD-систем развивались одновременно с пользовательским окружением вокруг них и данные системы имеют собственные системы инициализации, жестко привязанные к особенностям каждому BSD-проекту.
  
  
•   Миф: Systemd не сможет использоваться по умолчанию в Debian, так как он поддерживает только ядро Linux.
  
  - Леннерт отмечает, что работа по одновременному сопровождению unit-файлов systemd и классических init файлов является номинальной и незначительной по объему на фоне столь масштабной работы как внедрение в систему поддержки ядер, отличных от Linux.
  
  
•   Миф: Systemd можно портировать для других ядер, если мэйнтейнеры этих ядре этого пожелают.
  
  - Systemd слишком завязан на возможности и интерфейсы, доступные только в ядре Linux. В некоторых ядрах имеются аналоги подобных интерфейсов, некоторые возможности можно отключить, но все необходимые функции вряд-ли удастся обеспечить в ядрах, отличных от Linux. Среди активно используемых в Systemd возможностей: cgroups, fanotify, umount2(), /proc/self/mountinfo, /dev/swaps, udev, netlink, /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces, prctl(), ioctl, системный вызов mount(), selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input и т.п.
  
  
•   Миф: Systemd не является переносимым (Not Portable) без каких либо на то причин.
  
  - Это не так! Systemd просто использует специфичную для Linux функциональность чтобы реализовывать все что хотели сделать разработчики. У Linux столько возможностей, что остальные unix/posix системы попросту не предоставляют каких либо аналогов для многих из них, в то время как разработчики systemd желают дать в руки пользователей данные возможности.
  
  
•   Миф: Systemd использует конфигурационные файлы в бинарном формате.
  
  - В Systemd используются только простые и легко редактируемые вручную текстовые файлы конфигурации. Никакого XML и тем более бинарных форматов.
  
  
•   Миф: Systemd содержим избыточную функциональность.
  
  - Systemd изначально не ограничивался только системой инициализации и развивается как набор кирпичиков для построения ОС. Какие именно из возможности использовать решает пользователь, большая часть функций отключается на этапе сборки или в процессе работы.
  
  
•   Миф: Systemd заставляет кого-то что-то делать.
  
  - Программы - не мафия. Они не могут никого заставить что-либо делать против их воли. В Free Software каждый добровольно делает то, что считает нужным.
  
  
•   Миф: Systemd не позволяет использовать Syslog.
  
  - Это не так. Хотя у systemd есть свой метод ведения журналов, разработчики предприняли усилия чтобы сохранить полную совместимость с более традиционным syslog.
  
  
•   Миф: Systemd ни с чем не совместим.
  
  - Разработчики Systemd делают всё вохможное чтобы обеспечить наилучшую возможную совместимость с sysvinit. Большинство init-скриптов могут быть использованы с Systemd без необходимости внесения в них изменений. Имеющиеся несовместимости хорошо документированы.
  
  
•   Миф: К Systemd невозможно обращаться из скриптов из-за использования D-Bus.
  
  - Systemd предоставляет обширный набор утилит (systemctl, loginctl, timedatectl, hostnamectl, localectl) со всевозможными опциями, являющимися аналогами вызовов D-Bus, которые можно запускать из скриптов для автоматизации выполнения различных задач. Кроме того, нет никаких проблем с обращению к D-Bus из скриптов при помощи таких утилит как dbus-send и gdbus.
  
  
•   Миф: Systemd вынуждает использовать дополнительные конфигурационные утилиты вместо непосредственной правки файлов конфигурации.
  
  - Это не так. Конфигурационные утилиты предоставляют только дополнительную функциональность, такую как автодополнение имён директив конфигурации, но никто не заставляет обязательно их использовать. Пользователь может реализовать все действия через прямую правку файлов конфигурции с последующим ручным перезапуском связанных с ними процессов.
  
  
•   Миф: Systemd нестабилен и изобилует ошибками.
  
  - Этот тезис не подтверждается багтрекером системы Fedora.
  
  
•   Миф: Systemd трудно отлаживать.
  
  - В Systemd предусмотрен специальный отладочный интерфейс с поддержкой интерактивной отладки, отслеживания состояния, отключения компонентов при загрузке.
  
  
•   Миф: В Systemd изменения вносятся ради изменений.
  
  - Это не так, каждое вносимое в Systemd имеет техническое обоснование и разработчики по возможности стараются донести до общественности причины тех или иных изменений в wiki, блогах, документации и других источниках. Нарушающие совместимость изменения вносятся только в крайних случаях и явно документируются.
  
  
•   Миф: Systemd является проектом только компании Red Hat, которая использует трудоустроенных разработчиков для распространения своего мировоззрения.
  
  - Это не так, из 16 ведущих разработчиков Systemd только 6 работает в Red Hat, а остальные представляют такие проекты и компании как ArchLinux, Debian, Intel, Canonical, Mandriva, Pantheon.
  
  
•   Миф: Systemd не позволяет отделить /usr от корневой директории.
  
  - С самого начала systemd поддерживает опцию сборки "--with-rootprefix=", которая позволяет выделить необходимые для начальной стадии загрузки компоненты и установить их в корень или любою другую директорию. Хоть разработчики systemd и не считают загрузку без /usr хорошей идее, такая возможность поддерживается из коробки.
  
  
•   Миф: Systemd не позволяет заменять свои компоненты.
  
  - Это не так, большая часть возможностей Systemd может быть отключена и заменена на альтернативные реализации.
  
  
•   Миф: Использование D-Bus вместо сокетов делает Systemd непрозрачным.
  
  - D-Bus использует сокеты в качестве транспорта, но при этом предоставляет стандартизованный механизм сериализации сообщений, отправляемых через сокеты. Так как методы сериализации хорошо документированы и имеются штатные утилиты трассировки, то использование D-Bus наоборот делает систему более прозрачной, что нельзя сказать о многих Unix-демонах, которые использовали собственные протоколы для обмена данными.

•   "Addons" с дополнительными пакетами, которых нет в репозиториях RHEL. Например, в репозитории можно найти подборку Perl и Ruby модулей, системы мониторинга Zabbix и Nagios, свежие версии Firefox и различных мультимедийных и офисных программ;
•   "Computational" - с большой подборкой научных программ (более 400 пакетов);
•   "Unsupported" - с различными экспериментальными пакетами, например, с новыми версиями серверных программ, таких как clamav, exim, lighttpd, php и т.п.

•  Все текущие репозитории были объединены в один, чтобы облегчить конечным пользователям работу с ними.
•  Было сделано много важных изменений, в сравнении с предыдущей версией, поэтому настоятельно рекомендуется прочитать примечания к выпуску.
•  Так как текущая версия RHEL 6.2 уже выпущена, будут использоваться Continuous Release репозиторий, чтобы доставить все обновления безопасности до того, как выйдет CentOS 6.2.
•  LiveCD и LiveDVD также выпущены. Они дают вам возможность как ознакомления с системой, так и непосредственной установки на жесткий диск.
•  Есть также диск минимальной установки, который устанавливает лишь базовою часть системы и позволяет доуcтановить все остальное по вашему желанию.

•   кодовое имя: "мясное чудо";
•   используемая по умолчанию новая файловая система btrfs;
•   удаление ConsoleKit с заменой его функций через systemd-logind;
•   поддердка только DRI2-драйверов видеокарт; старые видеокарты будут поддерживаться через драйвер llvmpipe;
•   программная обработка 3-х мерной графики должна позволить запускать gnome-shell на любом компьютере;
•   дальнейший переход с sysVinit на systemd;
•   перенос всех файлов из /( ,s)bin и /lib( ,64) в /usr. (А там не за горами и /System :))

Открытое ПО… некоторые из аналитиков индустрии свободного ПО, например Стивен О’Грейди (Stephen O'Grady) из Redmonk или же убежденный сторонник свободного ПО Глин Муди (Glyn Moody), сомневались в возможности появления в этой сфере компании-миллиардера.

Тем не менее, компания Red Hat, лидер среди разработчиков открытых программных продуктов, пообещала перейти рубеж в 1 млрд долларов в следующем финансовом году. Этому и была посвящена вступительная речь Джима Уайтхерста (Jim Whitehurst, президент и CEO в Red Hat) «Перейдя рубеж в 1 миллиард долларов – возможности открытых технологий» на бизнес-конференции OSBC.

Годовой доход в один миллиард долларов больше не мечта для разработчиков открытого ПО. Теперь это – реальность, которая Red Hat действительно по плечу. Однако вполне вероятно, что компания, достигшая столь впечатляющих результатов, останется единственной в этом списке.

В погоне за миллиардной выручкой Red Hat оставила своих ближайших конкурентов далеко позади. Доходы других компаний, работающих с открытым кодом, несравнимо ниже. Например, такая известная Open Source-компания, как Mozilla, за последний финансовый год заработала 104 миллиона долларов, и до миллиарда им еще далеко. Другой пример – компания MySQL AB, которая заработала почти 94 миллиона перед тем, как ее приобрела Sun Microsystems. Теперь MySQL принадлежит Oracle, и наверняка сможет достичь еще большего. Но не миллиард. И не за пару лет.

Есть и те, чей бизнес совмещает как проприетарное, так и свободное ПО. Но доходы этих компаний немногим выше. Alfresco, SugarCRM, Pentaho, JasperSoft и еще ряд компаний только приближаются к порогу в 100 миллионов долларов, что откроет им двери для первичного размещения акций (IPO), SourceFire уже зарабатывает 130 миллионов в год. Но еще никто и близко не подобрался к заветному миллиарду Red Hat. В чем же дело?

Во-первых, как отмечает Глин Муди (Glyn Moody), ПО с открытым исходным кодом – это прекрасная модель для разработки и распространения программных продуктов, но она не очень подходит для тех, кто хочет заработать быстро и много. Поэтому неудивительно, что Мэтью Эслетт (Matthew Aslett) из The 451 Group не перестает повторять, что Open Source в чистом виде – это не бизнес-модель.

Как бы то ни было, своих успехов Red Hat достигала не в «тепличных» условиях. Сертифицированная, поддерживаемая и обновляемая модель Red Hat отлично подходит для продажи операционной системы, которая лежит в основе инфраструктуры предприятий, и не совсем приспособлена для продвижения корпоративных или пользовательских приложений. Однако это вовсе не означает, что в данной модели прикладное ПО не играет большой роли. Наоборот, выбор надежной операционной системы для бизнес-критичных приложений – это верный путь оградить себя от риска: IT-менеджер скорее потратит на несколько тысяч долларов больше, приобретя сервер Red Hat, чем решит сэкономить и довериться менее надежному разработчику. Ведь основную часть расходов составляет покупка прикладного ПО, и по сравнению с ним сервер RHEL или JBoss стоит сущие гроши. Именно такой подход и помог Red Hat подойти к границе в миллиард долларов.

Но и здесь успех не гарантирован. Множество компаний с аналогичной инфраструктурой на базе свободного ПО не добились и сотой доли того, что имеет сейчас Red Hat. Это свидетельство здорового прагматизма в системе менеджмента компании, где даже разработчики преданы принципам и ценностям открытого ПО.

Red Hat — первый вендор Linux, который сосредоточил своё внимание на корпоративных нуждах, выпустив в 2002 году Advanced Server. В то время казалось, что это не лучшая идея, поскольку она грозила ухудшением поддержки десктоп-систем пользователей, отдававших предпочтение бренду Red Hat. Однако, такое решение только сыграло на руку компании, в то время как ее конкуренты погрязли в сложных пользовательских и корпоративных продуктах на базе Linux.

Сфокусировав свое внимание на корпоративных решениях, компания Red Hat не снизила ценовой уровень. Например, стоимость Red Hat Enterprise Linux (RHEL) для мейнфреймов IBM существенно превышает стоимость этой же ОС для серверов стандартной архитектуры (чем весьма недовольны в IBM). Это не означает, что возрастает стоимость поддержки пользователей IBM, а скорее то, что Red Hat может взимать дополнительную плату с крупных компаний, что в принципе и делает. Как было отмечено в ходе одной из бесед, Red Hat продаёт качество, а не зарабатывает на скидках. Это бизнес, а не благотворительность.

Будучи одной из первых компаний, начавших борьбу с пробелами в области защиты интеллектуальной собственности, Red Hat инвестирует средства в программу по защите патентов. И следует отметить, что данная программа набирает все большие обороты.

Итак, Red Hat — это компания-разработчик СПО с предельно ясным видением рынка и чётким планом ведения бизнеса. Немногие компании, как из индустрии программного обеспечения с открытым исходным кодом, так и из других областей, смогут сравниться с Red Hat.

Отличия от RHEL 6.0:

•   добавлен оконный менеджер IceWM;
•   поддержка распределённой файловой системы openafs;
•   yum-autoupdater, позволяющий ежедневно автоматически обновлять систему;
•   дополнительные репозитории

Дополнение от Олега Садова, Linux Ink:

по нашему технологическому циклу -- мы сначала выпускаем т.н. Scientific Linux Cyrillic Edition, а потом по мере пересборки всех пакетов -- Наулинукс и его варианты с какими то проблемно-ориентированными дополнениями (напр. "Наулинукс Школа"). И тот и другой дистрибутив являются официальными вариациями ("site" или "spin") на тему Scientific Linux:

 http://www.scientificlinux.org/community/sites/

Cyrillic Edition для 6-ки надеемся выпустить в течении месяца. Если есть какие-то соображения относительно изменений и дополнений которые имело бы смысл сделать в российской локализации, милости просим в наш список рассылки:

 https://lists.linux-ink.ru/mailman/listinfo/naulinux

•   интеграция системного менеджера systemd в качестве системы инициализации по умолчанию;

•   включение в поставку десктоп-окружений Gnome 3.0, KDE 4.6 и Xfce 4.8;

•   переход на GCC 4.6 для сборки пакетов;

•   задействование метода сжатия LZMA для формирования Live-образов;

•   с целью повышения безопасности все setuid-приложения будут переведены на использование "capabilities";

•   разделы /var/run и /var/lock будут смонтированы в виде RAM-диска (tmpfs);

•   добавление LessFS, FUSE-модуля для автоматического объединения дубликатов в файлах;

•   поддержка динамического управления правилами пакетного фильтра через DBus;

•   использование по умолчанию DNSSEC в конфигурациях рабочих станций;

•   изменение наименования сетевых интерфейсов. Вместо ethN имена устройств будут формироваться в зависимости от типа подключения сетевого адаптера: "em{por}" - для встроенных в материнскую плату сетевых карт и "pci{slot}#{port}" - для карт с PCI-интерфейсом.

• поддержка автомонтирования ecryptfs в authconfig;

• замена OpenOffice.org на LibreOffice;

• интеграция в дистрибутив Python 3.2;

• обновление пакетного менеджера RPM до версии 4.9;

• интеграция в дистрибутив инструментария для проектирования роботов, симуляции их работы и создания программного обеспечения;

• Поддержка технологии Spice в virt-manager;

• улучшение работы системы управления питанием;

• GUI-интерфейс Setroubleshoot будет переработан с целью упрощения диагностики проблем с SELinux;

• использование по умолчанию файловой системы Btrfs.

Взято с opennet.ru

Итак сегодня, мы анонсируем Russian Fedora Remix 13.1. По сути это большое обновление пакетов. Также за время тестирования были исправлены некоторые баги:

• rf#164 – добавлен OpenOffice.org на диск LiveDVD-KDE;
• rf#165 – исправлен вход в систему после установки LiveDVD-KDE на жёсткий диск;
• rf#171– добавлена установка пакетов knetworkmanager-vpnc, knetworkmanager-pptp, knetworkmanager-openvpn к устанавливаемому knetworkmanager;
• rf#172 – исправлен выбор менеджера входа в систему при первой загрузке;
• rf#176 – добавлен импорт всех GPG ключей (на Live дисках), которые на данный момент есть в /etc/pki/rpm-gpg/;
• rf#177 – на Live диски добавлены пакеты для поддержки некоторых сетевых адаптеров: kmod-wl, kmod-rt2860, kmod-rt2870, kmod-rt3070;
• rf#179 – flash-plugin на 32-х битной системе не требует nspluginwrapper;
• rf#180 – увеличено время автологина на Live дисках (где используется gdm).

К плохим новшествам наверно можно отнести отсутствие Adobe Flash на Live дисках. Правда без интернета он и не нужен, а при наличии последнего его можно установить при помощи команды:

Для загрузки доступны установочные DVD и CD образы, образы delta, LiveCD с GNOME, KDE, XFCE, LXDE и LiveDVD с KDE и всеми средами сразу. Загрузить образы можно либо с зеркала Яндекса, либо с Канадского зеркала.

Также вы можете загрузить образы через Torrent.

Найденные ошибки следует регистрировать в Bug Tracker. Различную помощь можно получить либо на форуме Russian Fedora, либо в конференции fedora@conference.jabber.ru.

Следующий выпуск Russian Fedora Remix 14 выйдет одновременно с выпуском Fedora 14, запланированным на 2 ноября 2010.

Как не относящиеся к делу пропущены разделы 26 - Текстовые редакторы и
вспомогательные средства разработки в Linux, 27 - Лицензирование RPM (текст
GPL)

Из новшеств:

• Как всегда, самые последние версии различных пакетов: X.org, GNOME, KDE, XFCE.
• Уменьшенное время загрузки (обещают загрузку за 20 секунд)
• Поддержка KMS (Kernel Mode Setting, установка параметров видеорежима из ядра)
• Для карт NVIDIA теперь устанавливается свободный драйвер nouveau.
• Поддержка delta-rpm, файлов различий между разными версиями одного и того же пакета. Позволяет значительно сэкономить траффик при обновлениях
• Частичная замена HAL на DeviceKit
• Прочие незначительные улучшения.

В новом релизе реализованы следующие возможности:

* Улучшения в механизме репликации серверов (startTLS, SASL, Kerberos)

* 64-битные счетчики

* Возможность отключить анонимные подключения к каталогу

* Новые скрипты: remove-ds.pl для удаления экземпляра каталога и remove-ds-admin.pl - некий "hard reset", для того чтобы привести систему в состояние сразу после "yum install fedora-ds"

* Новая консоль и Windows Password Sync для синхронизации с Microsoft AD

* Расширение ACI (новые динамические фильтры)

* Исправлено более 200 ошибок, найденных с прошлого релиза

* Новая схема, которая изначально включает расширения для autofs, samba и множества других приложений

Из возможностей Fedora Directory Server можно отметить "multi-master" систему репликации данных, шифрование данных в хранилище и при передаче (SSLv3, TLSv1, SASL), поддержка расширений из LDAPv3, гибкие ACL, высокая производительность (тысячи операций в секунду, десятки тысяч одновременно работающих пользователей в сети, десятки миллионов аккаунтов, сотни гигабайт данных в хранилище).

Вместе с тем участники проекта отмечают, что бета-версия Fedora 11 содержит ряд недоработок и поэтому не рекомендуется для повседневного использования.

 >>> Подробнее