Буквально сегодня состоялся разговор по поводу того, что на
GitLab Pages нет возможности автоматически обновлять сертификаты
Let’s Encrypt (которые протухают каждые 90 дней) и что данная возможность есть на
GitHub Pages.
Кроме того, сегодня как раз подошла череда обновления сертификата, заодно что-то меня потянуло поглядеть статью в документации GitLab по настройке интеграции с Let’s Encrypt:
Let’s Encrypt for GitLab Pages
И что же я там вижу:
Let’s Encrypt for GitLab Pages (manual process, deprecated)
Warning: This method is still valid but was deprecated in favor of the
Let’s Encrypt integration introduced in GitLab 12.1.
Воу! С радостным предчувствием иду по указанной ссылке и таки да, они завезли автообновление сертификатов!
Но если интересно, как это было сделано вручную, добро пожаловать под кат.
Очень полезный ресурс от Андрея Пономаренко (
тыц,
тыц) как для разработчиков библиотек, так и для маинтейнеров разного рода софта. Позволяет мониторить изменения в
API/ABI интерфейсах библиотек:
Все доступные инструменты можно глянуть на странице
Reports.
Инструменты, используемые для анализа можно изучить на странице
Open Source. При помощи оных вполне можно организовать мониторинг изменений для вашего проекта или библиотеки.
С удивлением для себя обнаружил, что
Homebrew, который использовал несколько раз для установки пакетов и сборки/портирования софта на macOS, вполне себе может использоваться и на Linux и даже в среде WSL на Windows:
нет возможности (если есть - поправьте) зафиксировать версию/срез репозитория
Второй пункт особенно полезен для создания воспроизводимых окружений для сборки софта с последующей дистрибуцией. В этом отношении
MXE даёт фору: там попросту можно восстановить окружение используя номер коммита GIT.
Ну и для Windows я бы предпочёл окружение
MSYS2 с pacman в качестве пакетного менеджера.
Но, оно может оказаться полезным для установки более свежего софта без прав администратора с возможностью быстро откатиться (просто удалить директорию с установленным барахлом) на всяких LTS дистрибутивах.
Ну точнее не совсем. Статичный сайт на то и статичный, что вся генерация производится где-то там. Но иметь возможность получить ссылку на файл для редактирования конкретной страницы - достаточно удобная вещь.
http://domchristie.github.io/turndown/ - уже из исходного текста. Может показаться удобным, для статей изначально оформленных в HTML (некоторые блогодвижки). Или открыть исходный код страницы, и скопировать нужный текст.
Оба конвертера JS-онли, могут работать непосредственно из браузеров, исходники прилагаются:
Digi-Key предоставляет символы и корпуса для компонентов, которыми они торгуют в формате понятному для KiCAD. И выкладывают их на GitHub. Кроме того, есть символы и от некоторых партнёров (репозитории разделены).
Помимо этого они же опубликовали учебный курс по работе с KiCAD на YouTube.
Не всегда рисовать таблицы в Markdown разметке удобно, особенно добавлять/удалять колонки (со строками всё намного проще). Да и просто следить за соответствием вводимых данных конкретной колонке. И вот совершенно случайно набрёл на ресурс:
Tables Generator
В визуальной форме вводятся данные таблицы, потом нажимаем Generate и копируем полученный код в текст. Просто.
Для редактирования можно скопировать таблицу и импортировать её через “File → Paste table data…”, естественно при условии корректности данных. Кроме того, можно данные для таблицы импортировать из CSV (“File → Import CSV File…”), как работает эта функция я не проверял, скорее всего могут возникнуть проблемы с пробелами или разделителями.
Что ещё? Вообще там можно создавать таблицы не только в разметке Markdown, а в:
LaTeX
HTML
Text
MediaWiki (вот где абсолютный треш!)
Схожие ресурсы:
TableConvert Online - в каком-то смысле, возможностей больше, но есть мелочи, например: нельзя задать выравнивание колонки.
Typora - редактор Markdown, есть встренный редактор таблиц.
QMapShack умеет работать с сетевыми картами, которые представлены в виде тайлов с определённым соглашением о вызове. Что бы работать с подобными сервисами нужно создать файл-описание с расширением .tms. Описание формата можно
почитать здесь.
До недавнего времени я обходился в основном картами OpenCycleMap, TMS файл для которых идёт вместе с QMS. А для нужных районов уже искал/скачивал листы карт ГГЦ (в народе: “новый” генштаб) и делал им обвязку в виде .vrt файла (такие карты содержать описание нужных преобразований, не затрагивая самих исходников карты, тем самым можно делать “обрезку карт” и они понимаются всем, что использует GDAL).
Но это дело малость меня достало и захотелось быстро под рукой иметь и ГГЦ карты. Естественно, при условии наличия доступа к сети и доступности сервисов.
Что возвращать из обработчика IOCTL в user-space если данный IOCTL не поддерживается? В нашем драйвере активно использовался ENOIOCTLCMD. Проблема в том, что он объявлен в linux/errno.h в заголовке которого написано (вольный перевод):
не использовать в пользовательском коде
В данном случае, под пользовательским кодом стоит понимать всё, что не собирается в дереве ядра. Кто-то может не согласить со мной в этом аспекте, но по соображениям переносимости - лучше этому следовать.
Кроме того:
этого кода нет в пользовательских errno.h/cerrno;
для этого когда strerror() вернёт что-то вроде: Unknown error 515 (номер может и отличаться);
константы для этого кода ошибки нет на других платформах (Windows, MacOSX, FreeBSD).
Что использовать-то? А использовать не совсем очевидный: ENOTTY.
Изначально, да и согласно комментариям в include/uapi/asm-generic/errno-base.h:
Not a typewriter
При этом утилита пользовательского пространства errno из комплекта
moreutils говорит:
ENOTTY 25 Inappropriate ioctl for device
Дополнительными аргументами:
интернеты тоже подсказывают такую трактовку;
в ядре Linux оно используется по такому же назначению.
В чём же отличие? Нашёл отличное объяснение в
block/ioctl.c:
* Is it an unrecognized ioctl? The correct returns are either
* ENOTTY (final) or ENOIOCTLCMD ("I don't know this one, try a
* fallback"). ENOIOCTLCMD gets turned into ENOTTY by the ioctl
* code before returning.
Не буду переводить, просто поясню: ENOIOCTLCMD используется во внутренних реализациях, когда есть предположение, что обработку можно выполнить в каком-то стандартном русле, выполнить т.н. fallback. В пользовательское пространство должен вернуться ENOTTY. Точка.
Буквально вчера столкнулся с таким вот поведением QtC:
С учётом того, что я собираю QtC из исходников master-ветки репозитория, первая мысль была: что-то поломали, нужно по быстрому разобраться и откатить. Но всё оказалось чуточку интереснее. Кому интересно - добро пожаловать под кат.
Для Windows драйвер писать в QtC никто в здравом уме и трезвой памяти не будет. Поэтому речь дальше по процессу разработки драйвера для Linux. Я не буду касаться вопросов использования отладчика (KGDB), в основном посмотрим на вопросы запуска модуля ядра на удалённой системе.
