1

Вышла первая альфа-версия дистрибутива 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

Я буду сниться тебе после смерти,  Под маской желтого шелка. Я очень тихо сыграю на флейте, И очень недолго.
  А ты пытайся в какой-то ответ  Интерпретировать звуки. (Я очень тихо играю на флейте. На грани слуха).
Я прячу в себе такую же тьму Под маской желтого шелка, Лицо собрав себе самому Из костяных осколков.

2 (09.03.2011 13:29:21 отредактировано Cruiser78)

renegat пишет:

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

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

3

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

Истина ускользает от тех кто отказывается её видеть обоими глазами.
Талантам нужно помогать, бездарности пробьются сами.
В Туле настолько суровые парни, что вместо пены для бритья, используют пену монтажную.
cat /broken/hands > /dev/null

4

Vadimsky пишет:

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

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

5

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

Истина ускользает от тех кто отказывается её видеть обоими глазами.
Талантам нужно помогать, бездарности пробьются сами.
В Туле настолько суровые парни, что вместо пены для бритья, используют пену монтажную.
cat /broken/hands > /dev/null