В современном андроиде версии 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
В адиуме хотелось отключить html в отправляемых сообщениях, соответствующий тикет в трекере адиума был благополучно похоронен, поэтому соорудил быстрый костыль в виде патча внизу. Он делает простую вещь: отключает форматирование размера текста в исходящих xmpp-сообщениях.
Может быть позднее сделаю покрасивее, но пока и так сойдёт. После изменений скомпилять по инструкции с офсайта и установить вместо оригинального. После обновления версии процесс повторить.
diff -r 7ccfc3c4195e Plugins/Purple Service/ESPurpleJabberAccount.m
--- a/Plugins/Purple Service/ESPurpleJabberAccount.m Mon May 26 13:34:36 2014 +0200
+++ b/Plugins/Purple Service/ESPurpleJabberAccount.m Mon Jun 23 23:50:02 2014 +0700
@@ -428,7 +428,7 @@
if (!jabberHtmlEncoder) {
jabberHtmlEncoder = [[AIHTMLDecoder alloc] init];
[jabberHtmlEncoder setIncludesHeaders:NO];
- [jabberHtmlEncoder setIncludesFontTags:YES];
+ [jabberHtmlEncoder setIncludesFontTags:NO];
[jabberHtmlEncoder setClosesFontTags:YES];
[jabberHtmlEncoder setIncludesStyleTags:YES];
[jabberHtmlEncoder setIncludesColorTags:YES];
В XCode 7 выпилен opennsl, поэтому просто так собрать не получится. Можно поставить openssl через brew и дальше в конфиге xcconfigs/Base.xcconfig
изменить строчку с флагами компиляции как-то так:
OTHER_CFLAGS = "$(CFLAGS)" -I/usr/local/Cellar/openssl/1.0.2h_1/include
Дальше в XCode меню: Product → Scheme → Edit scheme поменять Build configuration на Release, затем собрать, итоговый билд (файл Adium.app) будет в каталоге типа ~/Library/Developer/Xcode/DerivedData/Adium-gvwbqjdtkfytqnfuyvumtjfzppsb/Build/Products/Release
.
Или как альтернатива — поставить XCode 6 и собрать в нём, скачать можно по этой ссылке: http://developer.apple.com/devcenter/download.action?path=/Developer_Tools/Xcode_6.4/Xcode_6.4.dmg
Задача: монтировать nfs-ресурсы в макоси.
В принципе, в макоси уже встроена поддержка nfs и соответствующие сетевые ресурсы можно монтировать через Finder (⌘K), однако чтобы это работало для обычного юзера, требуется некоторое шаманство на стороне linux-сервера.
И заодно важный момент: я монтирую только на чтение, поскольку если разрешить запись, то макось загадит диск своими служебными файлами.
На линукс-машине в /etc/exports прописываем что-то вроде:
/home/user/downloads 192.168.13.12(ro,sync,no_subtree_check,insecure)
Здесь адрес 192.168.13.12
— это айпишник макосной машины. После чего в Finder стандартным образом (через ⌘K или меню Go → Connect to Server...) монтируем ресурс, адрес указываем в виде nfs://nfs-server.name/home/user/downloads
.
Опция insecure
как раз и нужна, чтобы можно было простым юзером монтировать, без неё будет выдаваться маловразумительная ошибка.
Ещё одна вредная и очень трудноуловимая проблема связана с макосной интерпретаций кодирования «составных» букв в именах файлов, например, «й» или «ё», или «ü». Если имя файла (или вообще где-то в пути до файла встречается) содержит такую букву, то файл просто не откроется, причём с невразумительной ошибкой типа “The application can’t be found.” Я в детали не хочу вдаваться, можете сами погуглить по ключевым словам “mac os x nfc nfd unicode”.
Решение достаточно простое: нужно изменить опции монтирования nfs-ресурсов по умолчанию, для этого добавьте в файл /etc/nfs.conf
такую строчку:
nfs.client.mount.options = nfc
Теперь можно монтировать через Finder и всё будет в порядке.
Ну и команда для всяких тестов, вдруг пригодится:
/sbin/mount_nfs -v 192.168.13.12:/home/user/downloads /Volumes/test
Изначально я планировал написать небольшую заметку о наиболее часто используемых командах, однако в процессе получилось так много пояснений, что весь старый текст пришлось удалить и написать новый в формате полноценного туториала. Текст рассчитан на новичков, никогда нормально не сталкивавшихся с гитом. Я также старался не углубляться во внутренности работы репозитория или редкие малоиспользуемые в обычной жизни команды.
Структура статьи традиционная: знакомство с git, базовые команды, общепринятые подходы, а в конце справка о терминах и концепциях, список ссылок. Я не хочу углубляться в историю создания git и вообще стараюсь писать кратко, по делу и без воды, без слишком детальных объяснений команд, без копипасты манов или книг, однако при необходимости буду давать ссылки на сайты или книги по теме.
Я буду рассказывать только о классической программе git, работающей из командной строки. Все примеры использования предназначены для UNIX-подобных систем, например, линукса или макоси. Все примеры создания или модификации файлов также рассчитаны на UNIX-подобные системы. Почему именно консольный вариант: в гуёвых программах типа TortoiseGit очень сложно понять концепты, их авторы подразумевают, что вы всё уже знаете, а это не так. Почему линукс и макось: терминал в windows очень некомфортен, работать там больно и мучительно. Если у вас Windows, советую поставить убунту в Virtualbox/VMWare, также в комментариях Искандер упоминает git-bash для windows, но я об этом ничего сказать не могу.
Перед вами именно туториал, то есть в идеале вы должны читать его последовательно с начала и до конца, выполняя примеры из текста. У git обширная собственная терминология и куча общепринятых (в рамках git-экосистемы) названий сущностей; я постараюсь рассказать о самых важных из них, а вы постарайтесь их запомнить, они действительно очень важны и пригодятся, когда вы будете читать документацию или книги. Часть терминов я буду давать в переводе (например, «ветка» для слова «branch»), а часть — в транслитерации, так как адекватного перевода слова нет (например, «дифф» как перевод слова «diff»). Я очень не люблю многословные переводы простых слов и стараюсь по возможности ими не пользоваться, для понимания короткие слова важнее длинных фраз. Поэтому привыкайте к словам типа «коммит» или «репозиторий».
В тексте много примеров, они все согласованы с текстом и рассчитаны на параллельное их исполнение в процессе чтения. То есть дошли до примера, открыли терминал, выполнили указанные в тексте команды, порадовались, дальше читаем.
Статья ещё не завершена и будет постепенно дописываться, однако уже написанное радикально меняться не будет.