LINUX.ORG.RU

Обзор принятых нововведений для Fedora 18

 , ,


2

3

Не так давно прошли 4 собрания FESCo, на которых были приняты некоторые новые изменения, которые будут включены в 18-й выпуск ОС Fedora GNU/Linux.

Вот полный их список:

Первое собрание FESCo:

  • Упрощенная первоначальная настройка системы после установки на замену устаревшему firstboot. Будет создан апплет, который позволит быстро ознакомиться с лицензионным соглашением, настроить сеть, создать аккаунты пользователей и т.п.
  • Лучшая поддержка Clojure. Несмотря на то, что сам Clojure уже есть в репозитории, все еще недостает полезных утилит, которые приходится откуда-то качать, собирать и ставить. Это нужно исправить. Вызвался заняться этим немец индонезийского происхождения Michel Alexandre Salim, который помимо прочего помогает в деле включения Riak в репозитории Fedora.
  • Новый фронтэнд для RPM на замену yum — DNF (была предложена еще одна «фича», включение Hawkey, библиотеки для DNF, но ее порекомендовали объединить с родительской задачей). Цель — замена yum на более быстрый аналог, базирующийся на разработках проекта openSUSE.
  • Включение нового плагина для GCC, базирующегося на LLVM — DragonEgg. Это позволит использовать при компиляции с GCC оптимизатор и кодогенератор из LLVM.
  • Продолжится перевод SysVinit-скриптов в sytstemd-юниты.
  • Переименование логических переменных в SELinux. Ранее они именовались бессистемно, а теперь было решено привести их к некоему общему виду. Народ волнуется и ожидает проблем. Ничего, прорвемся!

Второе собрание FESCo:

  • В Fedora 18 будут новые нескучные 256-цветные терминалы. Пользователи Mac OS X, которые работают на Linux-машинах через ssh, будут особенно рады.
  • CIM Management — еще одна фича, предназначенная для т. н. систем enterprise-уровня.
  • Обновление fontconfig до версии 2.10.
  • Обновление Ruby on Rails до версии 3.2.
  • Обновление Perl до версии 5.16.
  • Новая суб-архитектура для PowerPC — Power7 (ppc64v7). Теперь их будет три: ppc, ppc64 и ppc64v7.

Третье собрание FESCo:

  • KDE 4.9.
  • Еще одно облачное решение будет доступно из коробки — Eucaliptus. Список зависимостей у него довольно значительный, но будем надеяться, что успеют.
  • Включение gss-proxy на замену старому rpc.svcgssd.
  • Две фичи для лучшей поддержки восточных и азиатских языков — автодополнение слов, основанное на ibus и совместимое с ним, и новый ibus-модуль для упрощенного китайского.

Четвёртое (последнее) собрание FESCo:

Отдельно стоит упомянуть 2 нововведения, связанные с проблемой обработки ошибок:

  • Использование специализированной утилиты для сжатия DWARF-секций, что уменьшит размер пакетов *-debuginfo. Это потребует внесения изменений во все приложения, что читают debug-информацию (gdb, valgrind и т.п.), и пересборку всего дерева.
  • Bызвавшая ожесточенные споры «фича» — установка некоего сокращенного *-debuginfo с каждым пакетом. Это, как ожидается, увеличит минимальные требования к свободному месту на 5-10 процентов. В общем, не так и страшно, но мы напоминаем, что была более радикальная идея — вообще не устанавливать никакого debuginfo, а использовать специализированный Web-сервис и FUSE для получения отладочной информации. Напоминаем, что речь не идет о разработчиках и тестерах — речь идет о том, чтоб увеличить качество автоматизированных багрепортов от простых пользователей.

Первое заседание
Второе заседание
Третье
Четвёртое

Теперь приём заявок на нововведения в Fedora 18 закрыт.

★★★

Проверено: maxcom ()
Последнее исправление: Silent (всего исправлений: 9)
Ответ на: комментарий от AVL2

о в любом случае имхо прежде чем вводить новый пакетный менеджер, имеет смысл его обкатать в опциональном режиме на текущем дистре.

Ну пока именно это и предлагается: «For Fedora 18 this is mainly meant as a preview» Говорить о замене пакетного менеджера рано.

Тоже как-то слабо согласуется, не находите?

Почему? Это форк yum-а, поэтому у него будет схожий интерфейс и на него легче будет перейти. При этом он будет использовать другую библиотеку, поэтому предполагается, что будет работать быстрее и эффективнее. По-моему логично.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Почему? Это форк yum-а, поэтому у него будет схожий интерфейс и на него легче будет перейти. При этом он будет использовать другую библиотеку, поэтому предполагается, что будет работать быстрее и эффективнее. По-моему логично.

2 тормозных поделия на питоне. «быстрее», «эффективнее» - это только розовые мечты.

Deleted
()
Ответ на: комментарий от alpha

Машинка для производства лозунгов - это Peter Lemenkov на вашем сайте.

Deleted
()
Ответ на: комментарий от alpha

Ну пока именно это и предлагается: «For Fedora 18 this is mainly meant as a preview» Говорить о замене пакетного менеджера рано.

Понятно.

Почему? Это форк yum-а, поэтому у него будет схожий интерфейс и на него легче будет перейти.

Довольно странно форк называть новыйм проектом. Это все тот же питоновый скрипт.

При этом он будет использовать другую библиотеку, поэтому предполагается, что будет работать быстрее и эффективнее. По-моему логично.

Ну это врядли. Насколько я помню, юма еще в 15 федоре частично на си переписали. С какой стати он станет быстрее? Да и нужно ли это? Имхо юм страдает от своей питоновой сущности, а не от медлительности. Стандартные операции поиска и установки у него проходят вполне себе хорошо.

А вот, например, необходимость жать ctrl-c стопицот раз на каждом зеркале, вот это другое.

AVL2 ★★★★★
()
Ответ на: комментарий от Deleted

2 тормозных поделия на питоне

Поскольку питон тормозит в основном у тех, кто его в глаза не видел, то ничего страшного.

По сабжу: федора правильным путём идёт, я считаю. Надо будет попробовать - сравнить с Убунтой

Divius ★★
()
Ответ на: комментарий от AVL2

С какой стати он станет быстрее? Да и нужно ли это? Имхо юм страдает от своей питоновой сущности, а не от медлительности.

Честно говоря я не понимаю, что значит «питоновая сущность» в вашем понимании. По вашему медлительна написанная на питоне обвязка для разбора параметров командной строки? Наверное нет. Наверное всё-таки важны внутренние функции работы с зависимостями, с репозиториями и т.п.?

libsolv - это как раз сишная библиотека, которая предполагается более быстрой по каким-то там своим причинам. Соответственно то, что они делают, - это оставляют интерфейс юма и постепенно заменяют внутренности на другие. Вполне вероятно, что они начали это делать в самом yum-е, но потом уперлись в какие-то ограничения и теперь продолжают это дело уже в рамках отдельного форка.

Вот как попадет этот DNF в репозитории - так и потестим, сравним скорости.

alpha ★★★★★
()
Ответ на: комментарий от AVL2

юма еще в 15 федоре частично на си переписали

юм страдает от своей питоновой сущности

Взаимоисключающие параграфы в действии

от своей питоновой сущности, а не от медлительности

... и фанатизм там же. Гвидо тебе лично в компьютер лезет с питоновской сущностью? И тормозит то, что не страдает «медлительностью»?

Что-то ты, кажется, сам себя не понял

Divius ★★
()
Ответ на: комментарий от alpha

Честно говоря я не понимаю, что значит «питоновая сущность» в вашем понимании.

Это перманентно выпадающие скрипты-программы. Например, из за юникода - http://bb.comp-house.ru/comp-house.repo/wiki/python-unicode-error

или вот еще питоновый прикол: http://bb.comp-house.ru/comp-house.repo/wiki/bug_in_system-config-keyboard

По вашему медлительна написанная на питоне

я не считаю, что юм в целом излишне медлителен. Для операций поиска и уставновки (то, для чего его и писали) он достаточно быстр, потому что на осознание необходимости доустановки софта, поиск ключевых слов для поиска и загрузку пакета из репа уходит не в пример больше времени. Потерять полчаса на поиск и принятие решения и съэкономить минуту на установке?

Проблемы юма в его недостаточной надежности. Это гораздо более серьезный недостаток, чем мнимая медлительность.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

Странные претензии, на мой вкус. Как будто, если прогу переписать на другом языке, в ней сразу уменьшится количество багов.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Странные претензии, на мой вкус. Как будто, если прогу переписать на другом языке, в ней сразу уменьшится количество багов.

Естественно, накосячить можно где угодно, было бы желание. Тем не менее используемый инструмент обычно оставляет свои следы. В питоне это куча ошибок, которые выявляются уже в рантайме.

AVL2 ★★★★★
()
Ответ на: комментарий от alpha

Ну это стандартное, ничем не обоснованное заявление для старта холивара. Я - пас )

да как же не обоснованное? В федоре инсталлятор, юм и семейство system-config написаны именно на питоне.

И достаточно посмотреть в логи при инсталляции или в багзиллу, чтобы убедиться, что ни одна из этих программ нормально не работает.

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

AVL2 ★★★★★
()
Ответ на: комментарий от Divius

Поскольку питон тормозит в основном у тех, кто его в глаза не видел, то ничего страшного.

Нормальные люди устанавливают и удаляют софт, поэтому не могут не столкнуться с ним. Но в вашей убанте возможно все юзают изкоробки.

Deleted
()
Ответ на: комментарий от AVL2

А вот, например, необходимость жать ctrl-c стопицот раз на каждом зеркале, вот это другое.

Что за необходимость такая?

dexpl ★★★★★
()
Ответ на: комментарий от Divius

По сабжу: федора правильным путём идёт, я считаю. Надо будет попробовать - сравнить с Убунтой

Я сегодня сравнил: fedora с gnome 3.4 тормозит сильно меньше на моем нетбуке чем ubuntu с unity.

vyazovoi ★★★
()
Ответ на: комментарий от dexpl

Что за необходимость такая?

если во время отмены операции юм пытается загрузить с зеркал что-то, то он так и будет скакать по всему списку зеркал, пока они не кончатся или не попадешь в момент смены. Так и строчишь ctrl-c пока не получится.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

если во время отмены операции юм пытается загрузить с зеркал что-то, то он так и будет скакать по всему списку зеркал, пока они не кончатся или не попадешь в момент смены. Так и строчишь ctrl-c пока не получится.

Да, есть такое дело, только я сомневаюсь, что в этом виновать конкретно python

dexpl ★★★★★
()
Ответ на: комментарий от dexpl

Да, есть такое дело, только я сомневаюсь, что в этом виновать конкретно python

Не прямо. Питон виноват в том, что в нем всеп рейсы обостряются до предела. И в том, что писать в нем корректный код сложно и муторно, то есть теряется его главное преимущество - быстрый код. Поэтому програмки на питоне вечно не доделаны и нестабильны.

AVL2 ★★★★★
()
Ответ на: комментарий от vyazovoi

Я сегодня сравнил: fedora с gnome 3.4 тормозит сильно меньше на моем нетбуке чем ubuntu с unity.

мне бы сравнение с Xfce ))

Divius ★★
()
Ответ на: комментарий от Divius

Ну у меня на все свое субъективное мнение есть: xfce просто работает и не тормозит. Но скучно же - ничего нового, медленно развивается.
Если сравнивать xfce на ubuntu c xfce на fedora - тут уж ничего не скажу. Т.к. на федоре xfce использовал, а на убунте нет. Правда после того, что я увидел в kubuntu после других kde-ориентированных дистрибутивов, не удивлюсь если xfce спин лучше чем xubuntu.

vyazovoi ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.