Seagate, традиционный участник RICON, сдержал свое обещание открыть исходный код Kinetic Storage Platform (они пообещали сделать это на прошедшем OpenStack Summit, о чем вы уже могли слышать). В рамках проекта будет развиваться платформа распределенного хранилища данных (Software-defined Storage. К проекту уже присоединились Cisco, Cleversafe, Dell, Digital Sense, Huawei, NetApp, Open vStorage, Red Hat, Scality, Seagate, SwiftStack, Toshiba, Western Digital.

Хранилище сразу спроектировали не на базе устаревшего и неподходящего для распределенных систем стандарта POSIX (о его недостатках мы регулярно рассказываем), а как KV-хранилище с незамысловатым протоколом, использующим protocol buffers. Добавление поддержки в WIreshark будет сравнительно несложным делом.

Ну пока еще этот Kinetic взлетит, а до тех пор народ будет использовать традиционные хранилища, и их разработчикам еще работы будет много. Если вы из "Ceph vs. Gluster" выбрали последний, то наверное уже слышали, чтоб в конце весны вышла версия GlusterFS 3.7.0 (новость уже обсуждалась на OpenNET.ru). Из особо понравившихся фич можно выделить "bitrot detection", поддержка NFSv4 и pNFS, и шардинг, но новинок там гораздо больше.

Приглашаем на встречу разработчиков Linux-контейнеров — мероприятие сообщества OpenVZ, которое пройдёт 19 сентября в московском офисе Яндекса. Оно пригодится всем, кто интересуется применением контейнеров и контейнерной виртуализацией.

На встрече вы узнаете про плюсы и минусы живой миграции контейнеров, библиотеку LibCT, новый менеджер памяти в OpenVZ. Докладчики расскажут о решении проблемы фрагментации виртуальных дисков, применении контейнерных технологий в DevOps-процессах и особенностях использования OpenVZ в инфраструктуре крупного хостинг-провайдера.

Участие во встрече бесплатное, однако нужно зарегистрироваться.

Программа:

  • 11:00 Регистрация
  • 11:30 Живая миграция контейнеров: плюсы, минусы, подводные камни. Павел Емельянов, Odin
  • 12:00 Управление памятью контейнеров в проекте OpenVZ. Владимир Давыдов, Odin
  • 12:30 Перерыв
  • 12:40 LibCT и контейнеры на уровне приложений. Андрей Вагин, Odin
  • 13:10 Использование контейнерных технологий в DevOps. Дмитрий Лазаренко, Jelastic
  • 13:40 Перерыв
  • 14:30 Опыт использования виртуальных контейнеров в работе сервис-провайдера. Константин Анисимов, Русоникс
  • 15:00 CRIU: ускорение запуска PHP в CloudLinux OS. Руслан Куприев, CloudLinux
  • 15:30 Перерыв
  • 15:40 Развёртывание приложений Docker в контейнерах Virtuozzo. Павел Тихомиров, Odin
  • 16:10 Проблема фрагментации виртуальных дисков и способы её решения. Дмитрий Монахов, Odin
  • 16:40 Закрытие
Как проехать:

Москва. Ул. Льва Толстого, 16. Конференц-зал «Экстрополис»

Информация из доклада "Какие Linux и Unix используют федеральные органы власти России":

Наиболее популярной ОС с открытым исходным кодом является продукт американской компании Red Hat. На его базе функционирует оборудование 25 ФГИС. Доли других ОС приведены в таблице.

Разновидности Linux, используемые в ФГИС

Число ФГИС
Red Hat
25
Debian
15
CentOS
15
Ubuntu
11
Fedora
8
Mandriva
7
SUSE
5
МСВС
2
Alt Linux
1
Oracle Enterprise Linux
1

Данные: аналитический центр TAdviser Report, август 2015

Самым популярным дистрибутивом Unix, согласно исследованию, является FreeBSD. Доли остальных разновидностей приведены в таблице.

Разновидности Unix, используемые в ФГИС

Число ФГИС
FreeBSD
13
Oracle Solaris
8
IBM AIX
7
HP-UX
2
Циркон
1

Данные: аналитический центр TAdviser Report, август 2015

На базе российских дистрибутивов Linux - МСВС и Alt Linux - работают серверы только трех ФГИС.

Наш коллега, инженер Rackspace, Major Hayden, которого вы можете уже знать, как человека с самым прекрасным в мире резюме, разразился серией статей о том, как использовать systemd-networkd (с небольшим перекосом на тему Rackspace, где Fedora всегда была доступна) - использование systemd-networkd в серверах Rackspace OnMetal, как устроены предсказуемые названия сетевых интерфейсов в systemd, и как смастерить сетевой роутер с помощью systemd-networkd (у нас есть некоторые замечания по поводу именно этой заметки, но в целом там все хорошо).

Постепенно развивается flannel. В версии 0.5.0 исправили гадкую ошибку в наиболее скоростном режиме работы, т.е. VxLAN, когда терялся самый первый пакет, добавили поддержку Google's Compute Engine, добавили возможность создавать несколько сетей, и добавили интересную возможность клиент-серверного режима работы. В версии 0.5.1 добавили socket activation для клиент-серверного режима. В версии 0.5.2 добавили возможность работы за NAT. А в недавно вышедшей версии 0.5.3 его полностью привели к пока еще секретному стандарту CNI, о котором мы вам по секрету-же уже сообщили.

В компании Docker Inc тоже решили поработать над своими сетевыми проблемами, и в начале лета анонсировали SDN-плагин. В стотыщепятисотый раз скажем, что SDN, это уже не будущее, это настоящее. На технологию возлагаются большие надежды в сотовых сетях следующих поколений (если вы были на прошедшем Red Hat Forum 2015 в Москве, те могли слышать интересные новости во время выступления нашего товарища, Jan Wildeboer). Интересно, что компания VMware очень серьезно настроена на SDN/NFV-систему на базе OpenStack (или наоборот). Время проприетарных решений уходит, и видимо они вовремя заметили запросы на стандартное открытое решение.

С ростом интереса к SDN и сложным сетевым решениям, в полный рост стали видны проблемы производительности сети (которые возникают порой в довольно неожиданных местах). Системы должны справляться просто с диким объемом пакетов, приходящих на огромной скорости. В Red Hat работа ведется с двух сторон. Во-1 разгоняется сетевая подсистема ядра, что будет заметно даже обычным десктопным пользователям. А во-2 разгоняется весь вертикальный стек управления трафиком. Тут плюсы увидят, наверное, лишь производители и разработчики SDN-систем.

И о грустном. Из РФ эвакуировали еще один офис. Компания F5, разработчик SDN для OpenStack, о которой мы мельком упоминали, приняла решение о срочной перевозке всего томского офиса в США. Жаль, конечно. Еще на несколько специалистов в РФ меньше.

Наконец-то, GCC начал переход на Git с Subversion! Вот этого реально давно ждали!

Из других новостей - наш коллега, инженер Red Hat, Carlos O'Donell, объявил о выходе Glibc 2.22 (уже перевели на русский). К сожалению, после прочтения анонса складывается впечатление, что после Glibc 2.20, где объявили о слиянии с Eglibc (прощай, Eglibc, нам будет не хватать веселья), народ не очень желает "пиарить" процесс разработки. Непонятно, то ли subversion являлся одной из характерных черт этого закрыто-открытого процесса, но ведь и правда о новостях Glibc / GCC слышно как-то немного. На линукс-сайтах пишут по результатам пресс-релизов, а на пульсе проекта руку никто вроде бы и не держит. А новинок там навалом!

Мы периодически пишем о больших новинках базовых компонентов, например, про offloading в GCC, но нашей энергии хватает лишь на те новости, что прямо или косвенно касаются нас или сделаны нашими коллегами. Этого, конечно, мало. Мы всегда призывали участников других коммьюнити читать не только (микро)блоги, но и GitHub, списки рассылок, баг-трекеры, IRC/XMPP-чаты разработчиков - там самая движуха и "эксклюзивные" новости. Например, навскидку про Glibc / GCC за последние полгода:



Вообще, несмотря на необходимую осторожность, количество изменений в базовые компоненты не снижается, и в т.ч. в их инфраструктуру. Самым главным улучшением является удобная VCS (т.е. Git) и тестирование. В GCC тесты уже включают, в Glibc с тестированием не все так однозначно (например, почитайте транскрипт выступления нашего коллеги, бывшего инженера Red Hat, Roland McGrath). Одна из проблем тестирования базовых компонентов, таких, как ядро или Libc, это то, что они слишком уж низкоуровневые. Непросто не только написать юнит-тесты, но и тестировать установленную копию. Изолироваться тут не получается, кроме как в виртуальной машине. А там может быть непросто воспроизвести ситуацию, приводящую к ошибке (но, кстати, тем ценнее инструкции по тому, как тестировать с помощью systemtap наживую).

Ну и из изменений в Fedora - наконец-то локали в Glibc будут упакованы отдельно (померяйте размер /usr/lib/locale, если кто-то сомневается, зачем это нужно). Раньше для этого, как вариант, приходилось указывать флаги для rpm где-нибудь в /etc/rpm/macros.locales. Вторая новость, это расставание Fedora с давно устаревшей библиотекой librtkaio.

И наконец, не совсем про базовые компоненты (хотя кому как) - Vim тоже перешел на GitHub (и на Git с Mercurial). Все-таки как хорошо, что Google Code закрывается!

shot0002
Пользователь Mercurial недоволен переходом GCC на Git и отказом Vim от Mercurial



"I'm sorry to everybody involved here in containers, I'm so happy that the kernel tends to be fairly far removed from all of these issues, all of the buzzwords and all the new technologies." (Linus Torvalds на прошедшем LinuxCon 2015)

Daniel Stenberg, наш хороший знакомый, с которым мы теперь регулярно видимся на FOSDEM, и инженер Mozilla Foundation, год назад добровольно установил кейлоггер на свой рабочий компьютер. Конечно, он его использовал не так, как обычно используют в Windows и Mac OS X, где с помощью кейлоггеров обворовывают и так обделенных пользователей этих проприетарных операционных систем, а для сбора статистики. И теперь он проанализировал ее и опубликовал результаты. Оказалось, что за год он сделал почти 7 миллионов нажатий, что в среднем дало почти 2000 нажатий на условный рабочий час. Но были и более плодотворные рабочие часы. Например, однажды кейлоггер насчитал 8842 нажатия в час, а это ведь за 3600 секунд, если кто не пересчитал сразу в уме! А за самый продуктивный день он сделал 63757 нажатия.

Что будем делать? Завидовать будем! И не только завидовать, но и стремиться к результатам старших товарищей!

Дружественная нам организация, One Laptop Per Child, благодаря которой Fedora одно время была самым массовым Linux-дистрибутивом, предустанавливаемым на ноутбуки (до того, как появился Chromebook) может и отошла на покой, но дело ее живет!

Вы помните, в начале прошлого года будущее OLPC представлялось скорее негативно, но люди-то, зараженные идеями компьютеризации третьего мира, остались, и вскоре появился проект Endless PC, о котором вы уже слышали. А вот на днях появился еще один проект - One Education, созданный бывшим австралийским филиалом OLPC. К сожалению, они полностью перешли на Android, и с нашей точки зрения, это ошибка. Все-таки Android больше рассчитан на потребление контента (это такой интернет-телевизор), в отличие от полноценной Linux-системы, Sugar OS, но учитывая, что их поджимали сроки, это решение вполне объяснимо. В этом смысле Endless PC выглядит поинтереснее, но пускай так.


Пусть расцветают сто цветов, пусть соперничают сто школ!

Есть интересная и довольно прибыльная задача - пробрасывать физические USB-устройства в виртуальную машину с Windows, так, чтобы та считала, что они подключены непосредственно к ней. Некоторые используют проприетарные и глючные продукты для ее решения, но на самом деле стоит попробовать открытый и надежный продукт нашего коллеги, Hans de Goede - usbredir. С его помощью можно как раз пробросить USB-ключ для 1С произвольное USB-устройство в виртуалку. Отрадно, что появляются хаутушки по этой теме:

Проброс USB в виртуалку по сети средствами usbredir и qemu


На сегодняшний день существет довольно много способов пробросить USB-устройство на другой компьютер или виртуалку по сети.
Из наиболее популярных — железячные такие как AnywhereUSB и чисто програмные продукты, из тех что я попробовал сам: USB Redirector и USB/IP.
Я бы хотел рассказать вам еще об одном интересном способе, который работает непосредственно с эмулятором qemu.
Он так же является частью проекта spice, официально поддерживаемым RedHat.

usbredir, это открытый протокол для проброса usb-устройств по tcp на удаленный виртуальный сервер, разработанный при поддержке RedHat в рамках проекта spice. Но как оказалось им можно вполне успешно пользоваться и без spice. В роли сервера выступает usbredirserver, который шарит usb-устройство на определенный порт, а в качестве клиента сам qemu, который эмулирует подключение экспортированного usb-устройства в определенный usb-контроллер вашей виртуальной машины. Благодаря такому подходу в качестве гостевой системы может использоваться абсолютно любая ОС, так как она даже не знает, что устройство является проброшенным удаленно, а вся логика ложится на qemu.

Для начала несколько слов о вышеперчисленных решениях


  • AnywhereUSB — довольно неплохое решение, но дорогое, и имеет неприятние глюки, например бывает если расшаренная флешка отваливается, то переподключить ее обратно можно только физически вынув и вставив ее.
  • USB/IP — OpenSource проект. Вроде как был заброшен. По факту глючит довольно сильно. При разрыве соединения, машина частенько уходит в полнейший freezee, а windows показывает BSOD
  • USB Redirector — Замечательная софтина. Для расшаривания устройств с linux на linux бесплатна, во всех остальных случаях уже стоит денег, не так много как AnywhereUSB, но и не бесплатно как хотелось бы :)

Как видно есть из чего выбрать, но давайте же наконец попробуем еще один способ — usbredir?

Настройка виртуальной машины



Для того что бы было куда подключать экспортированные устройства, на виртуальной машине нужно создать необходимые usb-контроллеры:
  • uhci — для USB1.0
  • ehci — для USB2.0
  • xhci — для USB3.0


Для qemu (без libvirt)


Скачайте конфиг ehci-uhci.cfg, положите его в /etc/qemu/
$ curl http://cgit.freedesktop.org/spice/qemu/plain/docs/ich9-ehci-uhci.cfg --create-dirs -o /etc/qemu/ehci-uhci.cfg

И добавьте следующие опции в команду запуска виртуальной машины:
-readconfig /etc/qemu/ich9-ehci-uhci.cfg
-chardev spicevmc,name=usbredir,id=usbredirchardev1
-device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3
-chardev spicevmc,name=usbredir,id=usbredirchardev2
-device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,debug=3
-chardev spicevmc,name=usbredir,id=usbredirchardev3
-device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,debug=3


Для libvirt


Можно использовать такой конфиг.
В исходном файле конфигурации виртуальной машины в узле <devices> удаляем все USB контроллеры и добавляем следущий блок:
<controller type='usb' index='0' model='ich9-ehci1'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x7'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci1'>
<master startport='0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0' multifunction='on'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci2'>
<master startport='2'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x1'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci3'>
<master startport='4'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x2'/>
</controller>
<redirdev bus='usb' type='spicevmc'> 
<address type='usb' bus='0' port='3'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='4'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='5'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='6'/>
</redirdev>

Но у меня он почему-то не заработал, и я решил пойти другим путем, а именно явно указть libvirt с какими опциями запускать qemu:
Этот блок рамещается перед тегом </domain>:

<qemu:commandline>
<qemu:arg value="-readconfig"/>
<qemu:arg value="/etc/qemu/ich9-ehci-uhci.cfg"/>
<qemu:arg value="-chardev"/>
<qemu:arg value="spicevmc,name=usbredir,id=usbredirchardev1"/>
<qemu:arg value="-device"/>
<qemu:arg value="usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3"/>
<qemu:arg value="-chardev"/>
<qemu:arg value="spicevmc,name=usbredir,id=usbredirchardev2"/>
<qemu:arg value="-device"/>
<qemu:arg value="usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0,debug=3"/>
<qemu:arg value="-chardev"/>
<qemu:arg value="spicevmc,name=usbredir,id=usbredirchardev3"/>
<qemu:arg value="-device"/>
<qemu:arg value="usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0,debug=3"/>
</qemu:commandline>
Не забудьте так же скачать конфиг ehci-uhci.cfg, и сохранить его в /etc/qemu/ как в случае с qemu без libvirt

Кстати, после данной настройки, если вы используете spice, станет возможен проброс usb-устройств с клиента spice на сервер.

Заводим виртуалку, теперь все готово для осуществления проброса.

Запуск сервера


Пакет usbredirserver можно найти в стандартных репозиториях практически во всех популярных дистрибутивах linux.

Вставляем флешку в компьютер, смотрим вывод usb-устройств:
$ lsusb
...
Bus 003 Device 011: ID 125f:c82a A-DATA Technology Co., Ltd. 
...


Видим что пара vendorid:prodid равна 125f:c82a, а ядро определило флешке 003-001 usbbus-usbaddr соотвественно.

Теперь давайте расшарим ее на 4000 порт:

# Используя пару vendorid:prodid
$ usbredirserver -p 4000 125f:c82a
# Используя пару usbbus-usbaddr
$ usbredirserver -p 4000 003-011


Подключение устройства к виртуальной машине


Заходим на гипервизор и в qemu-monitor нашей машины выполняем следующие команды:
# Добавляем наше устройство
chardev-add socket,id=usbredirchardev1,port=4000,host=192.168.1.123
# Подключем его в ehci контроллер (USB-2.0)
device_add usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=4

Что бы отключить флешку достаточно такой команды:
device_del usbredirdev1


Если у вас libvirt, то команды в qemu-monitor можно отправить следующим образом:
$ virsh qemu-monitor-command --hmp one-73 'chardev-add socket,id=usbredirchardev1,port=4000,host=192.168.1.123'
$ virsh qemu-monitor-command --hmp one-73 'device_add usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=4'
$ virsh qemu-monitor-command --hmp one-73 'device_del usbredirdev1'

На этом все, после данных шагов ваша ВМ увидит вашу флешку и сможет с ней нативно работать.

Если устройств много и все они одинаковые


Вот тут появилась интересная задачка, как пробросить несколько одинаковых девайсов на разные ВМ?
При этом, стоит отметить, все устройства имеют одинаковую пару vendorid:prodid, а пара usbbus-usbaddr совсем не постоянна, стоит только вынуть и вставить устройство, так оно сразу поменяет свой usbaddr.

Для себя я решил ее при помощи udev, и небольшого скрипта.
Кстати если вы не совсем понимаете как работает udev, на Debian Wiki есть классная статья о udev

И так приступим:

Для начала узнаем серийник нашего устройства, по которому и будем идентифицировать его в udev:
$ udevadm info -a -n /dev/bus/usb/003/011 | grep '{serial}'
    ATTR{serial}=="11C130317234004B"
    ATTRS{serial}=="0000:00:14.0"


Теперь создадаим файл /etc/udev/rules.d/99-usb-serial.rules и запишем в него следующее правило:
SUBSYSTEM=="usb", ATTRS{idVendor}=="125f", ATTRS{idProduct}=="c82a", ATTR{serial}=="11C130317234004B", SYMLINK+="usbdevices/token1"

Перезагрузим udev-правила:
$ udevadm control --reload-rules

Теперь, при подключении нашей флешки, в /dev/usbdevices/token1 на нее появится симлинк.

Я написал небольшой скрипт, который использует этот симлинк, для того что бы узнать настоящую пару usbbus-usbaddr устройства и расшарить его на нужный порт

usbredirserver-by-symlink.sh
#!/bin/bash
keys="${@:1:${#}-1}"
usblink="${@: -1}"
if [ -L $usblink ] && [ $# != 0 ]; then
    usbbus=`udevadm info -a -n $usblink | awk -F== '/ATTR{busnum}/ { gsub(/"/,"",$2);print $2 }'`
    usbaddr=`udevadm info -a -n $usblink | awk -F== '/ATTR{devnum}/ { gsub(/"/,"",$2);print $2 }'`
    if [ "$usbbus" != "" ] && [ "$usbaddr" != "" ]; then
        usbredirserver $keys $usbbus-$usbaddr
    else
        echo "This is not usb device"
        exit 1
    fi
else
    echo "Usage: usbredirserver-by-symlink.sh [-p|--port <port>] [-v|--verbose <0-5>] /dev/usbdevice"
    exit 1
fi

К сожалению от смены пары usbbus-usbaddr после расшаривания устройства этот скрипт не спасет, так как usbredirserver не отваливается, если устройство вынуть или если такое устройство вообще не существует. Но он облегчит путь и поможет не запутаться при расшаривании нужного устройства на нужные ВМ.
В дальнейшем его можно будет использовать, для написания следующего скрипта, который будет мониторить подключение/отключение устройств, расшаривать нужные и автоматически подключать/отключать их на удаленной ВМ.

Источники:


umvirt.ru/node/82
opennebula.org/opennebula-for-virtual-desktops
opennet.ru/opennews/art.shtml?num=30773
lists.gnu.org/archive/html/qemu-devel/2013-07/msg05244.html

На наших глазах развивается драма, разгоревшаяся после предложения нашего коллеги, Christian Schaller, рекомендовать конечным пользователям использовать LibreOffice вместо AOO. Christian адресовал предложение смотрителям кладбища OpenSource-проектов, Apache Software Foundation, так что история получилась еще смешнее. Драма уже обсуждается коллегами-аналитиками на русскоязычных ресурсах - OpenNET.ru и Linux.org.ru.

По существу вопроса добавить наверное нечего - каждому, кто заглянет в git log обоих проектов, будет все ясно. Но особенно интересна и показательна типичная реакция некоторых коллег-аналитиков - "в вашем %имя_проекта% полно глюков, и документы открываются/сохраняются/отображаются неправильно, но я вам устранить эту ошибку помогать не буду, а буду ждать, пока ею займется кто-то другой". Нам кажется такая позиция неконструктивной и не только чуждой самому духу сообщества открытого ПО, но и серьезно мешающей бизнес-процессу в конкретных компаниях. Как положительный пример отношения к проблемным моментам, хочется обратить внимание на доклад другого нашего коллеги, Bastien Nocera, на недавно прошедшей конференции GUADEC 2015.

Bastien Nocera рассказал о своем опыте запуска Linux на дешевом Windows-планшете и заодно предложил новый способ работы GNOME с новым оборудованием - чтобы было так просто, как и с Android.

Половину своего выступления Bastien рассказывал то, как вообще можно сферически запустить сферический Linux (а потом и GNOME) на новом сферическом устройстве. А вот под конец, он вернулся к началу и изложил события ровно в том порядке, в котором они произошли в реальности (с гораздо меньшим успехом). Но, как он подчеркнул, более успешная версия событий вполне достижима, если внести немного изменений в GNOME.

[Bastien Nocera]

История началась, когда Bastien купил дешевый китаепланшет, и решил поставить туда операционную систему GNOME вместо Windows 8. Главной проблемой был неработающий WiFi. В планшете был чип от Realtek, и Bastien даже сумел получить к нему исходники от компании, но они были в ужасном состоянии.

Скорее всего исходники были от драйвера для Android, но с мэйнстримовым Linux-ядром они не работали. Покопавшись в исходниках он обнаружил, что они забиты бесполезным мусором - тестами, кодом для препродакшен-версий оборудования, и т.д. В драйвере был даже какой-то код для USB, т.к. wifi был физически подключен к материнской плате через USB. В конечном итоге, с помощью других программистов, среди которых были и наши коллеги, он сумел выкинуть лишнее, и кодовая база уменьшилась в 20 раз.

Затем они привели его в состоянии пригодности для работы со стандартным ядром. Это заняло время, но все заработало, и после того, как получившийся код был выложен на GitHub on начал работу над следующей задачей. Следующим он добился работоспособности USB On-The-Go, что позволило подключиться к планшету через USB. Это, в свою очередь, позволило ему использовать Android Debug Bridge (adb), чтобы контролировать и мониторить процесс загрузки. Для этого пришлось поправить adb-демон, чтобы он работал с glibc и systemd, вместо Bionic и init из Android. Пропатченный adb он также выложил на GitHub.

Тут уже он настроил "EFI mixed mode" (загрузка 64-битного ядра 32-битным firmware), а позже он заменил загрузчик на GRUB, настроил Secure Boot shim, и запустил инсталлятор Fedora, чтобы установить полноценную 64-битную Linux-систему. ADB позволяет загружать пакеты на планшет, так что с поддержкой его в GNOME, разработчики могли бы создавать приложения xdg-app с помощью GNOME Builder на рабочих машинах, загружать их по USB на планшеты и тут же тестировать. Никаких эмуляторов, симуляторов, и не нужно было бы.

Тут то Nocera и остановился, чтобы сообщить, что лишь половина этого всего случилась в реальности. Ну, пока так. Действительно, ему удалось запустить WiFi с помощью Larry Finger. И его работа над ADB и EFI mixed mode тоже существует, хотя не все патчи готовы к включению в апстрим.

То, что он рассказывал, это то, что бы он хотел от GNOME в ближайшее время, и что ему хотелось бы обсудить. Все кусочки уже в наличии - xdg-app может создавать образы, которые, как и apk-файлы для Android, разработчик мог бы попробовать установить и потестировать. GNOME Builder хорошо бы, чтобы умел создавать пакеты xdg-app, и было бы здорово интегрировать его с adb.

Тут есть и другие проблемы, некоторые совсем не относятся к GNOME. Windows 8 не поддерживает USB On-The-Go, и поэтому даже если system-on-chip, используемый в планшете, поддерживает USB OTG, производитель может не присоединить его к материнской плате. Одной из альтернатив был бы кабель USB host-to-host - они дешевы, но потребуется некоторая работа, чтобы они надежно работали c Linux-десктопами. Внутри таких коннекторов используются дешевые сетевые адаптеры USB, между которым находится Ethernet-хаб, поэтому поддержка их потребует разработки драйверов.

Гораздо большей проблемой может стать то, что EFI mixed mode пока не полностью подерживается в Linux. Действительно, уже можно загрузить 64-битный Linux на 32-битном UEFI, но когда драйверы начинают обращаться к UEFI, тогда начинаются проблемы. Ну и проблема еще в том, что дешевые планшеты меняются очень быстро, и поддерживать большое количество моделей будет непросто. Но если на планшет можно установить старую версию Windows, то скорее всего легко получится запустить и Linux.

Nocera закончил выступление объявив, что претензии не принимаются. Он сказал, что сожалеет, что ему пришлось приврать в первой части доклада, когда он рассказывал про идеализированный сценарий, скрыв, что еще необходимо много работы. Но именно такая поддержка оборудования, это именно то, что нужно для распространения GNOME. Мобильные устройства никуда не уйдут, и т.к. у Android есть захватывающая история о том, как каждый желающий может подключить UBS-кабель, и начать разрабатывать ПО, которое можно сразу же запустить на любом планшете или телефоне, то GNOME стоило бы обеспечить такой же уровень поддержки.


Хотелось бы обратить внимание, как энергично Bastien решал проблемы, с которыми сталкивался. Конечно, не каждому суждено доработать драйвер для Wi-Fi (даже с помощью старших товарищей), но имеет смысл при возникновении проблемы проконсультироваться с upstream-разработчиками. Скажем, открыть заявку в Bugzilla.

Страницы