В Fedora 18 принята новая "фича" - по умолчанию /tmp будет монтироваться как tmpfs, а не как папка на физическом разделе, как это сделано сейчас.

С точки зрения пользователей с большими объемами памяти, это полезное улучшение, однако не все так хорошо для пользователей с небольшими объемами ОЗУ (теперь это значит "меньше двух гигабайт"). Многие приложения интенсивно используют /tmp для хранения временных файлов, туда распаковываются архивы, производятся какие-то промежуточные операции. Это все, если примонтировать /tmp как tmpfs, будет занимать оперативную память. Но на этом претензии не заканчиваются. Участник Fedora, Richard W.M. Jones, составил краткий список проблем, с которыми придется столкнуться, что породило довольно длинную и интересную дискуссию. Также интересные претензии изложил участник Fedora Kevin Kofler (один из бывших участников FESCo) на странице обсуждения "фичи".

Проблема с хранением больших (временных) файлов в /tmp проистекает в основном из-за того, что приложения не используют стандарты FreeDesktop.org на директории для хранения временных файлов, для скачанных файлов из интернета, для документов и т.п. Об этом, и о том, как же правильно их использовать, написал статью в своем блоге Lennart Poettering.

Недавно, из-за проблем со сборкой и отсутствием желающих его поддерживать, NetBeans был удален из Fedora 17 и выше. К счастью, нашлись люди, которые не удовлетворились подобным положением, и был начат обратный процесс. Возможно, что скоро NetBeans вернется.

Основным мэйнтейнером NetBeans в Fedora был работник Sun (а впоследствии Oracle) Victor Vasilyev. К несчастью, Oracle, после приобретения обанкротившегося Sun, сократила многие OSS-проекты, что прямо или косвенно отразилось и на поддержке NetBeans в Fedora - Victor официально объявил, что прекращает быть мэйнтейнером этого и многих других Java-приложений. Частично NetBeans занялся инженер Red Hat Omair Majid, но у него не получилось поддерживать такой сложный продукт в актуальном состоянии. Ну, будем надеяться, что так или иначе NetBeans вернется в репозитории Fedora.

В вики проекта закончена работа над инструкцией по работе со сборочным сервисом Koji. Этот сервис используется для автоматической сборки пакетов в Fedora. Насколько мне известно, других подобных инструкций на русском языке нет.
Спасибо, bookwar за проделанную работу!
  • Koji проекта Fedora
  • Koji для сборки пакетов Russian Fedora

В вики проекта появилась новая статья, подробно описывающая работу с консольным многопротокольным IM-клиентом EKG2.

Информации о настройке и использовании программы ekg2 крайне мало, но постоянный участник нашей Jabber-конференции Fomalhaut сумел собрать разрозненные данные в не слишком большую, но ёмкую статью, которая может быть полезна всем любителям консольных приложений, вне зависимости от используемого дистрибутива.

Представители Fedora-Legal сообщили заинтересованным лицам, что последний из известных патентов на JBIG1 истекает 4го апреля 2012 года. В связи с этим начат процесс импортирования из RPMFusion необходимых библиотек для работы с этим стандартом сжатия, активно используемых в факс-аппаратах и сопутствующем программном обеспечении.

Сегодня вечером Кевин Раймонд (Kévin Raymond) сообщил в рассылке для переводчиков об обновлении содержимого сайта fedoracommunity.org, на котором собраны сайты всех региональных сообществ Fedora. Никаких кардинальных изменений, но тем не менее модули для перевода пополнились новыми строками. Поскольку материал для перевода очень простой и к тому же у меня выдался спокойный вечер, я быстренько перевела новые строки.

Эту заметку можно было бы не писать, потому что труд пустяковый, но мне хотелось отметить такую простую, но важную возможность помочь свободному проекту. Нужно только время и желание :) Конечно, далеко не все материалы для перевода просты, большиство требует знаний и подготовки. Но если внимательно следить за проектом, то всегда можно найти что-нибудь подходящее.

Так что присоединяйтесь!
(Если что, команда локализации тусуется здесь , а о том, как к ней присоединиться, написано здесь).

Приглашаем принять участие в завтрашнем тестировании работы Gnome Shell на системах без аппаратной поддержки 3D.

Тестирование очень простое: достаточно загрузить Live-образ и проверить, что запустился Gnome Shell.

К тестированию приглашаются:

  • старое x86-железо, в частности, процессоры не поддерживающие SSE2 (AMD Geode и pre-Athlon-64, Intel pre-Pentium-4 и т.п.),
  • ARM, PowerPC, и прочие не x86-архитектуры,
  • виртуальные машины, отличные от KVM,
  • старые видеокарты: Intel 8xx, Radeon pre-R300, NVIDIA pre-GeForce-6,
ну и, разумеется, все остальные участники, желающие посмотреть на Gnome практически 3.4 в действии.

Инструкция по участию: Test Day: 2012-03-29 Gnome Shell Software Rendering

Не забывайте отписываться о результатах на вики-странице!

Сегодня было объявлено о самороспуске управляющего комитета Glibc. Признав, что текущая модель управления разработкой уже не отвечает требованиям времени, было единогласно решено самораспуститься и передать управление разработкой в руки сообщества (благо оно вокруг Glibc сформировалось очень опытное). Мы ждем больше подробностей в ближайшее время, но уже сейчас отзывы очень положительные.

Phoronix сообщает, что начальная поддержка новейшей видеоархитектуры от NVIDIA - Kepler, была добавлена в Nouveau инженерами Red Hat и участниками проекта Fedora David Airlie и Ben Skeggs (который также активно участвует в проекте Debian) спустя считанные часы после официального анонса компанией-производителем. Пока, конечно, там ничего особо нет, но как минимум, карта теперь не будет работать под управлением совершенно примитивного vesa-драйвера. И это - без какой-либо техдокументации от NVIDIA. Сравните с ATI/AMD картами, которые, несмотря на имеющуюся документацию и официальную поддержку от производителя, получают ту же базовую функциональность спустя недели после официального анонса. Еще для сравнения с ATI - Intel стараются реализовывать поддержку оборудования в драйверах до его официального анонсирования.

Активный участник проекта Fedora и работник Red Hat, Matthew Garrett, продолжает продолжать серию статей про проблемы с UEFI. В этот раз он натолкнулся на удивительную проблему - UEFI позволяет прошивке wi-fi карты изменять память ядра напрямую, без участия процессора (DMA). Прочитайте статью целиком, это очень увлекательное чтение о том, как сложно было поймать за руку firmware за таким хулиганством. Кстати, предлагаем пофантазировать, какие возможности открываются с такой функциональностью UEFI.

Страницы