Инженер Parallels, Pavel Emelyanov, в своей ленте Google+ сообщает, что на Intuit наконец-то появился курс по ядру Linux, который он читает судентам МФТИ.

Школьникам старших классов укажем, что для того, чтобы получить доступ к лекциям Павла бесплатно и без регистрации, нужно лишь поступить в МФТИ. Кроме этого курса на Физтехе вас научат много чему еще. Имейте в виду, абитуриенты.

Наконец-то и разработка RPM перехала на GitHub, о чем официально сообщил наш коллега, Florian Feisti. Давно пора!

Народ жалуется, что в RHEL 6.7 нельзя перезапускать squid, который при перезапуске сотрет все файлы. Баг открыт уже неделю.

Ну бывает, что. И вообще, незачем так привязываться к файлам на компьютере. Bumblebee-момент был и у Steam, например, и ничего.

Скоро выходит Qemu 2.3. Список изменений все специфичнее и специфичнее, что показывает надежность продукта - новые процессоры, новые устройства, и прочие улучшения. Из интересного для разработчиков, это запуск Qemu c KVM под Valgrind. Это наверняка понравится разработчикам ядра и/или системного ПО низкого уровня. Из удаляемых фич - встроенное шифрование Qcow2-дисков. Пока будет предупреждение, но в версии 2.4 фичу отключат навсегда. Используйте встроенные средства шифрования Linux.

Из других новостей о виртуализации - участники проекта Genode опубликовали обзорную статью о виртуализации на ARM, а Vasily A. Sartakov (ksys labs) поделился своими впечатлениями от FOSDEM 2015.

Народ, началось!


Студенты уже спешат занять свои места

Наш коллега, участник проекта Fedora и разработчик Bitcoin, Jeff Garzik, выступил сегодня на фестивале SXSW. Помните его планы по запуску в космос спутников для Bitcoin? Так вот, Jeff их не забросил, и теперь он не только инженер BitPay, но и CEO в Dunvegan Space Systems. В его планы теперь расширились далеко за сеть для Bitcoin. Теперь они собираются развернуть глобальную децентрализованную компьютерную спутниково-хостинговую сеть в ближнем космосе.



Хочется пожелать удачи нашим коллегам, а нам остается лишь позавидовать, т.к. по очевидным причинам в нашей стране подобное бы запретили моментально, сразу после GitHub, Bitcoin и Tor с VPN.


"We want to bring space to humanity..."

Начало года у наших коллег из GCC, несмотря на перерывы на мероприятия, выдалось деятельное, и новостей довольно много.

Конкуренция GCC с LLVM однозначно пошла проекту (проектам) на пользу, о чем мы постоянно говорим. Например, мы уже рассказывали вам о работе наших соотечественников, которые реализовали offloading в GCC. Но также мы упомянули, что на самом деле основными проблемами является монолитность GCC (ну, там тоже не все так просто, но скажем так - "большая" монолитность по сравнению с LLVM) и непоощряющийся доступ к внутреннему представлению GCC. И вот, обе проблемы вновь широко обсуждаются.

Для начала, по наводке LWN, мы с интересом ознакомились с январской дискуссией о доступе к IR GCC в Emacs (это часть древнего треда в списке рассылки Emacs, но он настолько большой, что с трудом открывается в Firefox). Доступ к внутренностям GCC помог бы Emacs конкурировать с тяжелыми проприетарными IDE. Мы уж не будем в очередной раз упоминать тут GCC-XML, которому бы это тоже сильно облегчило жизнь.

К сожалению, надо признать, что RMS занял очень неконструктивную позицию - по всей видимости он все еще боится, что вендоры будут клепать проприетарные модули, оперирующие IR GCC, и предлагает искусственно "оглуплять" выхлоп GCC IR, чтоб его еще можно было загружать в Emacs для чего-нибудь полезного, но нельзя было использовать в проприетарных утилитах. Ему на это привели ряд возражений практического и теоретического плана, но, как и обычно бывает, религиозные воззрения всегда побеждают рациональные доводы. RMS готов терпеть отток студентов и аспирантов, переключающихся в научной деятельности на LLVM. Он готов страдать от падения интереса со стороны железячных вендоров, которые хотят быстро разрабатывать поддержку новых архитектур (например, OpenCL и Vulcan). Он безразличен к уходу больших домов (Apple), которым нужен больший контроль над процессом компиляции, чтоб делать свои IDE (Xcode) еще умнее. Он не видит в надвигающемся отставании Emacs от (полу)открытых и проприетарных тяжелых IDE большой проблемы. Ведь свобода лучше несвободы наличием свободы.

В принципе, чтоб ублажить старика, можно сесть и устроить мутное пип-шоу из внутренностей GCC, отсортировав то, что можно показывать, и то, что нельзя. К сожалению, таким унылым делом могут заниматься лишь религиозно мыслящие люди, т.к. инженерный подход к такому стриптизу сразу приведет к разумному предложению - раздеться сразу, чтоб сэкономить время вывалить все, как есть, а там пусть каждый смотрит на то, что нравится. Хорошо, предположим, что такие бедолаги найдутся, но проблема еще и в том, что IDE непрерывно развиваются и улучшаются, и с каждой итерацией им требуется больше обратной связи с инструментарием компиляторов, причем обменом сильно структурированными данными (грубо говоря, Unix-вэй и тут давно уже сдерживает развитие). Поэтому придется постоянно то открывать, то прикрывать отдельные куски IR. Вот, например, современный тулкит для компиляторов, LLVM, пишется инженерами, а не религиозными любителями трогать друг друга текстами через пайпы, и там структура, как говорят, сильно упрощает взаимодействие с ним из IDE, чего и добивается Apple (хотя популярная городская легенда говорит о том, что им просто не нравится GPL).

Вероятно, как и у многих других любителей Unix-вэя, у RMS горизонт видения ограничивается религиозными воззрениями, и про возможности, предоставляемые современными IDE он, если и слышал, то уж точно не пробовал. Теория без практики, увы, бесплодна. Тут практика подразумевается в живом обмене идеями, и проверке подходов, невзирая на личные предпочтения. В диалоге оказалось, что его потолок, это autocomplete. Когда ему сообщили о различных advanced фичах для сложных языков, таких, как С++, он перепугался и решил, что ему всерьез угрожают и требуют отказаться от его свободы.

К счастью, народ догадался нажать RMS на его известную мозоль - ему в лоб сказали, что своим упрямством он угрожает свободному ПО проигрышем по "feature parity" проприетарным продуктам. Конечно, так таскать уважаемых людей за бороду неэтично, но прогресс важнее.

Но каков изгиб истории! Человек, начавший разработку Free Software с того, что проприетарное ПО было ограничено, призывает к ограничению функциональности Free Software. Например, в феврале он выступил против включения поддержки LLDB в Emacs, назвав это "систематическими атаками на GNU". Новость тогда широко обсуждалась коллегами-аналитиками на OpenNET.ru.


Коллега-аналитик рационально оценивает высказывания RMS


Продолжим хорошими новостями. Инженер Red Hat, Pedro Alves начал работу по переводу GDB с C на C++, который лучше подходит для разработки столь сложного инструмента. А недавно вышла версия 7.9, в которой появилась поддержка интересной функциональности - инъекция произвольного C-кода (требуется GCC 5 или старше). Начата работа по расширению этого функционала инъекцией уже C++-кода.

Требование 5го GCC вполне реалистично. Fedora 22 выходит с GCC 5. Это изменение, как всегда, запустило полную пересборку всех пакетов - увлекательное занятие, зачастую пропускаемое другими дистрибутивами. Помимо технической проблемы с меняющимся ABI с каждой мажорной версией GCC, мы еще решаем социально-философскую задачу - ищем и исправляем пакеты, несовместимые с новыми функциями и проверками GCC. Это, как считают некоторые, самая важная задача. В этот раз интрига была закручена сильнее - ABI менялся радикально, т.к. того требовало соответствие стандарту C++-11, и в срок мы не успевали. После ожесточенных дискуссий, было решено пойти на компромисс - ABI будет почти как старый, но возможности будут от нового GCC. Подробнее об этом наши коллеги написали в статье про ABI.

После обнародования списка организаций-участников GSoC 2015, настало время и второго этапа. Завтра, 16 марта, открывается регистрация студентов, желающих поучаствовать. В проекте GCC появилось уже пара интересных идей. Первая идея пришла от анонима, и не факт, что он будет участвовать в ее реализации, но тем не менее - это добавление бэкенда для SPIR-V в GCC. Т.е. предлагается задуматься о перспективе писать шейдеры на любом языке, поддерживемом GCC. Описание, опять же, напоминает offloading для GCC. Вообще, идея писать код на одном языке, который потом будет собираться в нативный, и в один или несколько модулей для сопроцессоров, выглядит интересной. Технически это возможно, например, с помощью gccjit, о котором мы упоминали. К сожалению, сейчас у gccjit есть существенное ограничение - он подразумевает, что хостовая архитектура совпадает с целевой (что не так, в случае трансляции кода в байткод для сопроцессора, например OpenCL, CUDA, Intel MIC и т.п.). Наш коллега, инженер Red Hat, David Malcolm, обещает, что к GCC 6 ситуация будет исправлена, и gccjit можно будет перенацелить на одну или несколько архитектур, отличающихся от хостовой, и тогда SPIR-V байткод или его "ассемблер" можно будет использовать в GCC. Пока отметим, что SPIR-V разрабатывается с помощью LLVM, за что спасибо RMS (см. выше).

Второе предложение пришло от студента, который, как видится со стороны, взялся за слишком большой вес. Он вызвался на задачу по модуляризации GCC, к которой из-за ее неподъемности и огромности не подступали и бывалые профессионалы. К его чести, он правильно оценил ее и попросил экспертов сузить область деятельности. Наши коллеги с радостью отозвались. Конечно, модуляризация продукта, который специально делался немодульным, это непросто. Однако определенные части задачи вполне поддаются выполнению за срок до полугода. Например ...пабабабам! удобный доступ к GCC IR (см. драму в @emacs-devel по ссылкам выше). Понятно, что если жестко стандартизировать формат обмена между подсистемами GCC, сделать их самодостаточными и предоставить к ним доступ, то это откроет перспективы, которые RMS не снились в самых страшных его кошмарах. Если мыслить совсем уж научно-фантастически, то можно будет заменять куски GCC аналогами LLVM, и наоборот. Из совсем уж приземленных вещей, изоляция в пределах подсистемы позволила бы упростить разработку и отладку проекта, сделав сам проект более LLVM-подобным. Отладка GCC, это отдельная история, и мы все чаще и чаще вынуждены проводить аналогии с коротким одеялом - чуть потянешь за опции, и вылезают какие-то странные эффекты, особенно в не самых освещенных углах пакета, например в Ada-фронтэнде.

Ну и напоследок, наш коллега, Petr Machata, представляет написанную им утилиту для изучения DWARF-файлов - dwgrep. Выглядит очень полезной для разработчиков инструментария для разработчиков.

С окончательным переходом Ubuntu на systemd на нашего товарища, инженера Canonical, Martin Pitt, рекой потекли багрепорты. Его, конечно, это не пугает, и он бесстрашно смеется над опасностью. Конечно, если бы его начальство не упиралось бессмысленно, то у них бы сейчас была бы и IVI-версия, и версия для телефона, и версия для телевизора. Ну, будем надеяться, что от самодельного аналога Wayland они откажутся оперативнее, без попыток навязать свое нестандартное решение другим, в т.ч. в материнский дистрибутив. Все равно ведь придется отказываться, так что тянуть?

Мы пока неторопливо добавляем поддержку systemd в сервисы. Конечно, речь не идет о том, чтобы переводить на исключительное использование systemd - поддержка огораживается ifdef-ами, т.к. еще есть Mac OS X и FreeBSD. Но если вы используете Linux-дистрибутив, которые уже все перешли на systemd, за исключением нескольких отмирающих или узкоспецифичных дистрибутивов, то вы можете заметить улучшенную интеграцию сервисов с systemd. Недавно была добавлена в Apache поддержка журналирования с помощью Journald. Новый функционал доступен начиная с версии 2.5, и пока есть какие-то проблемы с производительностью, но можно надеяться, что способ перенаправления журнала Apache в Journald скоро будет неактуален.

AMQP-сервер RabbitMQ, написанный на Erlang и популярный при проектировании облачных систем на базе OpenStack, начиная с версии 3.5.0 имеет штатную поддержку systemd-notify. Мы тестировали эту функциональность около полугода, и теперь перенесли в апстрим, что позволит и другим дистрибутивам решить ряд проблем.

Мы работаем и над интеграцией не столь широко использующихся сервисов. Например, широко известный в узких кругах VoIP-разработчиков и архитекторов RTPproxy недавно получил (раз pull request и два pull request) поддержку systemd, о чем теперь официально объявлено в анонсе недавно вышедшей версии 2.0.0.

Не все так гладко в других проектах, где разработчики, предлагающие патчи для лучшей работы с systemd, порой наталкиваются на необъяснимую агрессию со стороны upstream-разработчиков. Например, включение небольшого патча для systemd в Polipo идет уже несколько лет. Автор Polipo был против включения в 2012 году, выкатив ряд надуманных возражений (зависимость от хидеров из systemd, затем, уже после отказа от них, он начал всерьез упоминать про runit, и притворяться, что размер патча слишком большой, чтоб его просмотреть). Прошла пара лет, и он уже после дежурных проклятий в сторону systemd, на которые мы внимания уже не обращаем, пообещал заревьюить его, да так и замылил это дело. Но разработчики не сдаются, и вновь оформили pull request - вода камень точит. Вообще, проблема в том, что Polipo, это нынешний де-факто фронтэнд-модуль для Tor, и хотелось бы, чтоб его интеграция в systemd/Linux платформу была бы получше. Раньше использовали Privoxy, но потом перешли на Polipo, хотя их функциональность различается, и можно было бы использовать одновременно оба.

Мы уже говорили, что systemd в RHEL 7 и производных дистрибутивах слишком стар - в нем, например, нет поддержки конфигурирования сети. Lukáš Nykrýn подготовил специальный репозиторий для RHEL7 с самой новой версией systemd, о чем мы вам уже говорили. На днях он обновил systemd до версии 219. Некоторые наши коллеги уже вовсю используют его сборку в production-системах, наслаждаясь возможностями по управлению сетью. К сожалению, код очень экспериментальный, и порой на ровном месте возникают не очень понятные эффекты. Нас, конечно, проблемы не пугают!

Наш коллега, Patrick Uiterwijk, решил прикинуть, сколько вообще пакетов затронуты закрытием Google Code и поглощением GitLab B.V. хостинга Gitorious? Оказалось, что довольно много.

Patrick просто погрепал по spec-файлам, так что итоговое число будет больше, потому что есть пакеты, которые хостятся на Google Code или Gitorious, но информация об этом в spec-файлах отсутствует. Навскидку, например, Vim.

Кстати, наши упрямые коллеги, которые были не как все, уже переносят проекты. Например, Nikos Mavrogiannopoulos начал перенос GnuTLS на GitLab. Ну хоть так, хотя, конечно, надо было бы на GitHub.

На прошедшем в феврале этого года в Лос-анжелесе мероприятии SCALE 13x было довольно много интересных презентаций, но одна особенно привлекла внимание. Матерый гентушник, Stephen Arnold, сделал обзор нынешнего положения с ARM-системами. Наш коллега, Rich WM Jones, уже жаловался на недостатки ARM-систем, и стало интересно, далеко ли сдвинулась ситуация с тех пор. Выяснилось, что особо разницы не прибавилось. Все так же - нестандартное старое ядро, бинарные блобы, различия в ISA между системами формально одного типа, отсутствие каких либо стандартов на что либо.

Главное, это, конечно, не очередная констатация факта, что в свободе на каждом шагу, которая лучше несвободы (стандарта) наличием свободы, нет ничего хорошего ни для индустрии, ни для независимых разработчиков. Очень хотелось бы услышать от докладчика, что он предлагает с этим делать? Подскажем - стандартизация платформы ARM. К сожалению, нет, не было этого произнесено. Свобода выбора из десяти старых ядер, помноженная на свободу выбора среди десяти форков старых версий загрузчиков, все это перемноженное на очередные степени свободы в других компонентах, это какая-то священная корова для представителей коммьюнити любителей покомпилировать по вечерам. Ну что ж, подождем.

Из других новостей, помните историю с покупкой Tilera? Так вот, EZchip анонсировал выход 100-ядерного ARM-процессора в 2016 году. Обещают, что процессор будет использоваться в 200-гигабитных сетевых приложениях, так что пора пробовать AArch64-дистрибутивы. Тут как раз Rich WM Jones опубликовал микрохаутушку о том, как запустить Fedora 21 для AArch64 UEFI на x86_64 системе.

Страницы