Saboteur

Почему неудобно запускать сервисы?
Почему нельзя смотреть тлоги?

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

xml это не просто markup language, на базе которого уже создается формат записей.
Нет единого xml для кого-то.

Можно поискать импортеры и экспортеры для разных движков, или руками полазить по тегам и написать какой-то импортер который будет читать xml и кидать все в базу, или в формат, который понимает ваш движок.
Для самого вордпресса есть довольно много утилит, чтобы импортировать туда записи из ЖЖ, или еще откуда-то.
Надо смотреть есть ли утилиты для того движка, который вы выбрали.

И возможно ли оттуда транслировать видеострим? смысл в том чтобы просчитать все на сервере и отдать клиенту видеострим.

Предлагаешь, чтобы на сервере стояла графическая карточка для каждого юзера?
Ну возьмем сервер,где играет 100-200 человек. Нужно 100-200 видеокарточек на сервере.
Хочешь 1000? 1000 карточек? Тут тупо на электричестве сервер разорится.

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

Главное чтобы интернет был норм

Давай посчитаем как отдавать видеострим.
Берем например ну хотя бы hd 1920x1080x4 (2 млн цветов). Получаем 8294400 байт один кадр ( 8 мегабайт). Ты же хочешь нормальный фпс, ну хотя бы 50 в секунду, 400 мегабайт в секунду. на одного юзера.

Хочешь поговорить о крутом сжатии? Так вот, оно не работает на кадрах. Оно работает на стримах, когда можно проанализировать некоторое количество кадров и уже работать от них. Тогда надо решить вопрос сколько кадров мы будем удерживать для анализа и сжатия, перед тем как куда-то передавать. Игры типа контерстрайка, где 5-10 мс имеют значение сразу улетают в трубу. Сжатие может быть разным, в зависимости от того как резко меняется картинка, а неравномерность лагов хуже чем постоянный лаг. То есть надо решить еще и этот вопрос

То есть сжимать стрим на уровне кадров, если мы не можем их полноценно анализировать.
Нормальные современные кодеки умеют и в А-фреймы и Б-фреймы, то есть жмут в обе стороны. Плюс не ограничены во времени. А у нас и время поджимает, и генерация ограничена количеством кадров которые мы можем вместе использовать. В итоге сжатие будет не 90% как в современных видеокодеках, а хорошо если сожмет треть, и качество будет теряться. И трафик уменьшитсья ну до 50-100 мб/сек.
Теперь подумаем что у клиента отличный инет. А у сервера будет 50-100 мб/сек на КАЖДОГО игрока? Это какой канал должен быть у сервера для поддержания 100-200 игроков? А 1000?

В итоге твоя идея технически совершенно не рабочая.

Облачный хостинг сталкивается с теми же проблемами - лаги, хромает качество видео, в результате играть в мультиплеер становится проблематично. Более-менее можно играть в синглплеер, где милисекунды не так критичны. Но тут нужно понимать что облачный гейминг это не 1000 игроков на одну серверную, а пару десятков тут, пару десятков там, спрос на него не слишком большой, поэтому и бизнесом этим мало кто занимается.
Отдельный плюс облачного гейминга бывает в том, что игры могут быть уже оплачены, и можно поиграть во что-то что лень себе покупать.

Что значит сглаживается?
Не путаешь ли ты сглаживание шрифта, адаптацию под DPI монитора(cleartype), и банально нативную отрисовку векторного TrueType шрифта?

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

Сильно сомневаюсь, что существует хороший аналог ntfs прав в линукс среде.
Базовые права там совсем не такие, а селинукс для этого решения слишком громоздкий.
поддержка ntfs на линуксе не совсем полноценная, она просто достаточная для многих случаев, но прям не полный аналог.

Лучше немного отступить от своей текущей конфигурации, и посмореть можно ли реализовать свои хотелки именно в рамках стандартов самба + стандартные POSIX права доступа.

Надо разобраться как работает экранирование и разные типы кавычек в шелле.

TEXT_ARTIFACT_URL_HREF="Ссылка на артефакт: <a href=\"$TEXT_ARTIFACT_URL\">Download Artifact</a>"

Автоматом в телеге наких настроек нет, только скриптовать.
написать скрипт, который берет список участников из основного канала, и периодически выдает админа с правом "писать сообщения" в привязанную группу.
Можно и наборот, сравнивать и убирать.

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

Можно и обычный ставить.
Разница может быть в том, что оригинальный использует более дорогую технологию, типа подшипниковый. Он громче, зато годами без проверок будет крутиться.
Ну и плюс переплата за бренд.
Может быть еще какой-то вариант умного вентилятора, который может материнке сообщить что он перестал крутиться, там надо смотреть.
В принципе за прошедшие годы технологии подешевели, и дешевый вентилятор может все это тоже уметь и работать не хуже, разве что проверять что он крутится нужно периодически.

Пользователи сами настраивают свой личный сервер для переписки

Уязвимость номер раз, требуется квалифицированный пользователь, который понимает как и что он настраивает и может оценить риски.

Мессенджер использует симметричное шифрование, а ключи передаются между пользователями в оффлайн-формате.

Уязвимость в оффлайн формате какая-то есть. Если они передают друг другу по бумажке - одно. Если по телефону, или почте - то что за телефон, что за почта, могут ли пользователи оценить риски?

Сообщение шифруется локально на пк отправителя и отправляется на сервер, откуда пользователь получает его, если он в сети. Расшифровывается сообщение локально на пк получателя при помощи полученного от собеседника ключа шифрования.

Как проверяется, что сервер не дешифрует сообщение?

Притом, на сервере хранится только последнее сообщение каждого пользователя(история не сохраняется)

В каком виде? Дешифрованном или шифрованном? Какова вероятность компроментации сервера?

Ну и что за шифрование используется, насколько легко оно сейчас ломается, и как часто меняются ключи, учитывая сложность обновления ключей....

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

Ну и вообще, такой мессенджер скорее всего бесполезен. Если пользователи настолько опытные, что могут арендовать и настроить виртуальную машину, поставить и настроить там сервер, подключить к нему клиент, обменяться ключами, то в чем проблема ПРОСТО установить сервер, подключиться любым ссш клиентом и уже на самом сервере пообщаться в talk/write ?

Что-то не то с вашей консолью. | и > редиректят совершенно одинаково, не может одно работать, другое не работать.
Или что-то у вас еще вокруг хелма делается или непонятно.

Так собственно через ссылку и своего бота оно и делается.
Ссылку проще всего кидать через inline keyboard
Ссылка может запуститься только в приватном чате с ботом, в общих чатах следует создать ссылку на своего бота с предустановленным start=something, которая при старте в приватном чате запустит нужное приложение

повезло что я переименовал тогда файлы и сейчас нахожусь на предпоследней версии.

Вот тут ничего не понятно.
Гит ничего не удаляет, если оно было закоммичено. Возможно вы просто что-то правили локально, но забыли добавить и закоммитить?
и файлы переименовывали не через git mv

Не совсем понятно, где его заполучить. Чтобы получить этот опыт, нужно джуном устраиваться что ли? Это же бред какой-то. Или всё-таки предыдущий опыт как-то котируется в глазах HR-ов и прочих рекрутеров?

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

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

И там и там же руль.

Ну да, можно переключиться на другой язык. И опыт поможет. Но нужно брать и учить. С потолка опыт не придет. Придется потратить сколько-то лет

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

опять же, пока человек молод, мозг можно развить таким образом, чтобы на "быструю память" выделялось больше нейронов, так сказать привычка удерживать в "буфере" бОльшую цепочку. Чем человек старше, тем больше мозг решает задачи так, как привык до этого.

Но со стороны кода можно все упрощать.
Это делается декомпозицией кода на кусочки - функции или объекты с методами.
Для этого используется конвенции для именования переменных, функций, объектов, методов так, чтобы по названию было легко понимать их предназначение и возможно тип. Тогда не нужно в голове держать все нюансы, ты видешь глобальную цепочку.
Ну и стиль переносов, для облегчения чтения.

Ну и да, есть проекты, в которые чтобы нормально вникнуть, нужно много времени, месяцы, годы.
Поэтому собственно и стараются сейчас не писать полностью кастомный код, а пользоваться готовыми фремфорками, которые предлагают определенные паттерны.
Учат собственно общие паттерны и так далее.