В 18.04 запланирована версия GNOME 3.26 (та же, что и в artful). Но вот беда: Mutter научится захвату клавиатуры только в 3.28 (https://bugzilla.gnome.org/show_bug.cgi?id=783342). Вопрос: как это всё будет выглядеть? Варианты:

• дефолтной сессией по прежнему будет x11
• будет объявлено что: виртуалки ненужны, игры ненужны, а уж всякие rdp и vnc и подавно
• будут патчи

В общем, попробуйте запустить на хосте c GNOME3 и Wayland виртуалку с GNOME3 и у вас тоже нехило так пригорит. Гарантирую.

Ещё немного инфы по теме: https://wiki.archlinux.org/index.php/wayland#Input_grabbing_in_games.2C_remot...

Всегда думал, что все эти gzip, bzip2, xz и т.п. обладают достаточной восстановимостью. Т.е. если в стриме испортится несколько байт, то декомпрессия пойдет дальше, начиная со следующего блока. Оказалось — шиш!

Провёл небольшую лабораторную работу.

Исходные данные: tar-архив с исходниками 1,3 МБ (1,300,480).

Методика: пакуем файл со стандартными параметрами, меняем 8 байт по смещению (last_offset / 2) на de-ad-be-ef-ff-ff-ff-ff, пытаемся распаковать и/или восстановить архив.

Результаты:

• 7z — распаковано 47.9%, всё что дальше — не восстанавливается
• bzip2 — распаковано 0%, bzip2recover поделил файл на два якобы годных блока, но первый и больший из них распаковать не смог
• gzip — распаковано 45.8%, gzrecover дает тот же эффект
• lz4 — распаковано 81.76% (на самом деле 100%, но на выходе получился битый tar, который после cpio -ivd -H tar < my.recovered.tar дал указанное значение). Некоторые файлы, правда, с частичным мусором внутри.
• lzip — распаковано 43.1% (спасибо PtiCa, за указания по правильному использованию lziprecovery)
• lzma — распаковано 0%, чем оно восстанавливается — хз
• lzop — распаковано 40.3%
• rar — распаковано 0%, после восстановления (rar r) файл всё равно поврежден
• rar -rr — распаковано 100% (задействовалась recovery record), после восстановления (rar r) у распакованного файла такая же sha1 как и у неиспорченного
• xz — распаковано 47.8%
• zip — распаковано 45.4%, zip -F или -FF дают тот же результат.

  ---

  Ну и чо теперь делать? Паковать всё в .tar.rar?

Хотел напечатать пару листиков на завтра — ага, щаз! Шаттлвроты не дадут нам расслабиться!

Сравниваем:

• zesty (17.04)
• artful (17.10)

Все PPD'шки, похоже, потерялись где-то при сборке, ибо ни в одном пакете, который собирается из deb-src hplip, таких файлов нет.

Ладно, сделал apt-get source hplip, вручную cложил нужные файлы в /usr/share/ppd/hplip/HP/, добавил принтер, запустил hp-plugin install.

И вот тут началось хождение по мукам. Как оказалось, хьюллет убил все прямые ссылки с которых качалась firmware. Там теперь только редирект-страничка со ссылкой на б-гомерзкий sourceforge, где, само-собой, никакой фирмвари нет — только исходники hplip.

Пруф: http://hplipopensource.com/hplip-web/plugin/hplip-3.17.7-plugin.run

Существует официальное неполное зеркало на openprinting.org, но там нет плагина той версии, что нужен в artful (3.17.7). А судя по описанию (http://hplip.sourceforge.net/plugin.conf), должон быть.

Собственно вопрос: ни у кого в кеше нет такого файла?

filename: hplip-3.17.7-plugin.run
size:     2,059,561
mtime:    Fri, 21 Jul 2017 10:41:35 +0000
md5:      ed033f0de3b58ac10c54cf3c017d1bd7
sha1:     2987aa79e08c4642c52eccfc31b7662296484b91
sha256:   3c7acfb8e349332c555c958181c86322a86c33848a11b481040a754d6b5c9db1

cast intelfx (ты указан контрибьютором hplip-plugin'а в AUR'е, может у тебя такой файл остался?)

Столкнулся с непонятным. Вводная: арчик, 8 ГБ памяти, 10ГБ swap.

Система уходит в спящий режим очень долго и так же долго просыпается. Причём, судя по поведению firefox, который съедает примерно треть ОЗУ, происходит странное: сначала память всех процессов переносится в swap, а потом тот же swap пишется на swap-раздел в процессе перехода в спящий режим. Отзывчивость у системы после пробуждения — никакая. Остается, разве что, выполнить комбо swapoff -a && swapon -a и пойти перекурить. Только после этого можно работать.

Кто-то с подобным сталкивался? Как это лечить?

Update: забыл добавить: каждый раздел в софтварном зеркале (хук: mdadm_udev).

Не, ну это капец какой-то.

Мало того, что это лоскутное одяло собрано из кусков KF5 и KDE4 (собственно, в любой более-менее стабильной системе — та же проблема, пример: свежевышедший Leap). Пофиг на глюки и деградацию Apper и Plasma Discover, вместо которых пришлось прикрутить апплет от Gnome PackageKit. Виджет загрузки системы, монитор сети и погоду, я, так и быть, соберу сам, раз уж мейнтейнеры — кедарасы, в плохом смысле..

А сегодня я узнал, что в репах даже telepathy нет. Ну вот как жить дальше, а?

ЛОР, объясни мне, как весь этот чёртов пароход вообще работает?

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

• pk-update-icon — часть gnome-packagekit.
  • Запускается через xdg/autostart.
  • Автообновление кеша включается или через рекомендованный пакет apt-config-auto-update, или нужно вручную установить APT::Periodic::Update-Package-Lists "1";.
  • Дальше, как я понял, всё работает через /etc/cron.daily/apt-compat и /usr/lib/apt/apt.systemd.daily.
• apper — часть KDE4. В 14-й кубунте работал более-менее хорошо, но иногда вешался на интерактивных запросах debconf.
  • Запускался через плазма-виджет, но в stretch плазма-виджет уже завязан на discover и я не пойму как теперь запускать apper. Задачу в anacron дописать?
  • Обновление кеша, судя по всему, сделано с помощью APT::Periodic (см. выше), без установленного apt-config-auto-update, половина настроек тупо неактивна. Сами настройки хранятся в ~/.config/apper. Вот через какую хитрую жопу это всё взаимодействует, а? Конфиг-то пользовательский..
  • Баги: из-за сборки с Qt5 иногда разлезается интерфейс — прогрессбары и иконки скачут и портятся (хорошо хоть не бибикают, и на том спасибо).
  • Проблема с debconf, по идее, должна решаться за счёт debconf-kde-helper.
• plasma-discover — часть KDE5 и редкостно падучее говно.
  • Практически каждый запуск в стандартной установке сопряжен с какими-то проблемами. Может упасть прямо при установке обновлений. Буквально только что показал сообщение о просроченном сертификате c2.static.flickr.com (оказывается, оттуда грузится картинка с кофе для шапки списка).
  • Запускается как плазма-виджет.
  • Такое чувство, что discover конфликтует c apper. Если снести apper, discover стает менее падуч, однако task-kde-desktop ставит их оба и зачем-то ещё unattended-upgrades, у которого вообще собственный сервис. Я чего-то не понял, или это тот случай, когда мейнтейнеры — мудаки?

Есть ещё две прикольные штуки: needrestart и needrestart-session — они показывают те процессы, что требует перезапуска после обновления. Срабатывают по триггеру apt, так что с ними всё просто.

Многие знают, что в VMware Player есть противный баг, когда при переключении в окно виртуальной машины (оффтопика, естественно) мышь начинает вести себя странно. При любом её движении залипает скролл, т.е. все комбобоксы проматываются в конец списка, самовольно изменяется масштаб документа и прочая подобная фигня. Также, давно известно, что этот баг проявляется исключительно при включении в иксах любой раскладки клавиатуры, отличной от «us».

Собственно, что хочу: при переключении фокуса на окно vmplayer, нужно дергать setxkbmap/gsettings/и т.п., принудительно включая английскую раскладку и запрещая все остальные. По пропаданию фокуса, соответственно, вернуть всё взад.

Вопрос: чем следить за фокусом? Есть какие-то готовые решения? Вариант гонять в цикле

xprop -id $(xprop -root 32x '\t$0' _NET_ACTIVE_WINDOW | cut -f 2) WM_CLASS

Не, конечно можно взять какой-нибудь python-wnck и накостылить это дело на нём, но лень же. В С не умею. Менять оконный менеджер не готов.

Всякие штуки типа devilspie в цикле не работают, сразу говорю.