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

Сылка:

• https://packages.debian.org/sid/x11/xserver-xorg-video-intel

Цитата:

Пакет: xserver-xorg-video-intel (2:2.99.917+git20171229-1 и другие) … Не рекомендуется использование данного драйвера с видеокартами, выпущенными позднее 2007 года: вместо этого удалите его, и графический сервер будет использовать встроенный драйвер установки режимов.

Не рекомендуется.

Замена: Xorg драйвер modesetting, встроенный драйвер, работающий со всеми KMS совместимыми драйверами в ядре.

По мотивам:

• https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/

При этом мнения по поводу адекватности замены расходятся (на правах заметок по разным источникам из сети):

• По данным тестов Phoronix, ускорение Glamor существенно проигрывает SNA от Intel в производительности и примерно сопоставимо с UXA в части 2D. При этом единогласно сходятся, что SNA до сих пор глючная и бажная, а путь современных графических библиотек в использование 3D:
  • Intel 2D GLAMOR vs. UXA vs. SNA On Ubuntu 14.04
  • Intel vs. Modesetting X.Org DDX Performance Impact
• Нашёл ровно одно утверждения без подтверждения фактами, что Glamor может выедать больше батарейки (кстати, этот режим ускорения можно включить и в драйвере Intel). Реальных сравнений у меня нет.
• Стабильность и реальная скорость обоих драйверов (и трёх вариантов ускорения на драйвере Intel) разнится от железки к железке.
• Исправлений для старых карт в драйвере Intel почти нет, хотя и рекомендуется к использованию как раз для старых карт.

Ссылки:

• https://wiki.gentoo.org/wiki/Intel
  • Тут хорошая табличка по поколениям графики и соответствующим архитектурам. Ivy Bridge, это HD4000 и Gen7. Debian рекомендует modesetting новее 2007 года, Gentoo говорит более конкретно (по ссылке выше): Gen 4+.

Будет пополняться. В контексте изучения проблемы:

• https://community.spiceworks.com/topic/152058-what-causes-a-laptop-to-turn-on-then-turn-off-again
  • перегрева нет
  • батарея не влияет
• https://bugzilla.kernel.org/show_bug.cgi?id=109051

CPU

• Кладезь: https://wiki.archlinux.org/index.php/Stress_Test
  • stress - есть в репозиториях

GPU

• https://www.pcsuggest.com/gpu-benchmarking-and-stress-testing-in-linux/
  • glxgears
  • glmark2
  • furmark из комплекта GpuTest

Наблюдения

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

В первую очередь для рабочего стола, не для WEB.

На текущий момент мне понравилось три решения, которые могут работать с отдельными файлами без создания проектов и так далее:

• PlantUML QEditor
• Расширение для Visual Studio Code - PlantUML
• Плагин для NetBeans

В первом не хватает подсветки синтаксиса. Третий достаточно тяжеловат (всё же сам NetBeans сам по себе - IDE), так что второй вариант - пока мой выбор. Раньше Visual Studio Code не использовал, и сейчас он больше для редактирования PlatnUML с предпросмотром, но со своими задачами справляется достойно. Не хватает, правда, Assistant, как в PlantUML QEditor.

PS в IDEA есть достаточно удобный плагин, особенно если в рамках проекта нужно диаграммы думать. Мне же больше по душе запуск без IDE проекта, дабы не отвлекаться. PPS для WEB: www.plantuml.com/plantuml/form быстро сгенерить или посмотреть.

На два канала:

ffmpeg -f lavfi -i "sine=f=1000:sample_rate=48000" -filter_complex "[0][0]amerge" -c:a pcm_s24le -f alsa "hw:1,0"

для увеличения: добавляем [0] перед amerge

Можно генерировать и разные синусы по кадому каналу, просто увеличиваем число lavfi входов:

ffmpeg -f lavfi -i "sine=f=1000:sample_rate=48000" <br/>
       -f lavfi -i "sine=f=400:sample_rate=48000" 
       --filter_complex "[0][1]amerge" <br/>
       --c:a pcm_s24le -f alsa "hw:1,0"

и не забываем в этом случае менять номера входов для amerge

Как-то пропустил сей момент, но в PlantUML появились Временные диаграммы (Timing Diagram):

• http://plantuml.com/timing-diagram

Жаль, что когда они были ооооочень нужны (сейчас не так), удобного инструмента я не нашёл.

Возникает путаница иногда что где и когда. Коротко:

1. USB 3.0 == USB 3.1 Gen1 (SuperSpeed), скорость до 5 ГБит/с. По сути - ребрендинг и переименование.
2. USB 3.1 == USB 3.1 Gen2 (SuperSpeed+), скорость до 10 ГБит/с.

По поводу коннектора Type-C: его появление связывают с появлением USB 3.1 Gen2. Но! Этим коннектором вполне может быть осуществлено подключение в устройствах, которые поддерживают только USB 3.1 Gen1, USB 2.x или даже USB 1.x (для 1.x и 2.x используются одинаковые дифпары независимые от режима 3.x). Иными словами, наличие Type-C коннектора не говорит о поддержки USB 3.1 Gen2, особенно, когда данный разъём используется на устройстве, а не на хосте, хотя в последнем случае тоже нужно проверять внимательно спеки на материнку или лаптоп.

По поводу коннектора Type-A: провода для USB 3.1 Gen2 никак не изменились, поэтому применение коннектора Type-A вполне себе возможно на хостах. Правда в текущем виде обычно наблюдается такая картина:

1. чёрные коннекторы - USB 2.x
2. синие коннекторы - USB 3.1 Gen1
3. Type-C коннекторы - USB 3.1 Gen2

Но есть платы расширения, которые использую коннектор Type-A для USB 3.1. Gen2. Т.е. снова - нужно смотреть спецификации.

Вообще, появление Type-C это очень хорошая работа над ошибками для устранения идиотских варианта Micro Type-B (Micro-B, Mini-B выполнен вполне сносно) в варианте USB 3.1 Gen1: они отличаются большими габаритами и низкой механической прочностью:

Правда установка данного типа коннектора на хост… Мне не по душе. Да, решаются две проблемы:

1. симметричность кабеля с обеих сторон: можно подключать устройство как к хосту, так и к другому устройству, если поддерживается OTG и использовать для этого один кабель,
2. симметричность самого коннектора как такового, но вот его прочность (хоть маркетинговый булшит вещает иначе) значительно ниже Type-A.

Моё мнение (на которое всем, ессесно, пофиг):

1. Type-A - оставить для хоста
2. Type-B - оставить для устройств, где необходима повышенная механическая прочность
3. Type-C - оставить для всех остальных устройств

Сегодня пришло уведомление о комментарии к тикету 111:

In the meanwhile QMapShack has a new brother called QMapTool. QMapTool is for referencing maps. It’s now part as a sub-repository of QMapShack.

И вот ссылка:

• https://bitbucket.org/maproom/qmaptool

Если коротко: отдельная программа для привязки карт, то что было в QLandKarteGT в виде встроенного функционала, теперь в виде внешней утилиты.

Пока ещё не тестировал. В AUR mercurial версия QMapShack автоматом подтянет и QMapTool, когда будет релиз в Community - непонятно.

А так, ура!

Просто ссылка:

• AMD64 Linux Kernel Conventions

Более полная подборка для x86:

• x86 calling conventions

И более обобщённая информация (в т.ч. ARM):

• http://wiki.osdev.org/Calling_Conventions

В продолжение post/2017/08/25/qt_creator_baremetal_i_svjazka_gdb_7.7.1_openocd. Снова косяк и снова QtC не имеет прямого отношения к нему. Судя по всему, в самом GDB какие-то гонки.

Проблема проявляется на этот раз в том, что подобные сообщения от отсутствующем контексте исполнения появляются после попытки останова исполнения кода (для отладки), при этом, какого-то чёрта, появляются сообщения об вновь образовавшемся и тут же умершем треде. GDB не может уже потом ничего сделать, а QtC следом тоже сходит с ума, не зная, в каком состоянии что находится.

В общем, пока откатился на GDB 7.8 от Linaro: https://aur.archlinux.org/packages/arm-none-eabi-gdb-linaro, оно, по крайней мере, работает.

Связанные ссылки и обсуждения:

• https://github.com/gnu-mcu-eclipse/eclipse-plugins/issues/186
• https://github.com/gnu-mcu-eclipse/eclipse-plugins/issues/167

PS текущая связка: GDB 7.8 + OpenOCD 0.10.0