Дмитрий Шицков

Тут уже много чего сказано, предложу самый бюджетный вариант.
Поднимаешь WSUS, ставишь на парк зверей windows essential security и обновляешь по мере выхода обновлений безопасности. Из плюсов можно отметить бесплатность продукта и более менее активную защиту. Тестировал более года на филиальном офисе, парк примерно 40 машин, за год ни один пк не был существенно заражен.

Почитать про авторизацию по ssh ключам.

Создаете пару ключей (появятся файлы $HOME/.ssh/id_rsa и $HOME/.ssh/id_rsa.pub
ssh-keygen

копируете публичный ключ на удаленный сервер
ssh-copy-id user@remoteserver (для шелл машин)
для битбакета - в вебинтерфейсе посмотрите в профайле, куда можно вставить публичный ключ - просто скопируйте туда содержимое id_rsa.pub

Для passphrase - либо перегенерируйте ключ без passphrase, либо используйте ssh агент (под виндой например pageant от putty)

1) это не куча процессов, это куча потоков
2) это вполне нормально, бд использует память для кеширования данных, чтобы реже дёргать диск и быстрее отвечать. максимальный размер настраивается в конфигах

Просто так никто ничего вам не выдаст. За денюжку покупаете домен на любом регистраторе. У провайдера покупаете услугу "Фиксированный белый IP". Привязываете этот адрес к домену.

Яндекс принимает их нормально, а Gmail заносит в спам.

Используйте SPF, DKIM, ...

И еще одна проблемка. Видно что данное сообщение отправлено сразу нескольким людям.

$mailer->AddBCC('Ящик 3'); //Добавляет адрес кому отправится скрытая копия

Получатель не будет видеть список всех адресатов.

должен, как и таблицу умножения до 9
хреновый вы сисадмин, который не знает стек протоколов, на котором его сервисы работают

Правильно ли я понимаю что для хранение файлов их нужно разбивать по папкам,

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

Проблемы, про которые Вы могли слышать, связаны лишь с получением полного списка файлов в директории. Да, это долго и тормознуто, но никак не влияет на скорость чтения конкретного файла.

А на боевых серверах использование хранилища в локальной файловой системе и вовсе нонсенс. Там эта проблема не стоит в принципе.

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

допустим на сервер пользователь с Ником username заливает файл file.mp4, и я сохраняю этот файл по пути u/us/use/user/usern/file.mp4 и такой путь формируется для каждого пользователя

Опять неправильно.

Во-первых, никогда, НИКОГДА не доверяйте данным, пришедшим от пользователя. Сохраняете загруженный файл – сгенерируйте имя сами. А оригинальное имя не возбраняется сохранить и в другом месте. Если понадобится дать возможность пользователю сохранить файл под оригинальным именем, это делается в несколько строк.

Во-вторых, Ваша сегментация слишком агрессивная. Если представить, что юзернейм может состоять только из строчных латинских букв и цифр (итого алфавит 26+10=36 символов), то такое хранилище сможет вместить 36 ^ (1 + 2 + 3 + 4 + 5) = 36^15 = 2.21 * 10^23 файлов без повторений. А что если юзернейм короче 5 символов? А что если он переименуется?

Помните "во-первых"? Так как нам нужно самим придумать имя файла, почему бы не воспользоваться либо UUID и сгенерировать уникальное (с высокой достоверностью) значение вида 28c5a6d8-f7b5-440f-aeaa-150e4fd0bebc, а его уже сегментировать? Например, два сегмента по два символа датут прикольные ссылки вида 28/c5/28c5a6d8-f7b5-440f-aeaa-150e4fd0bebc и возможность разместить 65 тысяч файлов так, чтобы они были по одной штуке в директории :)

Есть также вариант использовать не UUID, а посчитать контрольную сумму файла и взять её в качестве имени. Практическая ценность такого хеша, правда, тоже стремится к нулю :)

если будет 2 одинаковых названия файла у одного пользователя то просто добавляю к новому файлу номер (file1.mp4)

Если речь идёт о Джанге, то она сама так делает, это штатная функция хранилища.