В unix-системе питоновские пакеты совсем не обязательно нужно ставить в системные каталоги (в /usr/, например). Благодаря virtualenv, пакеты можно установить в любой каталог, инициализировать локально окружение в терминале через специальный скрипт и дальше пользоваться всеми установленными в том каталоге библиотеками и программами. Локальный набор пакетов очень удобен для разработчика, так как позволяет на одной системе переключаться между разными их версиями.

В статье я описываю не только концепт, но и всю процедуру подготовки локального окружения. Сразу же уточнение: всё работает только в терминале, то есть вы запускаете терминал, «активируете» в нём нужный каталог с пакетами и дальше в этом терминале работаете. Базовая операционная система — linux, *bsd или mac os x. Windows я не рассматриваю.

Итак, нам понадобится установленный системно python3. Для линукса он ставится из пакетов вашего репозитория, для макоси — скачивается с офсайта https://www.python.org/downloads/mac-osx/ или через brew. В принципе, можно пользоваться штатной версией из макоси, но она гарантированно не будет последней. Например, в Macos Sonoma 14.5 штатно установлен python3 версии 3.9.6, хотя через brew уже доступна 3.12.3 (июнь 2024 года).

Целевая аудитория этой статьи — айтишники, поверхностно знакомые с понятием цифрового сертификата и сопутствующими техническими стандартами.

Эта статья уже во многом устарела и я рекомендую вместо неё сразу читать новую и полностью переработанную: Ещё больше и лучше о цифровых сертификатах: X.509, PKI, PKCS

Цифровые (электронные) сертификаты используются повсеместно, самая известная область их применения — это шифрование HTTPS-трафика в браузере. В таком виде с сертификатами знакомы все, однако более-менее адекватного понимающих гораздо меньше. Многие статьи на эту тему с самого начала топят читателя в абстрактных и несущественных деталях (например, раз, два, три). Между тем, базовые концепции системы сертификатов очень простые и я о них расскажу в этой статье. Эти концепции в моём изложении не являются абсолютно точными, но зато они помогут «въехать» в тему.

Традиционный дисклеймер: все примеры ориентированы на линуксовую, юниксовую или макосную консоль. Если хотите самостоятельно повторить куски консольного кода, поставьте openssl, например, через sudo apt-get install openssl

По умолчанию GIMP подхватывает все системные шрифты макоси, а их очень много, причём бо́льшая часть бесполезна и только мешает. Из настроек программы это никак не регулируется.

GIMP использует fontconfig для поиска доступных шрифтов, а конфигурационный файл для fontconfig хранится в /Applications/GIMP.app/Contents/Resources/etc/fonts/fonts.conf, поэтому просто открываем его любым редактором и комментируем строчки, содержащие пути к системным каталогам со шрифтами (это /Library/Fonts и /System/Library/Fonts). Можно также добавить свои каталоги, чтобы искать шрифты для редактора специально в них.

Вот пример уже отредактированной секции:

    <dir>/usr/share/fonts</dir>
    <dir>~/Library/Fonts</dir>
    <dir>~/Library/FontsGimp</dir>
    <!--<dir>/Library/Fonts</dir>-->
    <!--<dir>/System/Library/Fonts</dir>-->
    <dir prefix="xdg">fonts</dir>
    <!-- the following element will be removed in the future -->
    <!--<dir>~/.fonts</dir>

Здесь закомментированы каталоги /Library/Fonts и /System/Library/Fonts, а также добавлен каталог ~/Library/FontsGimp (в него я добавил симлинки на действительно нужные системные шрифты из /Library/Fonts).

Дальше перезапускаем программу и всё.

Дополнение 2025 года

Начиная с какой-то версии macos, уже нельзя просто так отредактировать приложение. Операционная система это определяет и не даёт его больше запускать, выдавая сообщение типа App Is Damaged And Can’t Be Opened. Отредактированные приложения попадают в карантин и его извлечь оттуда можно такой командой:

$ xattr -dr com.apple.quarantine /Applications/GIMP.app

После чего запускаем снова и оно должно открыться.

P.S.

Я предполагаю, что вы используете официальную сборку GIMP с официального сайта.

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

Многие выкручиваются так: поднимают на девайсе какой-нибудь сервер (обычно FTP), а дальше к нему подключаются через Wi-Fi; затем можно через любой FTP-клиент копировать файлы с девайса и назад. Есть и недостатки: не очень безопасно и часто очень медленно.

Но выход есть и называется он USB-tethering.

По умолчанию в Time Machine бэкапится практически всё, включая совершенно ненужные файлы и каталоги — кеши, временный файлы и т.п.

В исключения надо добавить вот такие каталоги (для добавления произвольного каталога в селекторе файлов нужно нажать Shift+Cmd+g):

/var/vm

Это каталог с образами памяти, используется для суспенда, они довольно большие и точно не нужны в итоговом образе

/Library/Caches

~/Library/Caches

Разнообразные бесполезные для бэкапа кеши

~/Downloads

Скачанные файлы тоже в бэкапе не нужны

Также дополнительно нужно исключить:

~/Library/Application Support/Google/Chrome/Default/Application Cache

~/Library/Application Support/Google/Chrome/Profile 1/Application Cache

~/Library/Application Support/Yandex/YandexBrowser/Default/File System

Браузерные кеши, если вы пользуетесь профилями в браузере, то придётся ещё и кеши для них исключать (Profile 1 и т.д.).

Образы ненужных виртуальных машин.

Примонтированные защищённые разделы, например, через encfs.

Разнообразные медиа-каталоги, например, ~/Movies.

Каталоги с временными файлами, например, /tmp и ~/tmp (если вы такой локально используете).

Возможно, имеет смысл исключить из бэкапа сетевые хранилища типа Dropbox или YandexDisk.

Исключать из бэкапа каталог с homebrew не стоит, так как файлы из него расползаются по другим системным каталогам.

Есть ещё один подозрительный каталог — /private/var/folder, в него складывает скачиваемые файлы app store, например. И если установка какого-нибудь пакета сорвалась, этот файл будет там валяться. Система иногда при перезагрузке этот каталог чистит, поэтому я рекомендую перед бэкапом перезагружать машину, на всякий случай.

См. также http://essentialmac.co.uk/apple-mac-iphone-how-to/what-folders-to-exclude-from-time-machine-backups/

Если запускать Chrome в KDE с выключённым режимом Use system title bar and borders, то кнопки в заголовке окна всегда будут выравнены по правому краю:

Никакими штатными настройками такое поведение изменить невозможно — Chrome при запуске определяет, в каком Desktop Environment он запускается, и если это Metacity/Compiz/Unity, то берёт часть настроек из gconf, в частности — расположение кнопок в заголовке.

Традиционный дисклеймер — все советы ниже годятся для Debian/Ubuntu.

Заставить Chrome «увидеть» себя в другом DE просто, достаточно выставить в переменной окружения XDG_CURRENT_DESKTOP значение Unity. Глобально это не надо делать, лучше всего сделать отдельный sh-скрипт для запуска такого «модифицированного» браузера. Также необходимо установить пакет gconf2, а затем выставить нужный порядок кнопок, например, выполнив такую команду в терминале (это нужно сделать всего один раз):

gconftool-2 --set /apps/metacity/general/button_layout --type string "minimize,maximize,close:"

Получится примерно так:

Естественно, после таких изменений Chrome будет использовать тулкит Gtk для всяких действий типа диалога открывания файла и т.п.

Естественно, есть и проблемы — настройки прокси теперь будут искаться в настройках gnome/unity, поэтому если хотите их конфигурить, ставьте соответствующие пакеты (например, gnome-control-center) или указывайте прокси в аргументах запуска браузера, а также можно пользоваться стандартными переменными окружения типа (http_proxy, auto_proxy, auto_proxy и т.п.)

А вот готовый скрипт:

#!/bin/sh

export XDG_CURRENT_DESKTOP=Unity
google-chrome

Для второго питона:

python -m SimpleHTTPServer 9090

Для третьего:

python3 -m http.server 9090

Вместо порта 9090 можно указать другой. По умолчанию цепляется ко всем сетевым интерфейсам, но можно указать и конкретный, например:

python3 -m http.server --bind 127.1.2.3 9090

В питоне есть модуль logging, через который приложение может выводить логи, например, в терминал при отладке программы. По умолчанию вывод выглядит просто как сплошной поток текста, однако его можно раскрасить, чтобы разные типы сообщений (DEBUG, INFO и т.п.) печатались разными цветами. Для этого нужно сконфигурировать форматер логов и протащить его в программу, сделать это можно разными способами в ini-файле проекта или внутри самой программы.

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

Чтобы результат селектов в консольном клиенте sqlite3 выглядел по-человечески, нужно в конфиге программы (файл ~/.sqliterc) написать такое:

.headers on
.mode line

При таком конфиге выводе селектов будет примерно таким:

sqlite> select * from track limit 2;
       id = 1
   dir_id = 3
 filename = 01 - хора.mp3
    title = хора
  modtime = 
artist_id = 1
 genre_id = 1
 album_id = 1
    track = 1
   length = 232
     year = 2003

       id = 2
   dir_id = 3
 filename = 02 - айда, недо.mp3
    title = айда, недо
  modtime = 
artist_id = 1
 genre_id = 1
 album_id = 1
    track = 2
   length = 184
     year = 2003

Очень частая ситуация: склонировали репозиторий, накоммитили, а в качестве имени/емейла в лог ушла всякая дефолтная лажа. У меня в глобальном конфиге юзер и емейл не указаны, поскольку у меня несколько разных емейлов для разных репозиториев, поэтому почти всегда забывают в склонированном репозитории прописать корректный емейл и в коммит лог уходит лажа.

Исправить можно, но такие изменения ломают всю историю коммитов и желательно это всё проделывать до отправки набора изменений на другой git-сервер. Итак, последовательность действий.

Сначала в локальном (или глобальном) репозитории выставляем имя пользователя и емейл.

Сначала делаем git rebase -i <COMMIT-SHA>, в редакторе помечаем нужный для изменения коммит как edit, закрываем редактор.

Делаем git commit --amend --reset-author, затем git rebase --continue. И так повторяем, пока не кончатся коммиты для редактирования.

Чтобы изменить самый первый коммит, используем команду git rebase -i --root