Юрий Самойлов

В .htaccess добавить:

<FilesMatch  "^log\.txt$">
  Order deny,allow
  Deny from all
  Allow from 192.168.0.0
</FilesMatch>

Open Sans - это семейство шрифтов.

Regular - это обычный вид начертания. У regular font-weight: 400, стандартный. Подключая Open Sans, вы получаете Open Sans Regular
У этого шрифта вариантов несколько, они могут отличаться насыщенностью, пропорциями, контрастностью и наклоном. Все они есть у гугла
https://fonts.google.com/specimen/Open+Sans

Число перестановок N элементов = N! (N-факториал)

Итог такой.
Если версия заббикс сервера 3.4 и выше, POSIX не подойдет (он вообще не реагирует на него). Нужно использовать PCRE. Итого я сделал сейчас так, работает отлично.

{Windows AD SEC:eventlog["Microsoft-Windows-Backup",,,].logeventid(^[1][9]$)}=1

Для составления своего регулярного выражения нашел хороший сервис для этого https://regex101.com/ , довольно удобно.

Если хочешь показывать видео со своего канала, то ответ написали выше.
Если нет - можно включит управление плеером через АПИ, поставить поверх iframe свой div с каринкой, на клик его прятать и проигрывать видео
https://developers.google.com/youtube/player_parameters (enablejsapi)

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

Вон ознакомьтесь с документом, как там написано, примерно все мы так и запрещаем. Из дополнительного +100.64.0.0 (он относительно недавно добавился)
https://archive.apnic.net/meetings/22/docs/tut-rou...

Вот этот список (так называемые bogons addresses).

В принципе, на сервере можно вообще любой язык программирования использовать.
Чаще всего используются эти:
(картинка с w3tech)

Также стоит рассмотреть и другие языки, использование некоторых из них довольно активно растет, например python, js (node.js), go и rust, elixir и прочие.

При прочих равных, у HP процессор чуть ли не в два раза быстрей - 4 ядра 8 потоков против 2 ядер 2 потоков у Lenovo. Я за HP.

вопросы у вас философские, на каждый можно отвести часы обсуждения

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

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

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)