Wexter

пытаюсь выполнить ssh 192.168.0.4 -p 2222 получаю фигу

Логично, ведь на 192.168.0.4 слушается 22 порт.
Стучаться надо на ssh 192.168.0.2 -p 2222, тогда 192.168.0.2 поменяет в соединении адреса и перенаправит запрос на 192.168.0.4, пр чем от своего имени-адреса

Не надо, ни изучайте. Пока таких как вы будет много - мне всегда найдется работа ;)

Если массив ассоциативный, то почему вы цифры ставите?

RouterOS

Я ничего не смыслю в этом и опасаюсь, что это на самом деле какая-нибудь адская смесь, которая не повысит вероятность не-идентификации меня, а наоборот снизит.

Первое практически гарантированно приведет ко второму.

Ты скорее спалишся по лигнвистике, чем используя только TOR

Правильный ответ Вам дало Армянское Радио - это ИЗНОС ячеек.
Сколько живёт Flash-память?
SLC < 100k циклов
MLC < 10k циклов
eMLC < 40k циклов
TLC < 5k циклов.
Теперь посчитаем, сколько живёт "Новая" память от Intel(r).
Даже возьмём за основу, те самые 100k циклов. И получим, порядка 100M циклов. Хорошо...
А теперь... положите в эту память стэк, который модифицируется при КАЖДОМ вызове процедуры, да ещё разделен для каждого приложения, и так далее. В среднем, вызов подпрограммы в современных программах это от 10 до 100 инструкций. Пусть программа будет висеть в памяти и работать достаточно редко, но выполнять обязательные вызовы ОС, отвечать на них, возвращать данные через буферы в стэке... и так 50-100 раз в секуду.
Чтобы стереть страницу, нужно опять же, куда-то положить её данные (а у нас НЕТ RAM, есть только эта новая память). Итого - 2 перезаписи на операцию. А если какая-то программа начнёт считать в переменной индекс массива? Она должна храниться где-то в RAM (но у нас-то её нет). Сколько проживёт несчастный сектор? Скажем, при стандартной тактовой частоте в 100МГц? Около 1 секунды непрерывных изменений ячейки.
Довольно неприятно, да?
А RAM износу не подвержена. Во всяком случае, не столь быстрому.
Надеюсь, провёл аналогию достаточно точно?

iperf3

1. Какая файловая система?
2. Во время копирования файлов, учитывали линки? В линукс очень любят символические на файлы и каталоги и даже хардлинки на файлы, которые вообще не отличить.

Что у них ломается - вам никто не скажет.

вечно что-то ломается и в самый ответственный момент я остаюсь без интернетов

Это Вам так кажется, я таких каждый день наблюдаю.
Вам или соглашаться и терпеть, или выбирать другого провайдера.

Если провайдер не дурак, в договоре с вами он максимум может сделать перерасчет, за то время когда не было Интернета.

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

А причины могут совершенно разные:
- возможно линк из большого города к вам в маленький не приходит
- возможно админ молодой еще и тренируется сразу на боевых машинах
- возможно нет согласия в работе команды, и кто-то что-то ставя - ломает другое
- возможно у вас проблемный участок, а проблем в головной офиса нет. Его решать надо коллективно и в зависимости от проблемы.
вариантов куча и каждом случае свой.

Картинка для наглядности:

Чатики - за рабство
Фриланс - за деньги

Без навыка самообучения ты никому не нужн

Обсуфикация, ioncube, zend guard, авторизация на внешнем сервере, прявязка к домену и т.д., но если захотят - расшифруют, уберут ограничения и выложат.

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

Тем, что отвечать на пинги - не прямая обязанность коммутатора, и делает он это, скорее всего, с низким приоритетом. А вот передача пакетов между компьютерами идёт в высоком приоритете, соответственно выполняется быстро.

1. Поискать в интернетах Youtube JS API
2. В БД привязать к песне хеш видоса с ютуба
3. При нажатии на кнопку "плей" получаем id песли, лезем в базу по айди, получаем хеш видоса, отдаём его яваскрипту и просим апи ютуба показать нужное видео у нас на сайте.

Не думайте о доменах. Вы смешали администрирование и программирование. Не нужно никакого dev сервера. Делайте работу на локальной dev машине, отправляйте изменения в удаленный репозиторий и всё. Можете вообще не устанавливать nginx/apache и т.д. на локальную dev машину, чтобы не забивать голову всякими доменами, а проект запускать под встроенным PHP сервером например из корня проекта и тогда будете обращаться к вашим сервисам по адресу localhost:port/service1/index.php, localhost:port/service2/index.php и т.д.

Домены будете создавать уже на продакшене. В простейшем случае склонируете на продакшн машину удаленный репозиторий проекта и в конфигах nginx нужно будет написать что-то типа такого

server {
  server_name company.com;
  root /home/www/company/frontend;
 ...
}
server {
  server_name admin.company.com;
  root /home/www/company/backend;
 ...
}
server {
  server_name service1.company.com;
  root /home/www/company/service1;
 ...
}
server {
  server_name service2.company.com;
  root /home/www/company/service2;
 ...
}

Есть еще мнение, что каждый разраб должен разворачивать себе локальное окружение на своем компе, но хз...

Так и делают. Разработчикам не нужен никакой dev сервер. Они клонируют репозиторий, делают что-то локально у себя и отправляют изменения в удаленный репозиторий. Для тестеров и всяких менеджеров просто поднимают так называемый stage-сервер где они и тестируют приложение, но это тоже самое что и продакшн сервер, просто доступ к нему только внутри компании. Можно настроить continuous integration чтобы все изменения из репозитория в master ветке автоматически бы приводили к деплою приложения на stage и продакшн сервера. Примерно так в общих словах устроена веб разработка.