А нельзя было просто установить систему на виртуальный HDD или загрузиться в live-режиме, подключив iso-образ? Ну ладно, допустим, флэшка нужна, чтобы загрузжаться с нее на ноутбуке. Тогда к чему все эти танцы с флэшкой вокруг виртуального HDD, когда в VirtualBox есть проброс USB-устройств? Очень странное руководство.
А почему не rrdtool? Это же и БД, и графики красивые, и костылей в два раза меньше. Я как-то делал похожую наколенную систему, оно туда очень органично вписалось.
В большинстве случаев стоит делать service xxx reload, где это только возможно, чтобы не портить клиентам жизнь, а также не останавливать и не запускать всего демона целиком. По крайней мере, хотя бы если изменяется только конфигурация.
Команда service является, грубо говоря, оберткой для скриптов из /etc/init.d, где опция restart обычно отправляет демону SIGTERM, после чего заново стартует процесс. Это верно по крайней мере для Debian, где в init-скрипте nginx используется дефолтный сигнал для остановки, и Ubuntu, где сигнал явно указан. У nginx SIGTERM повлечет за собой quick shutdown, при котором все соединения будут разорваны, и демон будет всеми силами пытаться умереть как можно быстрее. Плюс, ничего особо не изменилось, кроме одной строчки в конфиге, так что это тот самый случай, когда лучше сделать reload, ибо старые воркеры будут потихоньку умирать по мере завершения обработки запросов, а новые начнут запускаться уже с новой конфигурацией.
Там же с незапамятных времен еще в Miranda IM можно отключить такое поведение в настройках протокола: смотреть в сторону «server acknowledgement», где-то даже, вроде, капсом было написано «FASTER». Я перенес базу с IM на NG, поведение аналогичное, все хорошо — сообщение появляется в списке сразу, доставка проверяется где-то в фоне, а если что не так, то будет написано, что доставка не удалась.
Риск в том, что в случае взлома атакующий сможет скомпилировать что угодно: если совсем не повезет, то соберет какой-нибудь эксплоит, повысит привилегии и получит полный контроль над системой.
По поводу принципиального отличия, если это серьезный вопрос: использование make install засоряет систему бинарниками в лучшем стиле Windows DLL Hell. Чем больше софта устанавливается таким образом, тем сложнее поддерживать порядок. Причем затрудняется не только банальное управление установленным таким способом софта, но и есть ненулевая вероятность что-нибудь просто-напросто сломать, скажем, перезаписав нужную библиотеку, установленную ранее из репозитория, другой версией, или грохнув нужный Debian-way симлинк (например, Debian Alternatives), а потом долго думать и ходить вокруг да около с strace и ldd наперевес. Чем «системнее» пакет, тем хуже могут быть последствия от make install.
Если есть менеджер пакетов, нужно им пользоваться. Он обеспечивает разрешение всех зависимостей и минимизирует вероятность что-нибудь очень глупо сломать. Если пакет собран адекватным человеком, при его установке для всяческих инвазивных действий будут использоваться системные средства: скажем, если в системе стоит python2.6, можно рядом поставить python2.7, а потом еще и python3, и все три интерпретатора будут доступны, не будут друг с другом конфликтовать, и в любой момент можно запустить update-alternatives, чтобы изменить используемый по умолчанию интерпретатор. И все это через apt-get безо всякой беготни с тарболлами.
А для крайних случаев всегда есть checkinstall или сборка пакета руками.
Интересно, насколько приятно обслуживать только что вытащенный на поверхность сервер, «жирное» ли масло? И всякий ли сервис согласится с тем, что такие условия эксплуатации допустимы в рамках, скажем, гарантийного обслуживания?
Не отличается ровно до первого обновления, ломающего что-нибудь важное, и требующего выполнения странных телодвижений для починки, которые в нормальном дистрибутиве бы автоматически выполнились при установке пакета. Так что поиграться можно, а в продакшн ни-ни.
Поставьте Wakelock Detector, он как раз для этого и написан. Всегда можно узнать, какое очередное гениальное приложение решило не давать телефону спать, выставляя вейклоки CPU по тысяче раз за ночь. Кстати, оно мне помогло диагностировать баг в FBReader, из-за которого приложение, будучи работающим в фоне, не давало телефону погасить экран после срабатывания будильника или нажатия на кнопку питания с целью посмотреть время на локсркрине.
В большинстве случаев стоит делать service xxx reload, где это только возможно, чтобы не портить клиентам жизнь, а также не останавливать и не запускать всего демона целиком. По крайней мере, хотя бы если изменяется только конфигурация.
Команда service является, грубо говоря, оберткой для скриптов из /etc/init.d, где опция restart обычно отправляет демону SIGTERM, после чего заново стартует процесс. Это верно по крайней мере для Debian, где в init-скрипте nginx используется дефолтный сигнал для остановки, и Ubuntu, где сигнал явно указан. У nginx SIGTERM повлечет за собой quick shutdown, при котором все соединения будут разорваны, и демон будет всеми силами пытаться умереть как можно быстрее. Плюс, ничего особо не изменилось, кроме одной строчки в конфиге, так что это тот самый случай, когда лучше сделать reload, ибо старые воркеры будут потихоньку умирать по мере завершения обработки запросов, а новые начнут запускаться уже с новой конфигурацией.
Вот передача Discovery про укладку кабеля по дну океана с подъемом действующего кабеля и врезку в него: www.youtube.com/watch?v=GAmSfd01_6I
Побуду занудой: aircraft aerial vehicle — масло масляное, тут уж либо aircraft, либо aerial vehicle. Кстати, UAV расшифровывается как unmanned aerial vehicle.
По поводу принципиального отличия, если это серьезный вопрос: использование make install засоряет систему бинарниками в лучшем стиле Windows DLL Hell. Чем больше софта устанавливается таким образом, тем сложнее поддерживать порядок. Причем затрудняется не только банальное управление установленным таким способом софта, но и есть ненулевая вероятность что-нибудь просто-напросто сломать, скажем, перезаписав нужную библиотеку, установленную ранее из репозитория, другой версией, или грохнув нужный Debian-way симлинк (например, Debian Alternatives), а потом долго думать и ходить вокруг да около с strace и ldd наперевес. Чем «системнее» пакет, тем хуже могут быть последствия от make install.
Если есть менеджер пакетов, нужно им пользоваться. Он обеспечивает разрешение всех зависимостей и минимизирует вероятность что-нибудь очень глупо сломать. Если пакет собран адекватным человеком, при его установке для всяческих инвазивных действий будут использоваться системные средства: скажем, если в системе стоит python2.6, можно рядом поставить python2.7, а потом еще и python3, и все три интерпретатора будут доступны, не будут друг с другом конфликтовать, и в любой момент можно запустить update-alternatives, чтобы изменить используемый по умолчанию интерпретатор. И все это через apt-get безо всякой беготни с тарболлами.
А для крайних случаев всегда есть checkinstall или сборка пакета руками.
На всякий случай ссылка: play.google.com/store/apps/details?id=com.uzumapps.wakelockdetector