Началось альфа-тестирование дистрибутива Fedora Linux 15

Вышла первая альфа-версия дистрибутива Fedora Linux 15. Для загрузки доступны Live-сборки с GNOME 3 (567 Мб) и KDE 4.6 (667 Мб). Релиз запланирован на 10 мая.

Основные улучшения:

В состав дистрибутива включены последние версии десктоп-окружений Gnome 3.0 (с оболочной Gnome Shell), KDE 4.6 и Xfce 4.8;
Интеграция системного менеджера systemd в качестве системы инициализации по умолчанию. Systemd нацелен на более интенсивную параллелизацию выполнения сервисов на этапе загрузки системы, вобрав в себя лучшие черты таких систем, как launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, Fedora). Кроме запуска сервисов, systemd обеспечивает функции контроля за выполнением фоновых процессов. Подробнее о systemd можно прочитать в ранее опубликованных обзорах (здесь, здесь, здесь, здесь и здесь);
Изменение наименования сетевых интерфейсов. Вместо ethN имена устройств будут формироваться в зависимости от типа подключения сетевого адаптера: "em{port}" - для встроенных в материнскую плату сетевых карт и "pci{slot}#{port}" - для карт с PCI-интерфейсом.
Переход на GCC 4.6 для сборки пакетов. Интеграция в дистрибутив Python 3.2 и новых версий Rails и OCaml;
Использование вместо OpenOffice.org офисного пакета LibreOffice;
Интеграция BoxGrinder, инструмента для упрощения формирования сборок для развертывания внутри различных систем виртуализации (KVM, Xen, EC2);
Добавление фонового процесса для динамического управления правилами пакетного фильтра через DBus;
Улучшение поддержки шифрованной файловой системы eCryptfs. Использование authconfig для автоматического монтирования зашифрованных частей домашней директории в момент входа пользователя в систему;
Использование по умолчанию DNSSEC в конфигурациях рабочих станций. Для преобразования имен в NetworkManager использует DNS-сервер BIND;
Улучшение работы системы управления питанием, поддержка автоматического тюнинга параметров работы системы, с целью обеспечения оптимального баланса между производительностью и энергопотреблением. Интеграция утилиты PowerTOP для выявление узких мест, приводящих к повышенному энергопотреблению;
Добавление в дистрибутив ERP-платформы Tryton, предназначенной для разработки приложений для управления ресурсами предприятия (финансы, управление продажами и закупками, аналитика, инвентаризация и т.п.);
Новые группы пакетов: Graphics suite переименован в Design group, добавлена новая группа Robotics Package Suite, в которую вошли инструменты для проектирования роботов, симуляции их работы и создания программного обеспечения;
Задействование метода сжатия LZMA для формирования Live-образов;
C целью повышения безопасности все setuid-приложения будут переведены на использование "capabilities";
Разделы /var/run и /var/lock смонтированы в виде RAM-диска (tmpfs);
Добавление LessFS, FUSE-модуля для автоматического объединения дубликатов в файлах;
Обновление пакетного менеджера RPM до версии 4.9;
Поддержка технологии Spice в virt-manager;
GUI-интерфейс Setroubleshoot переработан с целью упрощения диагностики проблем с SELinux.
http://www.opennet.ru/opennews/art.shtml?num=29843

renegat написал:

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

Это они, IMHO, зря... Ох и повеселимся, когда на PCI-шине будет висеть по нескольку разных плат... И какая из них - сетевая??? Хотя, может я и неправ.
Ну и к тому же - очень возможны ситуации, когда конфикурации ПО завязаны на традиционные названия сетевых интерфейсов.

я так привык к eth0 и eth1
придётся переписать кучу скриптов.
Нобольше всего мне не нравится /var/run на RAM-диске.
С одной стороны это удобно, но в случае ребута сервака пропадут PID-файлы, по наличию которых, у меня при загрузке запускается тот или другой скрипт.
Придётся ковырять кучу конфигов, что бы настроить кидать PID-файлы в другое место. Что не есть айс.... :(

Vadimsky написал:

Придётся ковырять кучу конфигов, что бы настроить кидать PID-файлы в другое место. Что не есть айс.... :(

Не понял проблемы. PID-ы то появляются, когда тот или иной процесс запущен. И не появляются, когда... Какая разница - где ему появляться при запуске системы? А если PID-файл есть (на локальной FS), но самого процесса еще нет? Не стартовал еще, а PID от прежнего запуска остался неудаленным? Нет, помещать такую текучку надо именно в tmpfs. Которая при запуске оси завсегда чистая. Это правильное решение. А менять ethХ.... Это не поддерживаю.

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