Давным-давно пытался я пользоваться сканером Epson Perfection V10. И была у него одна беда: работал он либо под Windows, либо под i386, а на x86_64 драйверов не было. Недавно достал его с полки, сдул пыль, и решил узнать, не изменилось ли чего. Оказалось – изменилось!

Проблема: модули ядра VirtualBox текущей версии не дружат с ядром линукс 4.12 (последним на данный момент). В причины углубляться не будем, скажем только что несколько поменялось управление виртуальной памятью. Решение под катом.

Заметка, чтобы не забыть. При написании TeXовских документов, я использую общий для всех файл biblatex. В основном потому что удобно иметь один шаблон и не думать об этом. Но посылать огромную библиографию в редакцию как-то некрасиво.

Простой способ получить biblatex-файл, в котором содержатся только использованные в документе ссылки возможно следующим образом:

• bibexport -o outfile.bib ${document}.aux при использовании непосредственно bibtex
• biber --output-format=bibtex ${document}.bcf при использовании biber

Определить использование последнего можно по факту наличия bcf-файла после сборки документа.

Кстати, пока не забыл, беспроблемная сборка:

latexmk --outdir=build -f -pdf $document

Ghcjs оказывается иногда незаменим если хочется Хаскеля в JavaScript-окружении. Однако его выдача имеет нередко просто чудовищные размеры.

Решить (или по крайней мере уменьшить) проблему размера возможно с помощью гугловского closure-compiler. Однако в случае сборки под node.js возникает трудность: ADVANCED_OPTIMIZATIONS ломают названия нодовских функций. И все, привет. Есть, само собой, https://github.com/dcodeIO/ClosureCompiler.js, но он отмечен как outdated.

В общем, можно достичь нужного эффекта руками. Для этого следует клонировать https://github.com/dcodeIO/node.js-closure-compiler-externs и включить параметром --externs все *.js файлы оттуда. Вручную это, конечно, грустно. Поэтому я набросал вот такой вот скрипт:

#!/bin/bash
closure-compiler $1.jsexe/all.js --compilation_level=ADVANCED_OPTIMIZATIONS $(ls node.js-closure-compiler-externs/*.js | sed 's/^/--externs=/') --externs=$1.jsexe/all.js.externs > $1.js

Он, само собой, ужасен, но нужного эффекта достичь позволяет.

Замечание: гарантий, что extern’ы корректные, ни у кого нет. Поэтому что-то в каких-то случаях может ломаться совершенно случайным образом. Используйте на свой страх и риск.

Проблема

При нестандартной конфигурации сети, systemd-networkd-wait-online отваливается с таймаутом.

В логах при этом можно найти что-то такое:

systemd-networkd-wait-online[...]: Event loop failed: Connection timed out

Само собой, сервисы, зависящие от systemd-networkd-wait-online, не стартуюут.

Решение

Решение ситуации – явно указать внешний интерфейс, который должен быть поднят чтобы считать сеть рабочей. Сделать это можно, например, создав файлик /etc/systemd/system/systemd-networkd-wait-online.service.d/exec.conf следующего содержания:

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online -i <interface-name>

Вместо <interface-name> следует вставить название интерфейса, например, br0.

Заодно это решает проблемы на системах с несколькими сетевыми интерфейсами, когда только один из них можно считать “основным”, и если он не поднялся – сети еще, в широком смысле слова, нет.

С повсеместным пришествием HTTPS в массы, а особенно в связи с тем, что браузеры собираются помечать HTTP-сайты как небезопасные, возникает резонный вопрос: как сделать себе HTTPS задешево.

Раньше был вариант воспользоваться сервисом starttls/startssl, но в новых версиях Google Chrome и Mozilla Firefox их сертификаты блокируются, что еще хуже, чем отсутствие HTTPS вовсе.

С другой стороны, есть новый-модный-молодежный letsencrypt. Но если нет желания каждые три месяца подтверждать домен вручную (что долго и муторно), нужно гонять на целевом сервере утилиту (например, certbot), а это значит как минимум нужен SSH-доступ, ну или на худой конец webshell, которые прямо скажем не так-то просто организовать.

Дополнительно ситуация усугубляется тем, что на shared-хостинге установка certbot, даже при наличии shell-доступа, может быть совсем отдельным развлечением для мсье, знающих толк.

А что делать если у Вас копеечный shared-хостинг, на котором вообще ничего нет кроме CPanel, MySQL и апача?

Небольшая заметка про xdg-open. Эта утилита открывает файлы или URI “наиболее подходящим” приложением, как записано в файлах *.desktop.

Увы, как показывает практика, “наиболее подходящим” оказывается нередко какой-нибудь Firefox, что явно не всегда самое удачное решение.

Коротко и по делу, можно выполнить что-то такое в консоли:

[].slice.call(
    document.getElementsByClassName("watched")
).forEach(
    function (x) { x.parentElement.parentElement.parentElement.getElementsByClassName("pl-video-edit-remove")[0].click(); }
)

Я уже писал про пейринг устройств Logitech Unifiying, однако прошлые мои решения требовали компиляции сишной программы. Сегодня хочу предложить решение на “чистом” Bash (и dd).

#!/bin/bash

grep -H 'NAME=Logitech USB Receiver' /sys/class/hidraw/hidraw?/device/uevent | cut -f1-5 -d'/' | \
while read syshr; do
	devname=`grep -H DEVNAME "$syshr/uevent" | cut -f2 -d'='`
	if [ -n "$devname" ]; then
		dd if=<(echo -en '\x10\xFF\x80\xB2\x01\x00\x00') of="/dev/$devname" && echo "Pairing mode enabled on $devname"
	fi
done

Скрипт пройдется по всем USB-устройствам, и включит режим пейринга на всех Unifying-приемниках, тупо скопировав “волшебную строку” при помощи dd.

Portage в Git, что может быть прекраснее?

Нужен portage по крайней мере версии 2.2.16.

Во-первых, нужно убрать старое дерево, например mv /usr/portage{,_bak}.

Затем сделать git clone https://github.com/gentoo/gentoo-portage-rsync-mirror /usr/portage.

Теперь обновляем /etc/portage/repos.conf/gentoo.conf, раздел [gentoo]

[gentoo]
location = /usr/portage
sync-type = git
sync-uri = https://github.com/gentoo/gentoo-portage-rsync-mirror
auto-sync = true

P.S. Официальный гайд предлагает держать дерево в /var/db/repos/gentoo. Оставлю на усмотрение читателя, какой вариант более предпочтителен.