Russian Fedora - сообщество русскоязычных участников международного проекта Fedora

Недавно вышедший RERemix 6.2 включал Live-образы, размер которых был больше 700 Мб. Подобную практику мы переносим и на RFRemix для образов с GNOME и KDE. К сожалению постоянно приходится очень долго возиться и чем-то жертвовать, а то и вычищать даже нужные пакеты, чтобы только уместиться в эти злосчастные 703 чистых мегабайта.

Проблема скорее всего скажется на различных старых компьютерах и ноутбуках, у которых нет DVD ридера и не поддерживается загрузка с USB. Для таких машин останется возможность загрузки по сети, а также живые образы с XFCE и LXDE, которые мы будем держать в рамках 700 Мб.

Проект по созданию сверхдешевого компьютера Raspberry Pi рекомендовал для использования на уже выпущенных устройствах специализированный remix Fedora. Сейчас используется уже довольно старая версия Fedora - 14, но планируется выпуск версии 17 для ARM одновременно с версиями для x86/x86_64.

Нельзя не отметить широкое вовлечение студентов в процесс подготовки дистрибутива. В отличие от российских реалий, где "школота" и "студентота" в рамках изучения IT заняты довольно бессмысленными задачами типа решения на паскале систем линейных уравнений, то студенты США занимались практически полезным и востребованным экономикой делом - адаптировали под руководством известных хакеров и айти-специалистов наиболее высокотехнологичный Linux-дистрибутив на набирающую популярность архитектуру и ряд существующих систем в рамках архитектуры. Т.е. они были заняты platform engineering в чистом виде. В результате, они уже получают предложения от заинтересованных компаний о трудоустройстве, которые, в свою очередь, получают в качестве сотрудников не пустоголовых болванчиков, по быстрому списавших и "спихнувших" несколько "лаб" по информатике, а обладающих практическими навыками специалистов.

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

От лица всех мужчин, пользователей и разработчиков, мы поздравляем наших любимых женщин с международным праздником 8-го марта!
Вы, наши дорогие дамы, олицетворяете уют нашего сообщества. Само существование проекта невозможно без вас!
Мы очень рады, что вы у нас есть!

Еще не утихли срачи^W продуктивные обсуждения на Linux.org.ru инициативы небезызвестного Lennart Poettering по замене syslog на Journald, а ведущие разработчики решений на базе стандарта RFC 5424 (syslog) уже встретились, чтобы лицом к лицу ответить на суровую критику от Poettering'а.

На прошедшем недавно Fedora Developer's Conference в чешском городе Брно встретились Rainer Gerhards, основной разработчик rsyslog, Balazs Scheidler, основной разработчик syslog-ng, William Heinbockel, один из соавторов стандарта CEE со стороны Mitre, Lennart Poettering, Steve Grubb, нынешний мэйнтейнер auditd, работник Red Hat и участник проекта Fedora. Были и еще некоторые заинтересованные лица из числа участников Fedora Project.

По результатам встречи было признано очевидное (о чем и говорил Lennart Poettering) - система ведения журнала в Linux действительно в печальном наколеночном состоянии, негодном для серьезного использования в сложных системах без значительной доработки и написания кучи скриптов на shell, perl, sed/awk и python с php. Например, нет стандартов на хранение бинарного журнала (в базе данных, например), нет формата на структуру сообщений (почитайте man 3 syslog - там довольно исчерпывающая информация о его возможностях). Основной проблемой служит то, что подавляющее большинство разработчиков в своих программах просто задействуют старый интерфейс BSD syslog, который оперирует лишь с текстовыми строками, получаемыми от приложения (отдельный разговор, это то, как в эти строки вставить бинарные данные, и что будет потом). Т.е. основная проблема с журналированием в Linux, это ты, ленивый разработчик! С другой стороны, те разработчики, которые упираются в примитивность традиционного текстового BSD syslog, из-за слабой информированности о возможностях современных syslog-демонов, просто берут сторонние (или создают свои - Journald) нестандартные решения для ведения журналов - тысячи их!

В результате, даже в популярных Linux-дистрибутивах сразу работают несколько логгеров - один из популярных syslog-демонов, работающий хорошо если на 10% своих возможностей, и еще пара-тройка средней паршивости и отлаженности (а теперь еще будет работать и Journald). Например, отдельный логгер для auditd и сообщений selinux, отдельная подсистема для Java-приложений (Log4J, который может использовать syslog, а может и нет). Не стоит и говорить, что практически любое большое приложение (как принято говорить, Enterprise уровня) использует свою систему ведения журналов, т.к. его разработчики скорее всего уже имеют печальный опыт общения с примитивным void syslog(int priority, const char *format, ...);

С 2007 года существует проект CEE, от Mitre, в рамках которого добиваются синхронизации стандарта на формат сообщений журналирования, и проект уже привлек внимание внушительного количества заинтересованных компаний, однако большинство oткрытых программ, написанных энтузиастами, не использует наработок этого и других проектов, в результате чего журналирование в Linux дистрибутивах сильно отстает от журналов, ведущихся в проприетарных продуктах и операционных системах, разработчики которых внимательнее прислушиваются к своим пользователям. Опять-же, посмотри в зеркало, ленивый opensource девелопер!

Учитывая эти и другие факты, на встрече было решено создать совместный проект - Lumberjack, в рамках которого будет проводиться популяризация и внедрение в популярные Linux дистрибутивы стандартов CEE, RFC 5424 и наработок Lennart Poettering. В рамках проекта предложена трехуровневая система, в которой внизу будет находиться бэкенд для физического ведения журнала (традиционные текстовые файлы, база данных, сетевое хранилище и т.п.), в середине будет сам демон журналирования, а сверху будет одновременно доступно несколько вариантов API - традиционный, для примитивного журналирования, как было принято в простеньких системах в конце 1980х, и структурированные логи событий, как это требуется для сложных систем второй декады XXI века. У проекта уже есть подпроект - ELAPI, библиотека, упрощающая внедрение CEE-журналирования в приложения. Она развивается Red Hat и участниками Fedora.

Ждите скоро в Fedora, а затем и в других дистрибутивах!