Saboteur

Все адекватные работодатели:

1. Задают вопрос "когда вы готовы приступить к обязанностям", и 2 недели по КЗОТ это вообще минимальный стандарт. А так могут и месяц подождать, вполне адекватно отнесясь к тому, что после увольнения вы хотите взять небольшой отпуск, например. Но это вполне обговариваемо с работодателем.

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

3. Успешное прохождение интервью это еще не означает хороший оффер. Вам может не понравиться компания, не понравятся условия или ЗП или начальник с которым вы собеседуетесь. Не нужно думать что если пошел на собеседование то это точка невозврата. Точка невозврата это даже не подтверждение оффера. Даже увольнение еще можно откатить в некоторых случаях. Нет смысла волноваться по таким поводам.

4. Многие ходят на собеседование даже не предполагая менять работу. Кто-то из спортивного интереса, кто-то на всякий случай посмотреть, а вдруг предложат работу мечты. В таких случаях всегда бывает, что сотрудника нужно ждать и месяц и два. Но такие варианты, конечно, встречаются в основном на уровне mid/senior и выше.

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

Там вроде есть консольная утилита sacctmgr, которой можно и задать и посмотреть лимиты ресурсов, но не знаю может ли это сделать обычный юзер

Я бы посоветовал выяснить об ограничениях у ваших админов - это же всегда кастомные настройки.

p.s. Тут вряд ли нужен тег bash, скорее Linux

Получаем примерную дату за последние сутки с нужной точностью
olddate=$(date -d "-24 hours" "+%d/%b/%Y:%H:%M:%S")
Но тут есть проблема. Если в данную секунду в прошлом не было ни одной записи, мы пролетим мимо. Поэтому округлим хотя бы до часа, но все равно остается риск, если приложение было выключено целый час, то мы не найдем начальную позицию вообще. Как эту проблему решать я не знаю, зависит от того что у вас в файле всегда будет что-то или не всегда и если не всегда, тогда все усложняется. Но давайте пойдем от простого, просто округлить хотя бы до часа:
olddate=$(date -d "-24 hours" "+%d/%b/%Y:%H")

Потом через sed можно найти текст от указанной даты и до конца файла, и тут же фильтруем router:
sed -nE "/$olddate/,\${/router/p}" file.log|wc -l

Ну или однострочник

sed -nE "/$(date -d "-24 hours" "+%d/%b/%Y:%H")/,\${/router/p}" file.log|wc -l

Да любой гит клиент это умеет.
Например в консоли

git ls-files

Ну и любой gui клиент для git должен это уметь.

Не совсем понятно что такое в 14 позицию. Но может быть вам нужно это?

read LINE <1.txt
sed -r -i "5s/(.{13})(.*)/\1\$LINE\2/" 2.txt

Для большинства рекламных сервисов

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

Они знают это благодаря какому-то ключу, который указывает пряом на вас (SDK Key). Следовательно читай документацию этих рекламных сервисов, а точнее в AdMob.

Пока что видно что у вас 4 диска и 3 раздела.
Может быть два диска объединены в зеркало для одного из разделов, или один из дисков не используется.
Покликайте в сами сторы, например в datastore1 или main и посмотрите на чем они сделаны

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

2. Отверстия для крепления расположены несимметрично, неправильно прикрутить не получится (если не применять чрезмерную силу)

1. стандартная служба syslog умеет парсить логи по facility, следовательно можно настроить логирование разных компонентов в разные файлы на уровне syslog, управлять их ротацией.
Также syslog умеет работать с другими syslog, таким образом можно аггрегировать логи с разных машин и управлять ими централизованно.

2. логи отправленные в stdout обычно куда-то перенаправляют, в тот же файл, или сразу грабят в какой-то аггрегатор.
В современное время про stdout чаще всего говорят, когда вы запускаете что-то в контейнере, а контейнер крутится в оркестраторе типа kubernetes/openshift.
В этом случае настраивается внешний сборщик - тот же filebeat, fluentd, logstash или syslog, который собирает логи со всего кластера кубернетес/опенщифт, парсит их и кидает в аггрегатор.
Просто задеплоили новый компонент и по его имени можно фильтровать логи в той же Кибане, при этом нигде не нужно в системе логирования настраивать что-то под новый компонент, все тегируется автоматом.

Если просто обнулить файл, то обычный
echo "" > file
если нужно сохранить часть файла, то можно считать кусок из файла и записать в него же

tmp=$(tail -n 1000 file)
echo "$tmp" > file

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

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

А послойно - ну есть послойная фрезеровка, и есть послойное сканирование в разных диапазонах. Все.
Молекулярный анализатор пока только в книжках. Фантастических.

Есть подозрение, что ты изучил только основы основ С++, иначе не было бы подобного вопроса.
Ты уже написал свою первую простенькую игру на С++?
Ты уже попробовал ее взломать через отладчик?
А ведь это и есть основа reverse engineering?

1. Написано, что ошибка в строке 42-43, а на картинке от силы 20 строк. Ты весь скрипт просмотри, где кавычку не закрыл.
2. Выкладывать надо текст, а не картинку.

В основном такое изучают дома.
Читают много документации по *nix, читают много документации по тому как работает ОС, стандартные протоколы и способы хранения и передачи данных.
Затем много практики, и уже можно пробовать реверс-инженерить.

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

Все очень плохо.
А теперь подробнее.

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

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

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

P.S. Вижу, что топик поменялся с DevOps на Web full stack - в таком случае мой ответ более нерелевантен, но возможно из-за него топик и поменялся =)