ПоискПочтаДискКалендарьДеньгиМой КругФотки
Войти


Друзья, 28 июля мы закрываем Я.ру. Приносим вам свои извинения.

(^_^)

клуб  

Присоединившись к клубу, вы сможете вывешивать фотки в галерее и создавать новые темы для обсуждения. Обсуждаемые темы клуба будут появляться на странице «Что нового».
Вступить в клуб
Какую связку ОС Вы используете?
О клубе
изменено 29 мая 2012 года, в 19:36
Клуб для пользователей операционной системы Fedora Linux.
Новости проекта на  http://ru.fedoracommunity.org
В клубе действуют правила.
Правила клуба

В клубе запрещено:

  1. Писать сообщения, противоречащие законодательству РФ.
  2. Оскорблять других участников клуба.
  3. Размещать материалы эротического характера.
  4. Размещать рекламу.
  5. Размещать записи, не соответствующие теме клуба.

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

записи по месяцам · меткам · типам

выделить все / снять выделение

Показать
Изрыкатель рычательств поделился ссылкой
21 марта, 13:33
(^_^)
Еще немного будущих фич 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, о чем вы уже могли слышать.


Разумеется, это далеко еще не все - на подходе новые фичи.
Изрыкатель рычательств поделился ссылкой
19 марта, 04:03
(^_^)
GSoC 2014 - не упустите свой шанс
( читать дальше )
Некоторое время назад мы уже писали о Google Summer of Code 2014, в котором участвует как Fedora Project, так и многие другие дружественные нам проекты. И тем не менее, напомним ещё раз.

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

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

Изрыкатель рычательств поделился ссылкой
18 марта, 20:41
(^_^)
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, так что это действительно почетно.
Изрыкатель рычательств поделился ссылкой
18 марта, 12:47
(^_^)
QR-коды в ядре!
После включения QR-кодов в systemd, настало время включить их и в ядро.

Teodora Baluta, студентка из Румынии, в списке рассылки LKML предложила первый вариант интеграции QR-кодов для kernel oops. Мы с радостью поддерживаем начинание, т.к. обычно приходилось фоткать oops на телефон, и там зачастую все равно было ничего толком не разобрать. Конечно, в ближайшее время, благодаря kernel log renderer, их хотя бы можно будет прочитать целиком.
Изрыкатель рычательств поделился ссылкой
изменено 14 марта, в 21:53
(^_^)
P.haul научился мигрировать OpenVZ контейнеры
P.haul только вышел, а уже начал обрастать функционалом. В ленте Google+ проекта появился анонс, что теперь доступна Live-миграция контейнеров OpenVZ.
Изрыкатель рычательств поделился ссылкой
изменено 14 марта, в 21:53
(^_^)
Интервью с 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” проект. Как вы вырастили и поддерживаете настолько сильное сообщество?

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, напрямую относится к облачному сервису компании – предоставляет-ли провайдер облачного приложения переносимость данных? Или может быть ваши данные наглухо заперты в нем?
Изрыкатель рычательств поделился ссылкой
изменено 14 марта, в 21:53
(^_^)
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.
Изрыкатель рычательств поделился ссылкой
изменено 14 марта, в 08:40
(^_^)
Будущие фичи Fedora 21
( читать дальше )
График выхода Fedora 21 пока только утряхивается, а фичи будущего релиза уже начали появляться. Неопределенность с графиком привела к тому, что большое количество фич до сих пор не было анонсировано, и в списке находились лишь известные с октября и ноября 2013 года базовая поддержка OpenCL в Fedora 21, Python3 по умолчанию и обновление Python3 до версии 3.4. Но определенность позволила начать планировать свои возможности, и наши коллеги сразу предложили ряд фич:



На подходе еще пачка фич.
Изрыкатель рычательств поделился ссылкой
изменено 13 марта, в 22:11
(^_^)
Есть ли будущее у OLPC?
( читать дальше )
Над проектом OLPC сгущаются тучи. В блоге независимого коммьюнити вокруг OLPC появилась заметка, в которой предвещается скорая кончина проекта. Среди признаков надвигающейся гибели проекта выделяют окончание гарантийного срока, сложности с поиском запчастей, отсутствие поддержки со стороны производителя, отсутствие программистов, продолжающих развивать ПО для проекта, уход Nicholas Negroponte, что приводит к падению энтузиазма у участников коммьюнити (что, в свою очередь, можно считать еще одним показателем скорой гибели проекта). Заметка быстро стала довольно обсуждаемой, и к вышеуказанным признакам прибавили недавнюю продажу имущества головной компании, после которого осталось несколько миллионов долларов долгов.

Появились и несогласные с утверждением о скорой гибели. Giulia D'Amico, Vice President of Business Development, не согласилась с тем, что проект вот-вот загнется. Новая модель XO-4, которая работает под управлением Android, уже поступает потребителям - 50 тысяч устройств прямо сейчас поставляются в Уругвай. Другие комментаторы считают, что проект необходимо мерять не сухим языком бухгалтерии, а его культурным и социальным воздействием. OLPC предвосхитил ряд концепций, и многие ныне реализованные идеи возможно даже и не обдумывались бы всерьез без примера OLPC перед глазами. Высказались и люди, которые до сих пор поддерживают проекты, построенные на базе оборудования OLPC. Так что не все так однозначно.

Для нас OLPC навсегда будет примером того, что можно сделать с помощью нашего коммьюнити. Операционная система первоначальных релизов базировалась на Fedora, благодаря чему статистически наш дистрибутив одно время стал самым популярным предустановленным Linux-дистрибутивом на ноутбуках, позднее уступившим пальму первенства ChromeOS. Другие проекты предустановки Linux на ноутбуках так и не вышли за пределы пилотных партий и фотосессий в магазинах второго эшелона в странах третьего мира. Проект послужил одним из катализаторов разработки GNOME 3, заложил ряд новых концепций в интерфейсе пользователя (Sugar), и впервые реализовал на практике казавшуюся уже несбыточной мечту о полностью свободном ноутбуке.

Если действительно проект вот-вот закроется, то нам будет не хватать этого малого, крутящегося под ногами. Но чтобы ни случилось, наследие проекта OLPC будет жить, и в нем всегда будет присутствовать наш вклад - наш труд, наши идеи, и наши чувства.
Изрыкатель рычательств поделился ссылкой
изменено 13 марта, в 06:34
(^_^)
BLKDISCARD, BLKZEROOUT, BLKDISCARDZEROES, BLKSECDISCARD
( читать дальше )
Rich WM Jones обращает наше внимание на ряд новых ioctl - BLKDISCARD, BLKZEROOUT, BLKDISCARDZEROES, BLKSECDISCARD. Ну, новые они относительно - в ядре с 2010 года, а поддержка в userspace-программах начала появляться недавно (например, в util-linux добавили примерно год назад), т.е., например, в Debian они будут доступны года с 2017.

Rich заметил, что данные ioctl никак не документированы, хотя наши коллеги уже упоминают их в своих докладах (например, Paolo Bonzini на прошедшем недавно DevConf) и решил исправить положение, перечислив их функциональность и ограничения (если есть):

  • BLKDISCARD - требует от блочного устройства удалить все блоки, попадающие в указанный диапазон. Есть ограничение - блочное устройство может игнорировать этот ioctl. Что будет прочитано после выполнения этой функции никак не стандартизируется, и может заполнить указанный диапазон нулями, случайными числами, или просто проигнорировать запрос целиком, оставив все, как есть.
  • BLKZEROOUT - то же, что и BLKDISCARD, но требует заполнить указанный диапазон нулями. Ядро вынуждено реализовать этот функционал само, и устройство тут никак не помогает.
  • BLKDISCARDZEROES - запрашивает у устройства, будет ли оно обнулять секторы, удаленные при помощи вызова BLKDISCARD. Если ответ положительный, то BLKZEROOUT не требуется.
  • BLKSECDISCARD - то же, что и BLKDISCARD, но без какой-либо возможности восстановления. Обязано вернуть EOPNOTSUPP, если устройство не в состоянии этого сделать.


В RHEL 6.5 и выше, утилита blkdiscard уже доступна в составе пакета util-linux-ng.
β-версия

 

Что получается:    изменить 
Подписаться на комментарии к записи

Получать уведомления о всех ответах в этом обсуждении.

 
Отписаться от комментарев к записи

Получать уведомления только о тех ответах в этом обсуждении, которые адресованы лично вам.

 
К сожалению, комментарий не удалось отправить. Попробуйте ещё раз.я в курсе