Для приведенных целей вполне достаточно ресурсов любого современного телефона. А ваш вопрос выглядит примерно так "стоит ли мне переплачивать 8 234.04 pyб. за 2% увеличение производительности, которое я не буду использовать"
Добавьте еще столько же и купите лучше 15", если нужна мобильность, то лучше взять air, а по уровню комфорта работы 15" гораздо лучше 13".
Вы уж извините, но это обсуждалось стотыщ пицот раз, можно было воспользоваться поиском:
строка команды в кроне не должна содержать относительные пути, потому что переменная PATH в среде выполнения cron отличается от стандартной /path/to/command в место command /usr/bin/php file.php в место
file.php
#или
php file.php
а если в теле скрипта присутствуют относительные пути, то cd /path/to/script && /usr/bin/php file.php
Если вы сами не знаете о том, какой нужен объем под ваши задачи /var, /boot и т. д., то и не надо отступать от автоматической разметки, которую предлагает установщик, не создавайте себе проблем.
/boot принято ставить на ext2, так как отсутствие журналирования положительно сказывается на производительности
/tmp в современных системах монтируется в tmpfs(ram), потому что современные объемы памяти это позволяют и незначительное снижение io на диске положительно сказывается на производительности и рабочем ресурсе (особенно актуально для ssd)
Ну в целом-то оно, конечно, верно все. Но при повторном запуске переменная db будет в первоначальном состоянии.
Значит надо это дело куда-то сохранять, например писать в файл. Сценарий такой: открываем файл, читаем базу. Это ок.
Когда добавляется юзер надо добавить запись в базу + добавить запись в файл. Это уже не ок, потому что может вызвать несогласованность данных в этих 2-х словарях.
А если программа вылетит с ошибкой во время добавления пользователя? Значит надо предусмотреть срочный дамп текущего экземпляра словаря в файл при выходе. Это тоже не ок.
Можно продолжать так еще много, но я тут остановлюсь и просто скажу, что идея плохая. Бородатые дядьки почти 50 лет назад придумали классные штуки для работы с данными и сейчас они называются "традиционными", не нужно изобретать велосипед.
Если цель не выходит за рамки самообразовния и если "доступным языком", то для поверхностных знаний хватит и педивикии.
В любом другом случае, там одной кнжки будет чрезвычайно маловато =)
Можно все, но при этом вы не будете хорошо знать ни один из них.
Если python + R еще понятно, то в случае с си, плюсами и джавой - непонятно совершенно, зачем?
Да, человек выше все правильно сказала - через UDP keepalive поддерживать дело неблагодарное, используйте еще один сокет tcp для контроля. А может быть и просто отказаться от UDP.
listen.backlog это параметр backlog функции TCP listen того сокета, на котором висит fpm
параметр backlog отвечает за размер очереди одновременно _ожидающих_ подключений к сокету, то есть инициированных (SYN - SYN,ACK - ACK), но еще не принятых сервером (established)
-1 использует текущий hard limit net.core.somaxconn, можно открыть исходники и убедиться в этом самостоятельно. Значение по умолчанию в линуксах равно 128 и этого более, чем достаточно для любого php-fpm.
Прежде чем браться за любой ЯП, нужно понимать как программировать, как это работает изнутри и конечно же алгоритмы. Для этого лучше подходит С без плюсов.
Пишите код только для закрепления каких-то моментов, не нужно торопиться говнокодить свои велосипеды, таких программистов, которые осилили только половину книги, сейчас миллионы по всему миру. Все они говорят, что знают С++ имя опыт в несколько лет, а написать функцию нахождения максимального числа их 3-х не могут.
Пытался прикрутить Celery, но выглядело это как костыль, и я написал очень примитивный алгоритм запуска тасков внутри приложения Flask с сохранением промежуточной информации о выполнении в уже существующей базе данных. Таски выполняются в отдельных тредах.
Минимальный оверхед и еще 100 строчек кода для того, чтобы синхронизировать и восстановить таски после дауна uwsgi.
Ваш пароль не такой трудный на самом деле, как вам кажется. Вы его засветили где-то еще или он у вас на почте висит в письме от хостера.
Какой-то дилетант брутфорсит ssh пароли. Повезло еще, что вам попался не самый серьезный кул хацкер, тогда вы бы еще пару лет не узнали, что сервером пользуется кто-то еще.
Поменяйте пароль, запретите логин для рута (жалательно это делать сразу как только устанавливается любой сервер), ребутните сервер и смотрите что пишет `ps aux` и конфиги веб-сервера. Маловероятно, что там что-то останется рабочее.
Но если серьезно подходить к проблеме, то при любых подозрениях на взлом делают реинсталл системы, это самый быстрый и эффективный способ лечения всякой нечести.
Есть всего несколько достойных систем, которые активно используются, разрабатываются и поддерживаются:
Zabbix
Munin
Zenoss (вроде как поддерживает nagios плагины)
Nagios
Opsview (на базе nagios)
Каждая из систем из коробки предоставляет очень-очень базовую функциональность, руками допиливать придется многое (в данном случае еще и натягивать Drupal). Поэтому сильно заморачиваться на выборе не стоит. Для инфраструктуры типа вашей подойдет любая из перечисленных.
У меня используется Zabbix, кое-где OpsView. Последний по-проще.
Верстать на макбуке можно, основной проблемой является тестирование - решается установкой нескольких виртуальных машин, мощностей для этого на современных машинках хватает с достатком. Ретина уже плотно вошла в современность и поддерживается везде.
Чтобы не было желания сделать апгрейд через неделю нужно просто купить достаточно мощный ноутбук сразу, с достаточным объемом оперативной памяти и SSD. Темп развития железа уже давно стремительно падает, модели макбуков в техническом плане меняются мало, поэтому в апгрейде практически отсутствует смысл.
Синхронизация происходит в фоновом режиме самостоятельно.
Если в настройках OS X в разделе iCloud галочка на Safari стоит, то синхронизации может препятствовать плохое соединение на телефоне, попробуйте включить на нем "нормальный" wi-fi.
В любом сервисе Apple нет возможности принудительно заставить произвести синхронизацию между устройствами. Некоторые советуют инициировать это с помощью вкл/выкл сервиса iCloud, но помогает не всегда.
Можно поднять DKIM/SPF/PTR/DNSSec и так далее еще 10 наименований, но какой-нибудь местный почтовый монополист в Германии, к примеру, обязательно в один момент скажет, что ваш шаблон письма не удовлетворяет требованиям нашей новой системы автодетекта спама, но почему - мы вам не скажем и будем все письма с вашего домена переносить в папку junk.
Поэтому вот aws.amazon.com/ses
Ничего, абсолютно ничего. Mac OSX десктопная система, смысла от ее использования в качестве серверной практически нет.
Даже для билдов/тестов это бессмысленно, потому что проще+дешевле+быстрее будет запилить для этого несколько виртуальных машин.
Хотите побаловаться - купите макбук в качестве переносной рабочей станции, air модели сейчас стоят не дорого.