Дискуссия вокруг systemd
Опубликовано 24.4.2012 23:17 пользователем Peter Lemenkov
Не прекращаются споры вокруг systemd - против него недавно высказался Mark Shuttleworth, на что тут-же среагировал в своей ленте Google+ Lennart Poettering. Следом в дискуссию вступил мэйнтейнер Fedora и один из ведущих разработчиков OLPC, Martin Langhoff. Его точка зрения заключается в том, что есть момент, о котором в общем никто и не спорит - внедрение systemd вызовет фундаментальное разделение на передовые дистрибутивы, использующие последние "фичи" Linux, и отстающих (экспериментирующих с ядрами от устаревших операционных систем, с различными Libc и пр.). Никто и не думал спорить, что cgroups, например, просто не получается задействовать в старой мешанине из BASH-скриптов без радикальных переделок всего. Опять-же нет сомнения, что Debian будет вынужден перейти на systemd, и это сильно ударит по Ubuntu, которые используют его, как upstream-проект - тут Martin и Lennart согласны.
К сожалению, "семеро одного не ждут", и если кто-то говорит, что его не интересует развитие ядра (а также, glibc, gcc, dracut, udev, GNOME, и которому вообще практически ничего не интересно, кроме неких внутрикорпоративных поделок), то непонятно, как можно ожидать, что разработчики будут подстраиваться под его нужды? Опять-же, понятно, что жертвовать Linux-специфичными вещами ради совместимости с устаревшими операционными системами - неразумно. Не для того в развитие именно Linux (а не Amiga, BSD или BeOS) вкладываются ресурсы, чтоб потом ждать, пока новые фичи реализуют догоняющие. Но так живет Open Source - люди делают то, что им надо, или за что им заплатили. Но недовольные всегда могут пойти своей дорогой и сделать что-то свое. Если, конечно, квалификации и сил у критиков хватит.
К сожалению, "семеро одного не ждут", и если кто-то говорит, что его не интересует развитие ядра (а также, glibc, gcc, dracut, udev, GNOME, и которому вообще практически ничего не интересно, кроме неких внутрикорпоративных поделок), то непонятно, как можно ожидать, что разработчики будут подстраиваться под его нужды? Опять-же, понятно, что жертвовать Linux-специфичными вещами ради совместимости с устаревшими операционными системами - неразумно. Не для того в развитие именно Linux (а не Amiga, BSD или BeOS) вкладываются ресурсы, чтоб потом ждать, пока новые фичи реализуют догоняющие. Но так живет Open Source - люди делают то, что им надо, или за что им заплатили. Но недовольные всегда могут пойти своей дорогой и сделать что-то свое. Если, конечно, квалификации и сил у критиков хватит.
Улучшения в видеодрайвере для Intel Poulsbo/GMA500
Опубликовано 24.4.2012 22:49 пользователем Peter Lemenkov
Известный пользователь (и бывший мэйнтейнер) Fedora, Alan Cox в своей ленте Google+ анонсировал серьезные улучшения в драйвере для видеоадаптеров семейства Poulsbo / GMA500. Ситуация с ними была очень плохая, так как этот видеоадаптер не является собственной разработкой Intel, а лицензирован у сторонней компании, которая не разрешила Intel опубликовать исходные тексты драйвера. К сожалению, он оказался довольно распространен. Так или иначе, коммьюнити собрало вместе и написало костяк драйвера, который хоть как-то работал. Инженеры Intel вынуждены были не прикасаться к исходникам на данном этапе, чтоб не дать повода для судебного иска о разглашении конфиденциальной информации, а смогли присоединиться лишь на финальном этапе.
Сейчас ситуация гораздо лучше, а с последним улучшение будет совсем хорошей. Alan надеется, что все последние улучшения будут доступны уже в скоро выходящей Fedora 17 - работающий suspend/resume, реализованное управление подсветкой, прямо сейчас ведутся работы по включению HDMI и исправлено множество ошибок. Ждем релиза!
Сейчас ситуация гораздо лучше, а с последним улучшение будет совсем хорошей. Alan надеется, что все последние улучшения будут доступны уже в скоро выходящей Fedora 17 - работающий suspend/resume, реализованное управление подсветкой, прямо сейчас ведутся работы по включению HDMI и исправлено множество ошибок. Ждем релиза!
Fedora ищет нового Program Manager
Опубликовано 20.4.2012 15:04 пользователем Peter Lemenkov
После того, как Robyn Bergeron повысили до лидера проекта, у нее не осталось времени на приглядывание за "фичами" проекта, за тем, чтоб все было вовремя, не нарушало принципов и правил, чтоб release engineering проходил, как запланировано. А раз так, то проекту понадобился новый менеджер. Более подробно и неформально Robyn описала фронт работ у себя в блоге, а более формально - тут. Работа интересная и увлекательная, подразумевает общение с угрюмыми и вечно злыми нердами. Если вы считаете, что подходите, то шлите резюме. Если знаете того, кто подходит и кто может согласиться - шлите ему ссылку. Ну а мы с интересом продолжим следить за интригой выбора нового менеджера.
"The spice must flow..."
"The spice must flow..."
Текущая ситуация с JBoss в Fedora
Опубликовано 20.4.2012 14:45 пользователем Peter Lemenkov
Один из разработчиков JBoss, Marek Goldmann, в своем блоге подвел итоги прошедшего недавно тестового дня JBoss Application Server в Fedora. Почти все тесты были успешными, и удалось заметить лишь одну ошибку, которая уже исправляется - можно считать, что в целом оно работает!
Парни провели просто огромную заботу - упаковали и включили в Fedora сто с лишним библиотек и приложений. Это было очень непросто, так как традиционно Java-приложения не отличаются высоким уровнем внимания к вопросам их распространения. Например, некоторые (не буду указывать конкретных имен) JBoss разработчики считают, что достаточно того, что они поставляют все, что нужно, в одном большом ZIP-архиве (напоминаю, что именно Java-приложения приносят наибольшее количество проблем при соблюдении правила No Bundled Libs).
Парни провели просто огромную заботу - упаковали и включили в Fedora сто с лишним библиотек и приложений. Это было очень непросто, так как традиционно Java-приложения не отличаются высоким уровнем внимания к вопросам их распространения. Например, некоторые (не буду указывать конкретных имен) JBoss разработчики считают, что достаточно того, что они поставляют все, что нужно, в одном большом ZIP-архиве (напоминаю, что именно Java-приложения приносят наибольшее количество проблем при соблюдении правила No Bundled Libs).
Вышел RFRemix 17-Beta
Опубликовано 17.4.2012 16:27 пользователем Tigro
Сегодня выходит Fedora 17-Beta (Beefy Miracle). Одновременно мы выпускаем RFRemix 17-Beta. У нас было желание обозвать дистрибутив RFRemix 17-Beta (Pelmen') с логотипом, но пока эти мысли в доработке. Основные новшества 17 перечислены на wiki проекта Fedora.
Дистрибутив RFRemix 17-Beta основан на development ветке Fedora 17, RPM Fusion и репозитории Russian Fedora. Из коробки доступна поддержка Adobe Flash, различных форматов мультимедиа, проприетарные драйвера Nvidia.
Основные отличия от Fedora:- Наличие быстрых сценариев для установки в меню инсталлятора;
- Live диски имет размер больше 700 мб, что позволило положить на них больше полезных пакетов;
- В установщик добавлены сценарии установки различных рабочих столов (GNOME, KDE, XFCE, LXDE, Enlightment и минимальные установки GNOME и KDE;
- Поддержка репозиториев RPM Fusion и Russian Fedora в установщике;
- Добавлена возможность выбора различных клавиатурных комбинаций для смены раскладок (для русского языка). По умолчанию используется Alt+Shift;
- В Firstboot добавлен дополнительный экран для быстрой настройки системы (выбор между KDM и GDM, включение некоторых полезных настроек в GNOME, включение комбинации Ctrl+Alt+Backspace и др.;
- Система мониторинга Smolt отсылает в качестве названия дистрибутива не Fedora, а RFRemix;
- Пакет Freetype собран с поддержкой subpixel rendering;
- Словарь hunspell для русского языка содержит как русские, так и английские слова, что позволяет проверять орфографию сразу на двух языках, когда приложение этого не позволяет;
- В GNOME используется шрифт Cantarell с поддержкой кириллицы.
Для загрузки доступны установочные DVD образы, Live-образы с GNOME, KDE, LXDE, XFCE. Загрузка возможна через зеркала и торренты.
- Установочные диски [ i686 ] [ x86_64 ]
- Образы Live [ i686 ] [ x86_64 ]
- Торренты
Финальная версия RFRemix 17 ожидается 22 мая.
20 апреля. МГТУ им. Баумана. Конференция «Открытые технологии в инженерном деле»
Опубликовано 17.4.2012 14:18 пользователем mama-sun
20 апреля 2012 года (т.е. уже в эту пятницу) состоится еще одно мероприятие. На этот раз более студенческое — конференция «Открытые технологии в инженерном деле».
Конференция будет состоять из двух параллельных секций:
В этом году от одного из участников проекта также ожидается доклад про технологии Red Hat в больших системах — кластерах, гридах, облаках и пр.
Сайт конференции - oskonf2012.bmstu.ru
Проход на территорию университета строго по пропускам при предъявлении паспорта => нужна предварительная регистрация. Кому интересно, не откладывайте. Регистрируйтесь прямо сейчас.
Время и место: 20 апреля 2012 года, 15:00, МГТУ им. Н.Э. Баумана, 316 ауд. (как добраться)
Конференция будет состоять из двух параллельных секций:
- Секция об открытых операционных системах, программировании, о сетях и технологиях виртуализации.
- Секция, посвященная прикладным инженерным программам, таким как: KiCAD, libreCAD, FreeCAD, Elmer, openFOAM, GNU/Octave, SciLab, Maxima, LaTeX, openSCADA
В этом году от одного из участников проекта также ожидается доклад про технологии Red Hat в больших системах — кластерах, гридах, облаках и пр.
Сайт конференции - oskonf2012.bmstu.ru
Проход на территорию университета строго по пропускам при предъявлении паспорта => нужна предварительная регистрация. Кому интересно, не откладывайте. Регистрируйтесь прямо сейчас.
Время и место: 20 апреля 2012 года, 15:00, МГТУ им. Н.Э. Баумана, 316 ауд. (как добраться)
Расшифровка интервью с Яном. Требуется помощь!
Опубликовано 16.4.2012 15:02 пользователем mama-sun
В данный момент участниками проекта ведется работа по расшифровке интервью с Яном Вилдбоером, посетившим Москву на прошлой неделе. И нам требуется помощь. Если у вас есть время и знание английского, вы можете сделать хорошее дело :)
Координируемся здесь. Вы можете взять на себя кусок видео той длительности, которая вам по силам. Главное - вписывайтесь в таблицу.
Координируемся здесь. Вы можете взять на себя кусок видео той длительности, которая вам по силам. Главное - вписывайтесь в таблицу.
Работы по исправлению регрессии в модуле ath9k в ядре 3.3.1
Опубликовано 15.4.2012 14:21 пользователем Peter Lemenkov
Некоторые пользователи после обновления на ядро 3.3.1 обнаружили невозможность подключиться в Wi-Fi после выхода из гибернации, если используется модуль ath9k. Проблему заметили многие, в т.ч. и в Fedora. Сообщаем, что ошибка уже отловлена и исправлена и участник Fedora и инженер Red Hat John Linville ее уже включил в ядро (будет доступно с версии 3.3.2).
В общем, это досадный рабочий момент, ничего особенного - всяко бывает. Однако по его итогам разгорелась нешуточная дискуссия, с которой будет интересно ознакомиться тем, кто еще не знает, как же ведутся обсуждения среди kernel-разрабочиков. Ознакомьтесь :).
В общем, это досадный рабочий момент, ничего особенного - всяко бывает. Однако по его итогам разгорелась нешуточная дискуссия, с которой будет интересно ознакомиться тем, кто еще не знает, как же ведутся обсуждения среди kernel-разрабочиков. Ознакомьтесь :).
Часть функциональности Gnome, KDE и Xfce переносят в systemd
Опубликовано 14.4.2012 18:15 пользователем Peter Lemenkov
Продолжается победное наступление systemd на дистрибутивы. Основной мэйнтейнер Lunar Linux и сотрудник Intel, работающий над проектом Tizen, Auke Kok в своей ленте Google+ анонсировал революционное изменение, которое он уже представил на рассмотрение разработчикам systemd.
Сначала, он упомянул, что Tizen также переходит с устаревшего SysV на systemd, а затем он рассказал о его нововведении, которое создано в рамках внедрения systemd инженерами Intel совместно с инженерами Samsung - первом варианте изменений, которые предназначены для управления пользовательскими сессиями не на уровне неких демонов, встроенных в Desktop Environment (gnome-session, startxfce4 и прочих), а с помощью systemd. Он добился значительного ускорения и повышенной надежности загрузки (лучший контроль компонентов).
Какова же проблема, которую он решает? Изначально, в устаревшем SysV, не было никакой возможности запустить рабочее окружение пользователя. Процесс загрузки выглядит так - init от суперпользователя запускает скрипты в /etc/init.d, затем запускает desktop manager (GDM, KDM, XDM или иные). Пользователь вводит пароль и логин, и desktop manager известным лишь ему образом запускает последовательность действий для запуска рабочего окружения (на этом этапе init уже никак не задействован). Таким образом, у нас есть минимум два компонента, которые запускают сервисы в системе - init и еще один на каждый Desktop Envionment, доступный на машине пользователя. Все это приводит к дублированию правил запуска для различных desktop manager, написанию неких менеджеров сессий и прочей лишней работе, результаты которой, к тому же, еще и содержат ошибки, порой трудноуловимые.
С появлением основанного на принципах философии Unix, специализированного изолированного компонента для запуска системы, который учитывает различные внешние события (он, как и полагается такому компоненту, делает только одно и делает это хорошо - следит за запуском и состоянием сервисов), оказалось можно отделить компоненты запуска рабочего окружения от Desktop Environment и сделать их полностью независимыми (и зависимыми от systemd, конечно). Auke написал первый прототип, который уже заслужил теплый отзыв от Greg Kroah-Hartman, оставленный им в его ленте Google+.
Что ж, вслед за уже почти закончившимся повальным переходом дистрибутивов на systemd, будем ожидать переходов Desktop Environment на него-же. А пользователям дистрибутивов, которые все еще по каким-то причинам не начали переход на systemd, стоило бы потормошить своих мэйнтейнеров.
Сначала, он упомянул, что Tizen также переходит с устаревшего SysV на systemd, а затем он рассказал о его нововведении, которое создано в рамках внедрения systemd инженерами Intel совместно с инженерами Samsung - первом варианте изменений, которые предназначены для управления пользовательскими сессиями не на уровне неких демонов, встроенных в Desktop Environment (gnome-session, startxfce4 и прочих), а с помощью systemd. Он добился значительного ускорения и повышенной надежности загрузки (лучший контроль компонентов).
Какова же проблема, которую он решает? Изначально, в устаревшем SysV, не было никакой возможности запустить рабочее окружение пользователя. Процесс загрузки выглядит так - init от суперпользователя запускает скрипты в /etc/init.d, затем запускает desktop manager (GDM, KDM, XDM или иные). Пользователь вводит пароль и логин, и desktop manager известным лишь ему образом запускает последовательность действий для запуска рабочего окружения (на этом этапе init уже никак не задействован). Таким образом, у нас есть минимум два компонента, которые запускают сервисы в системе - init и еще один на каждый Desktop Envionment, доступный на машине пользователя. Все это приводит к дублированию правил запуска для различных desktop manager, написанию неких менеджеров сессий и прочей лишней работе, результаты которой, к тому же, еще и содержат ошибки, порой трудноуловимые.
С появлением основанного на принципах философии Unix, специализированного изолированного компонента для запуска системы, который учитывает различные внешние события (он, как и полагается такому компоненту, делает только одно и делает это хорошо - следит за запуском и состоянием сервисов), оказалось можно отделить компоненты запуска рабочего окружения от Desktop Environment и сделать их полностью независимыми (и зависимыми от systemd, конечно). Auke написал первый прототип, который уже заслужил теплый отзыв от Greg Kroah-Hartman, оставленный им в его ленте Google+.
Что ж, вслед за уже почти закончившимся повальным переходом дистрибутивов на systemd, будем ожидать переходов Desktop Environment на него-же. А пользователям дистрибутивов, которые все еще по каким-то причинам не начали переход на systemd, стоило бы потормошить своих мэйнтейнеров.
"Бинарные логи" в ядре
Опубликовано 14.4.2012 17:28 пользователем Peter Lemenkov
Продолжаем тему о структурированном журналировании. Jonathan Corbet пишет на LWN, что систему журналирования ядра Linux вскоре ожидают сильные изменения (к сожалению, статья за paywall). Разработчик udev и systemd Kay Sievers предложил радикально изменить поведение журналируемой подсистемы ядра.
Напомню, какова-же одна из проблем, которую решает проект Lumberjack. Изначально, из-за малого количества разработчиков и недоговоренности о стандартах, было решено, что журнал будет содержать просто текстовые строчки сообщений (например, "[system] Successfully activated service 'org.freedesktop.PolicyKit1'"). Человек в них может узнать о каких-то событиях, но роботы-то читать не умеют! Им нужна заранее заданная структура сообщений, возможно, что и не человекочитаемая (так напугавшие всех "бинарные логи"), и поэтому каждый или почти каждый сисадмин имеет свои скриптики, которые приходится постоянно переписывать, чтоб извлекать какие-то данные из журнала. Было предложено ввести структурирование журнала - отделить человеко-читаемые данные от тех, что нужны роботам. На уровне user-space это вылилось в проект Lumberjack, и, видимо, стоит ожидать скорого повсеместного внедрения "бинарных логов" в дистрибутивы. К сожалению, в ядре до сих пор журнал ведется с помощью произвольно сформированных строк текста.
Предложение Kay Sievers содержит три пункта. Первое, это вести журнал внутри ядра не в виде некоего буфера фиксированной длины, а в виде очереди объектов. Это даже немного сэкономит память в ряде случаев и поможет предотвратить повреждение сообщений при переполнении очереди (сейчас просто перезаписывается память, занятая старыми сообщениями, что приводило к повреждению некоторых перед отправкой в логгер, работающий на уровне пользователя). Второе, это возможность присовокупить некоего KV-словаря к каждому сообщению (это и есть то самое, что будет читаться роботами - systemd, rsyslog, syslog-ng и т.п.). И, наконец, третье, это радикальное изменение поведения /dev/kmsg. Сейчас, максимум, на что оно годно, это для добавления своего сообщения к журналу событий ядра. Sievers переработал его так, что из него можно будет читать ленту событий ядра программами типа cat и less. Поддерживается одновременное чтение событий несколькими источниками. Таким образом, это устройство становится основным источником событий ядра, которое будет удобно разбирать, и которое будет гарантированно доставлять сообщения в целости или сообщать, что некое-количество сообщений было потеряно.
В целом изменение благосклонно встречено kernel-хакерами. Даже Linus Torvalds высказался одобрительно. Стоит ожидать частичного появления этой функциональности в ядре 3.4, и окончательного - в ядре 3.5.
Напомню, какова-же одна из проблем, которую решает проект Lumberjack. Изначально, из-за малого количества разработчиков и недоговоренности о стандартах, было решено, что журнал будет содержать просто текстовые строчки сообщений (например, "[system] Successfully activated service 'org.freedesktop.PolicyKit1'"). Человек в них может узнать о каких-то событиях, но роботы-то читать не умеют! Им нужна заранее заданная структура сообщений, возможно, что и не человекочитаемая (так напугавшие всех "бинарные логи"), и поэтому каждый или почти каждый сисадмин имеет свои скриптики, которые приходится постоянно переписывать, чтоб извлекать какие-то данные из журнала. Было предложено ввести структурирование журнала - отделить человеко-читаемые данные от тех, что нужны роботам. На уровне user-space это вылилось в проект Lumberjack, и, видимо, стоит ожидать скорого повсеместного внедрения "бинарных логов" в дистрибутивы. К сожалению, в ядре до сих пор журнал ведется с помощью произвольно сформированных строк текста.
Предложение Kay Sievers содержит три пункта. Первое, это вести журнал внутри ядра не в виде некоего буфера фиксированной длины, а в виде очереди объектов. Это даже немного сэкономит память в ряде случаев и поможет предотвратить повреждение сообщений при переполнении очереди (сейчас просто перезаписывается память, занятая старыми сообщениями, что приводило к повреждению некоторых перед отправкой в логгер, работающий на уровне пользователя). Второе, это возможность присовокупить некоего KV-словаря к каждому сообщению (это и есть то самое, что будет читаться роботами - systemd, rsyslog, syslog-ng и т.п.). И, наконец, третье, это радикальное изменение поведения /dev/kmsg. Сейчас, максимум, на что оно годно, это для добавления своего сообщения к журналу событий ядра. Sievers переработал его так, что из него можно будет читать ленту событий ядра программами типа cat и less. Поддерживается одновременное чтение событий несколькими источниками. Таким образом, это устройство становится основным источником событий ядра, которое будет удобно разбирать, и которое будет гарантированно доставлять сообщения в целости или сообщать, что некое-количество сообщений было потеряно.
В целом изменение благосклонно встречено kernel-хакерами. Даже Linus Torvalds высказался одобрительно. Стоит ожидать частичного появления этой функциональности в ядре 3.4, и окончательного - в ядре 3.5.
Страницы
- « первая
- ‹ предыдущая
- …
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- …
- следующая ›
- последняя »
Обменная кнопка проекта: 