Евгений

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

По поводу адресации 64х бит. Насколько я помню адресные линии современных процессоров материнских плат так и не достигли этого размера. Что такое вообще - полный объем памяти с 64х битами - это больше чем во всех датацентрах вместе взятых. Посчитайте сами. Простая арифметика. Каждый бит - удваивает количество железа на борту. Сколько щас Intel Core способен адресовать? Я не помню. Пускай знающие подскажут.

Тоесть когда мы говорим 64 бит - то надо уточнять какие на самом деле биты имееются в виду. Доступная память для процесса? Ну да. Может быть.

IBM в 20м веке выпускала железки с 128 битной адресацией но там смысл указателя был немного более сложный. Что-то вроде бесконечной виртуальной ленточной памяти.

А 64х разрядные регистры были еще у первых Pentium MMX в 90х. Но это не имело отношения к адресации памяти.

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

https://ip-ranges.amazonaws.com/ip-ranges.json
https://www.geeksforgeeks.org/read-json-file-using...

делается за 3 минуты в notepad ++

1) копирование файла
2) сортировка строк с удалением дублей
3) очистка блока с IP адресами

Значит сразу скажу что у меня для вас - плохие новости. DynamoDb как и многие ему подобные облачные key-value решения расчитаны на выборку по сету ключевых полей. Обычно это хеш-ключ и ключ диапазона. В этом случае вы платите немного. Если вдруг вы решили выбирать по не-ключевым полям это уже будет другое тип запроса. Называется scan. Его можно писать на любом языке разработки но суть в том что будет выбрана ВСЯ таблица. Если она большая - то charge за текущий период вас неприятно удивит. Фиксить это почти невозможно. Это неправильный дизайн и неправильное использование AWS Dynamo. Вам следует вообще отказаться от использования Dynamo и думать над тем как НЕ делать сканов в будущем. Можете теоретически создать индекс по хвосту от строки. Но индекс с точки зрения Динамо - это копия таблицы просто по другому расположенная и реплицируемая. Вобщем не советую тоже.

Официально производитель этот ноут с линем не продает, значит, и тюнинговать не разбежался.
Готовенького не будет, только если готовы пилить все сами.
Тут может быть полезной АрчВики, где перечислен ряд грабель и даются некоторые советы по тюнингу.
В какой системе вы будете его делать - по большому счету, не так важно. Из коробки, с настройками по умолчанию, вы везде получите примерно ту же картину, что описывали с Убунтой.

А это точно массив? Или все таки словарь?
Работа со словарем

# Код Python для демонстрации
# разделить словарь
# в ключи и значения

  
# инициализация _dictionary

ini_dict = {'a' : 'akshat', 'b' : 'bhuvan', 'c': 'chandan'}

  
# печать iniial_dictionary

print("intial_dictionary", str(ini_dict))

  
# разбить словарь на ключи и значения

keys = ini_dict.keys()

values = ini_dict.values()

  
# печать ключей и значений отдельно

print ("keys : ", str(keys))

print ("values : ", str(values))

Зафигачьте всю development инфраструктуру в терраформ и поднимайте только тогда, когда есть необходимость, затем все удаляйте (останавливайте EC2, отключите/не используйте в autoscaling in dev) Создайте для это отдельный aws account и/или дочернюю aws организацию - так будет правильно! Dev и Prod должны быть разные аккаунты - best practices!

В AWS белый IP не назначается системному интерфейсу инстанса. Это фича AWS. Не надо лезть в систему для настройки сети, совсем не надо. IP аттачится из консоли управления на инстанс, но не принадлежит ОС, поэтому парни выше правильно пишут, что надо биндить сервис на 0.0.0.0

1. Реальные кейсы написания и использования Bash скриптов, какие задачи они решают?

Да почти все можно на bash скриптах.
Автоматизация рутины
Склейка разных процессов в единый пайплайн
Системные вещи (копирования, бэкапы, синхронизация, запуски других процессов, даже простой мониторинг)
bash это кроме всего прочего неплохой универсальный скриптовый язык, и отсутствие библиотек восполняется готовым набором консольных утилит на все случаи жизни.

2. Сколько часов, ориентировочно, потребуется на изучение и практику написания скриптов на Bash, как глубоко погружаться?

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

3. Что должен уметь написать на Bash junior/middle/senior DevOps?

Слово все тут подойдет.

4. Возможно для на Bash скрипты стоит потратить день-другой, уметь писать базовые скрипты и переходить к изучению Python?

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

Python:

1. Где и для чего используется Python на практике DevOps, реальные, повседневные кейсы использования?

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

2. Каким уровнем знаний Python должен обладать junior/middle/senior DevOps? (Знакомый middle DevOps и Python не знает от слова совсем).

Если ты знаешь питон на уровне сеньор, то не факт что тебе будет интересно работать на позиции девопс. Можно работать девелопером на питоне.
Поэтому знания питона на уровне джуниора обычно достаточны. Но нужно понимать, что джуниор - это не тот, кто знает две команды. Это полноценный разработчик, который знает и структуры данных и стандартные библиотеки и все конструкции. Уровень джуниор в языке программирования должен позволять устроиться на позицию джуниор разработчика.
Девопс инженер, который знает язык программирования на уровне джуниор разработчика - полезный человек, который сам решил углубиться в питон. И в айти области часто людям что-то нравится и они этим занимаются и углубляются вне зависимости от рабочих задач.
Поэтому у большинства именно девопс инженеров знания именно о языках программирования немного отрывочные, но их хватает для написания универсальных скриптов и небольших утилит.
Я в свое время писал простые и не очень вещи на ANSI C/С++/java/python/perl/actionscript. Сейчас почти все делаю на bash и иногда python, и все предыдущие знания мне помогают выбрать чем воспользоваться - написать что-то свое, найти готовую реализацию на другом языке, попросить в проекте, чтобы написали задачу (это тоже вполне себе способ для рабочих нужд договориться с разработчиками о написании нужного функционала для автоматизации/тестирования). Но главное, что я сам могу оценить примерный выхлоп от того, чем делать.

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

Сколько часов нужно ориентировочно футболисту, чтобы стать таким как Месси?
Сколько часов нужно музыканту, чтобы стать таким как Фредди Меркури?

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

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

Еще один немаловажный фактор.
Позиция девопс инженера подразумевает достаточно сложную архитектуру проекта. С простой архитектурой и задачами обычно справляются своими силами, и когда выделяют целую отдельную позицию, подразумевается что ее займет опытный инженер.
Поэтому фраза "джуниор девопс" в моем понятии моветон.
Джуниор девопс это обычно человек, у которого уже есть опыт хотя бы на уровне мидл специалиста в области системного администрирования (предпочтительно) либо тестировщика-автоматизатора либо разработчика.

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

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

Выбор инструмента - это частности. Понимание какой должен быть результат - важен.
Те же самые вещи можно делать и башем и питоном и ансиблом и чефом и перлом и не так важно что было выбрано, разве что стоит вопрос расширения и поддержки. А вот что именно делать и как это все увязывать...
почитайте например git flow, и важно не сам гит - это вообще базово должно быть само собой, а зачем git flow нужен и прикинуть какой вариант подойдет в нужном проекте. Это уже как раз задача которую решают совместно девопс инженер и архитектор/тимлида.

Вы не годитесь в девопсы.
Это очень частый ответ на этот очень частый вопрос.

Девопс - это человек, который не задаёт вопросы. Он на них отвечает. Самостоятельность является для девопса одним из ключевых навыков. У вас он отсутствует.
И это совершенно точно человек, которого НЕ пугает прочтение 326 страниц мануала.
Девопсу приходится читать примерно в сто раз больше документации. В год. Подумайте хорошенько, а надо ли оно вам, если перспектива выучить даже самые примитивные основы вас пугает настолько, что вы пришли на тостер поторговаться?

В девопс, как и в инфосек, очень редко можно войти с нуля.
Надо начинать либо сисадмином (не эникейщиком), либо программистом (не вордпресс).
И потом, уже развившись как программист/сисадмин, можно подумать о движении в сторону девопса.

нет
безлимитные трафики это фантастика

скопируйте диск виндовс
загрузитесь с загруз флешки винды и восстановите загрузчик

Батники не умеют работать с датами. Тут все переменные строковые.
Да, set /a умеет целочисленную арифметику, но результат все равно строковый.
Нужно перевести даты в количество дней с начала эпохи, а потом их уже можно сравнивать стандартными средствами.
Проще всего использовать для этих целей более продвинутые средства, умеющие работать с датами, например powershel, JS, VBS - эти скрипты при желании можно вызывать из батника.
Но если очень хочется, можно и батником пересчитать. Алгоритм расчета есть на вики. Код можно дернуть отсюда - https://www.robvanderwoude.com/files/datediff_nt.txt