Russian Fedora

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

Content (65 страница со старыми записями)

Уроки программирования от Red Hat

Это архивная статья

Security-отдел Red Hat (не "безопасники" в отечественном смысле слова) опубликовал пост в своем блоке, посвященный проблеме с семейством функций strcpy, strcat, sprintf.
Увы, но несмотря на общее распространенное мнение, что эти функции использовать нежелательно, их все еще используют в разных проектах, в т.ч. и очень известных. Но проблема в том, что за просто так, просто перейдя на использование strncpy, strncat, strnprintf, программа не станет безопасной, волшебным образом лишившись buffer overflow. В заметке как раз и разбирают еще один типичный паттерн программирования, который теоретически (и порой, практически) приводит к buffer overflow. Обратите внимание, если вы разрабатываете на C, и если вы пока еще не видите проблем в данном фрагменте кода:
/* buff is a pointer to a buffer of blen characters. */
/* Note well: This example is now incorrect. */
char *cp = buff;
if ((n = snprintf(cp, blen, "AF=%d ", sau->soa.sa_family)) < 0) {
    Warn1("sockaddr_info(): buffer too short ("F_Zu")", blen);
    *buff = '';
    return buff;
}
cp += n,  blen -= n;

Заметили? Если нет, то прочитайте.

Glauber Costa рассказывает об OSv в Microsoft

Это архивная статья

На сайте Microsoft Research появились материалы с недавнего выступления Glauber Costa (Lord Glauber of Sealand), в котором он рассказывал про OSv. К сожалению, в Microsoft не осилили выложить видео для HTML5-совместимых браузеров, которым устаревший лет на 15 Internet Explorer, разумеется, никогда не будет, поэтому мы исправим ситуацию: Также доступны слайды презентации.

Не только Google Summer of Code

Это архивная статья

Образовательные программы не исчерпываются одним GSoC. Помимо него есть и другие интересные предложения.

Дружественный нам проект Qemu в своей ленте Google+ анонсировал, что дедлайн по участию в программе Outreach Program for Women Summer 2014 продлевается до 31 марта. Коммьюнити Qemu предлагает девушкам поучаствовать в доработке таких проектов, как Qemu, kvm и LibVirt.

В рамках этой программы студентка из Румынии, Teodora Băluţă предложила использовать QR-коды в Linux для oops-сообщений, о чем мы уже рассказывали. И это еще не все! Известный борец с мужским шовинизмом среди разработчиков ядра, инженер Intel, Sarah Sharp, с гордостью сообщает в своей ленте Google+, что еще две девушки сейчас работают над ядром в рамках этой программы.

Не знаем, есть ли тут корреляция, но по статистике работы над версией ядра 3.13 дифченки обогнали унылых ботанов из Google, NVidia, Oracle и ARM по количеству патчей, так что посмотрим, что будет дальше!

Еще немного будущих фич Fedora 21

Прошло немного времени после недавнего одобрения полудюжины фич будущей Fedora 21, а уже одобрили еще немного:

  • Доработка autofs - добавление парсера amd-формата (automount daemon). Проект am-utils заброшен, и autofs выглядит более перспективно, но, к сожалению, в autofs до сих пор не хватает некоторого функционала из am-utils, среди которого поддержка amd-формата. Вот его добавление и запланировано.

  • Полная поддержка чипов Allwinner sunxi (A10 / A13 / A20) (используются, например, в CubieTruck). Работа будет проведена в рамках Fedora ARM SIG. До сих пор Fedora на этой платформе работала благодаря ремиксу, а теперь планируется включить все нужное прямо в Fedora для ARM. К сожалению, поддержка графического режима работы пока не планируется.

  • Поддержка ведения журнала CUPS в journald, который традиционно пишет в файлики в /var/log/ Это часть более значительного проекта по унификации ведения журнала во всех приложениях и демонах. Мы уверены, что все OpenSource-приложения должны перестать писать в файлики, в syslog и т.п, и переходить на унифицированный фреймворк, предоставляемый systemd, т.е. journald. И мы надеемся, что вы в ближайшее время услышите еще о фичах из этой серии.

  • Очередное изменение во флагах GCC по умолчанию - включение *-Werror=format-security*.

    Как обычно, будет запланирована полная пересборка всего дерева. В качестве теста мы уже попробовали пересобрать дерево, и нашли почти две сотни проблем, часть из которых уже исправлена (и патчи, как обычно, уже отправлены или отправляются в апстрим). Типичное исправление выглядит довольно просто, но его нужно сделать, чем мы традиционно и занимаемся.

  • "Headless" Java. Одной из популярных претензий к большим языковым платформам, поставляемым в Fedora /RHEL, было "мне нужно запустить демон на %название_языка%, а он тянет за собой пол-иксов" (например, так жалуются на Erlang). Теперь появится возможность поставить Java без "десктопных" компонентов, таких, как X11 и PulseAudio.

  • System-wide jQuery. Сейчас у нас нет пакета с jQuery в дистрибутиве, поэтому каждое приложение, которое его использует, тянет его как bundled lib, и эта практика в общем случае приводит к куче проблем. Теперь, после включения пакета в дистрибутив, от мэйнтейнеров приложений, использующих jQuery, будет требоваться перейти на system-wide копию, либо получить от FESCo разрешение.

  • Поддержка конфигурационных файлов syslinux в U-boot.

    Традиционно, в ARM-системах, то, как надо загружать систему, "хардкодилось" прямо в U-boot, что, само собой, неудобно для дистрибутивов общего пользования. Поэтому было принято решение вынести платформо-специфичные настройки в отдельный файл конфигурации, который будет создаваться Anaconda или самим пользователем, и который будет использоваться U-boot во время загрузки. Возможно в будущем перейдут на спецификации для загрузчиков от FreeDesktop.org, но пока будет вот так.

  • Долгожданный X.org без прав суперпользователя.

    Эта фича стала возможно благодаря работе нашего коллеги, инженера Red Hat, Hans de Goede, о чем вы уже могли слышать.

Разумеется, это далеко еще не все - на подходе новые фичи.

GSoC 2014 - не упустите свой шанс

Это архивная статья

Некоторое время назад мы уже писали о Google Summer of Code 2014, в котором участвует как Fedora Project, так и многие другие дружественные нам проекты. И тем не менее, напомним ещё раз.

До окончания срока подачи заявок осталось всего ничего(два дня), однако по сообщениям с полей работы ещё много, а желающих не хватает. И ведь мы знаем, что часто камнем преткновения на пути к участию является вовсе не недостаток квалификации, а неверие в свои силы и в свои возможности. К сожалению, многие наши студенты оказываются слишком изолированы от открытого сообщества, чтобы правильно оценить свой технический уровень и перспективы.

Хватит раздумывать и сомневаться!
Прямо сегодня и прямо сейчас напишите письмо ментору приглянувшегося вам проекта. Расскажите, что вы умеете и чего хотите. И пусть ментор думает о том, подходите ли вы для решения поставленной задачи. Ведь очень может быть, что он ждёт именно вас.

Mark Shuttleworth против SBSA

Это архивная статья

Шумная толпа противников продвигаемой ARM Ltd / Linaro / Red Hat платформы SBSA неожиданно пополнилась Марком Шатлвортом. В своем блоге он недвусмысленно призвал отказаться от ACPI, приведя как возможную альтернативу Deviсe Tree. И по сути, и по форме, это открытый призыв к отказу от платформы SBSA, в продвижение и развитие которой уже вложены огромные ресурсы, и которая является единственным готовым вариантом разработки массовых серверных ARM-систем.

Мы уже не раз писали, как непросто создавать серверную платформу из кучи неряшливого кода, написанного без оглядки на перспективу ARM-разработчиками, так что некоторых из нас очень обеспокоило предложение Марка отказаться от уже готового решения в пользу, как всегда у Canonical, некоего несуществующего варианта. Даже основной противник SBSA, инженер Google, Olof Johansson вынужден был высказаться по поводу в своей ленте Google+.

Невольный виновник, наш коллега, Jon Masters ситуацию воспринял с юмором, и в своей ленте Google+ радуется попаданию в почетный список Open Source Tea Party, вместе с Lennart Poettering и другими разработчиками. Выходит так, что в этот почетный список заносят тех, кто фактически определяет развитие Open Source, так что это действительно почетно.

QR-коды в ядре!

Это архивная статья

После включения QR-кодов в systemd, настало время включить их и в ядро.

Teodora Baluta, студентка из Румынии, в списке рассылки LKML предложила первый вариант интеграции QR-кодов для kernel oops.

Мы с радостью поддерживаем начинание, т.к. обычно приходилось фоткать oops на телефон, и там зачастую все равно было ничего толком не разобрать. Конечно, в ближайшее время, благодаря kernel log renderer, их хотя бы можно будет прочитать целиком.

Интервью с Greg DeKoenigsberg, вице-президентом компании Eucalyptus Systems

Это архивная статья

Black Duck Software, компания-владелец широко известного в узких кругах ресурса Ohloh.net опубликовала интервью с Greg DeKoenigsberg, вице-президентом компании Eucalyptus Systems, бывшим лидером Fedora Project.

BDS: В каких областях вы видели наиболее быстрый переход на облака, и какова, по вашему мнению, движущая сила за этим переходом? GDK: Есть несколько факторов, которые ускоряют переход на приватные облака: компании часто достигают точки, где им требуется гораздо большая скорость, они хотят уменьшить расходы на публичные облака, или им нужно поддерживать совместимость. Частное облако, это естественное решение для таких бизнес-задач.

В Eucalyptus мы часто работаем с компаниями, и целыми отраслями, которые выросли на публичных облаках, и сейчас начали замечать, что их расходы растут быстрее, чем ожидалось. Это вгрызается в их прибыли и отвлекает айти-персонал, которые теперь вынуждены оценивать затраты на запуск каждого теста, вместо того, чтоб сосредоточиться на разработке новых технологий.

Если говорить о географических тенденциях, Северная Америка и Европа остаются лидерами, когда речь идет об использовании облачных платформ. Однако, появляются громадные перспективы в Индии, КНР, странах Латинской Америки. Так как эти регионы обычно необременены legacy-приложениями и устаревшими технологиями виртуализации, у них есть возможность догнать коллег в США и EMEA, возможно быстрее, чем думают в индустрии.

BDS: `На Ohloh Eucalyptus классифицируется как "very high activity” проект <https://www.openhub.net/p/eucalyptus>`__. Как вы вырастили и поддерживаете настолько сильное сообщество? GDK: Как почти в любом OSS-проекте, наиболее значимый вклад идет от группы power-пользователей, которые и упорно продвигают продукт вперед. В конечном счете, лучший способ вырастить разработчиков, это привлечь больше пользователей, а лучший способ заинтересовать больше пользователей, это как можно больше упростить развертывание и запуск продукта на уровне, достаточно для "поиграться". В случае Eucalyptus, также очень важно заметить, что у нас было преимущество следованию AWS (Amazon Web Services) API. Так как спецификации были уже определены в API, у Eucalyptus была возможность развиваться быстрее других проектов.

Наш высокий уровень соответствия AWS API также позволяет Eucalyptus претендовать на сообщество, гораздо более обширное, чем представленное лишь теми, кто вносит вклад в наш проект. Любой пользователь OSS-утилит для AWS может использовать те же утилиты для Eucalyptus – тем самым делая любого контрибутора этих утилит также, опосредованно, контрибутором Eucalyptus. Коммьюнити AWS огромно, и продолжает увеличиваться, и я горжусь той существенной (и продолжающей расти) ролью, которую мы играем в нем.

BDS: Сейчас много обсуждают "open API". С вашей точки зрения, есть ли какая-то информация, известная только посвященным, по этой теме? GDK: Сама идея “open API”, это отвлекающий маневр.

Провайдеры облачных приложений понимают, что предоставляя простой и стабильный API разработчикам, это сильный способ расширить их-же собственный функционал. Однако, любой API лишь настолько открыт, насколько открыто облачный сервис, к которому он подключает. "Open API" и OSS-утилиты для использования этого API, бессмысленны если сервис за этим API недостаточно открыт.

Ключевой вопрос, когда разговор заходит об APU и OSS, напрямую относится к облачному сервису компании – предоставляет-ли провайдер облачного приложения переносимость данных? Или может быть ваши данные наглухо заперты в нем?

fleet без systemd?

Это архивная статья

К сожалению, до сих пор есть еще дистрибутивы, использующиеся в "продакшене", и в которых нет systemd. Самый печальный пример, это RHEL 6 и производные. Конечно, еще есть Debian и Ubuntu, и кое-кто их выбирает порой и для какого-никакого серьезного использования. Конечно, оба отстающих сейчас начали движение, но в Debian, как обычно, будут тупить и тормозить (как обычно, это верующие в "Linux is about choice", любители в одиночку заняться kFreeBSD, шумные любители юниксвэя и прочие проблемные моменты коммьюнити), а Ubuntu перейдет на systemd лишь через два года. Но глядя на фейерверк технологий и решений уже выстраиваемых на базе systemd некоторым не терпится (и почему-то не хочется использовать для экспериментов современный дистрибутив).

В список рассылки проекта CoreOS пришел любитель Ubuntu и спросил, есть ли планы по интеграции fleet с альтернативными init-системами? Как вы помните, fleet, это надстройка над systemd и etcd, работающая, как init-система для целого кластера. Спрашивающий хотел бы задействовать ее для кластера, по неизвестной причине собранного на базе Ubuntu. Про списку рассылки прокатилась волна веселья, и когда восстановилось серьезное настроение, то ему порекомендовали подождать до Ubuntu 14.10, где systemd должен быть уже доступен, как опция. Хотя, конечно, мы все знаем, как плавают планы у Canonical.