Владимир Чернышев

Использую докер-контейнеры как легковесные виртуалки, которыми куда проще манипулировать. И куда меньше душит жаба для конфигов типа "на этой виртуалке будет работать только nginx, на этой только php-fpm, на этой только postgre, эта будет шарить статические файлы для nginx и php-fpm, тут будет лежать кэш, тут загруженные пользователями файлы, а тут база данных"

1.1 и частично 1.2: Зачастую тупо не знаешь под какой осью твой софт будет работать, даже если он чисто внутренний для компании. Даже (или особенно?) если сервер в компании единственный, админ может решить его обновить из-за критической уязвимости или для установки какого-то другого софта.

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

2. Редкость, по-моему, сейчас когда один физический сервис выполняет ровно одну функцию. Да и раньше как-то не практиковалось, по-моему. Контейнеризация позволяет чётко выделять сервисы и изолировать их друг от друга куда меньшими ресурсами чем виртуализация, как при разработке и деплое, так и в рантайме.

3. Зависимости разных процессов не будут конфликтовать друг с другом. Какой-нибудь унаследованный софт будет работать под уже неподдерживаемым дистром, и тут же будет работать софт, использующий самые последние версии каких-то библиотек.

Что-то серьезное — IDE, в частности IDE от JetBrains (WebSrotm, PhpStorm, RubyMine и т.п). По быстрому что-то набросать — vim/emacs/sublime на любителя. Хотя и в gedit можно плагинов понаставить. Это в плане управления кодом.

Дев-окружение для запуска или аналогичное продакшену (стандартные пакеты, например apt-get install apache2 php5 mysql-server), или встроенное в среде выполнения/фреймворка (php -s), или вообще запуск на VDS.

Ну и консоль, куда без неё, даже с IDE.

Всё, кроме nginx и sshd, слушает 127.0.0.1. root логиниться не может даже локально. Каждое приложение свой набор пользователей. Удаленный вход только по ключам.

Не знаю, правильно ли понял вопрос, но LiveCD Ubuntu работает с ISO образа на винте. Правда со всеми ограничениями присущим LiveCD, прежде всего read-only. Инструменты для кастомизации установки есть.

Он же не отслеживает текущий размер шрифта?

>2. Существуют какие-то примочки, позволяющие привести вид папок в Линуксе к стандартному C:/Program Files?

Этот вид ни разу не стандартный. Стандартный — Filesystem Hierarchy Standard

Для разработчиков (описание интерфейсов) вполне нормально можно использовать %используемый_ЯП%doc и/или тесты. Главное следить за актуальностью, но это для любой документации проблема, но проще документировать прямов коде или тестах (при использовании TDD), чем леззь куда-то.

Мне нравится такая практика по умолчанию:
— если приложение устанавливается в /usr (или другой системный каталог), то логи пишутся в /var/log (для установки в /usr нужны права рута, потому создать и настроить права для записи в /var/log проблемы быть не должно — можно открыть запись для всех, можно создать группу, в которую заносить пользователей имеющих право запуска)
— если приложение устанавливается в ~, то логи пишутся в ~/./log

Вариант вывода логов по умолчанию в stdout для «демонообразных» приложений как-то раздражает.

Своп нужен когда не хватает оперативки. Linux (по дефолту, может есть настройки влияющие на «агрессивность») от «некоторых других ОС» отличается его экономным расходованием, не стремясь иметь под кэши и буферы пол-ОЗУ. Но в этом есть и отрицательный момент — даже программы/данные, которые используются очень редко она будет держать в ОЗУ до последнего вместо того, чтобы выгрузить их на пару недель, а память отдать под кэш. При ваших соотношениях ОЗУ/винта я бы дал свопу гиг-другой (если не жалко) на всякий пожарный и в надежде, что что-то туда выгрузится, но от сообщений типа «can't fork» или «out of memory» это не спасёт, как и выделение под своп, скажем, 16 Гб — если 16ГБ ОЗУ не хватает то в 99% случаев дело в неправильном расходе памят по причине неправильных настроек софта

Очень интересно, только вчера компилился всю ночь mono 2.8.1 (пакетов под debian/buntu не нашёл, те что в репах не захотели с linq работать), завтра буду последний monodevelop собирать, потом собирался разбираться как это хозяйство запустить под nginx без apache.

Особо интересует какие подводные камни могут быть при переносе как проектов (веб), так и сборок туда-сюда (прежде всего сборок из моно/линукс в нет/самизнаетечто — достаточно ли будет избегать каких-то либ и соблюдать какие-то правила (именование путей?, кодирование перевода строки?), чтобы гарантированно запустилось приложение или нужно обязательно тестировать)

Насчёт удаления есть нюансы:
— обычное удаление (apt-get remove) удаляет файлы приложения, но не удаляет настройки (по аналогии с windows — не чистит за собой реестр, да и program files не всегда полностью, какой-нибудь settings.dat останется), то есть установив приложение в следующий раз получите те же настройки, что и были
— полное удаление (apt-get purge) удаляет всё, и программу, и настройки
— автоматическая очистка (apt-get autoremove) — удаляет больше не нужные пакеты (те, что были вытащены по зависимостям для других, уже удаленных, пакетов и больше системой не используются)
Проверка целостности зависимостей apt-get check — может помочь в случае если при установке/удалении возникли фатальные ошибки
Менеджер пакетов Synaptic тоже как-то поддерживает эти команды

Проверить рендеринг (может драйвера не встали) можно командой «glxinfo» («glxinfo | grep render» — пропустить кучу технической инфы) — должны быть строка «direct rendering: Yes» и строка как-то связанная с видеочипом, оценить скорость по «glxgears»

P.S. Я вот в Windows не знал куда что-пишется при установке/запуске приложений, приходилось ставить проги типа Ashampoo Uninstaller и/или FileMon/RegMon, такие неожиданные места временами попадались, что у «наколенных» шаровар, что у «тру» программ от MS