xotkot

Главные критерии для программиста (реалии таковы)
1. оперативная память, чем больше тем лучше, работать можно и с 8 (visual studio при меньших объемах тормозит), но есть направления, где разработчику требуется разворачивать свои сервисы в виртуальных машинах а там оперативная память ой как критична.
Плюс, к примеру если работаешь с данными, большой объем оперативной памяти экономит время на разработке (к примеру вместо использования sql можно разместить все данные в оперативной памяти и пользоваться своими алгоритмами)
2. клавиатура - ноутбучные раскладки - это ад, неправильное размещение управляющих клавиш (стрелки, page up/down/home/end, ins/del да банально enter не на том месте или требование нажимать fn чтобы рядовые комбинации использовать, сильно портят нервы, да если поднапрячся можно перенастроить все горячие клавиши на свои комбинации, привязывая себя к своей раскладке, но через годы позе будешь мучиться наоборот на нормальной клавиатуре
3. монитор - размер монитора современного разработчика 23"..27", все что меньше - мучение, все IDE и не только рассчитаны на большой экран и FullHD разрешение, 2к и 4к можно отскалить до нужного масштабированием и будет даже приятнее (шрифты лучше выглядят на 4к) а уж дизайнерам и подавно нужно работать с таким разрешением чобы соответствовать мейнстриму
Ноутбучные 17" это либо очень все мелкое (FullHD) и напрягает глаза либо если по глупости HD720 (или 1360x768 есть такой популярный нестандарт) и это терпят только ради мобильности, значение чего слишком переоцененно и имеет смысл если дома работать не получается а рабочего места нет.
4. скорость процессора в 1 потоке (single thread в бенчмарках)
разработчика совершенно не должно волновать сколько потоков умеет его процессор (больше 4 и ладно), но вот объем процессорного кеша и производительность на поток - очень важны, так как в конечном счете время, которое разработчик тратит на компиляцию и подготовку окружения очень важно, для нервов, даже 30% разницы (а это та разница между одного ценового диапазона ноутубков и десктопа) очень заметны, разработчик тратит огромное время на эксперименты со своим кодом, поправил, запустил, снова подправил, и если время между этими действиями больше некоторого периода (секунды даже меньше, у разных людей по разному) это сбивает настрой, что то связанное с короткой памятью,... в общем это надо прочувствовать и поработать на быстрых и медленных машинах чтобы понимать
5. скорость и размер ssd, это в догонку к пункту 4, в современной разработке скорость подготовки окружения (развертывания докер контейнера например) очень важна и поверь, сидеть на hdd ты не пожелаешь, особенно если у тебя win10 или не дай бог win11. А если у тебя виртуальные машины крутятся, размещать их на hdd еще хуже (когда у меня не хватало ssd я размещал базовую виртуалку на hdd а снапшоты, с которых работает приложение, размещаются на ssd, это дает неплохой бонус к производительности при этом на ssd размещается от силы 5-10% данных..

подумай 10 раз, так ли тебе нужен ноутбук, так как за те же деньги можно собрать заметно более крутой стационарный компьютер

Однозначно, подтверждается синтетическими тестами, главное! при наличии драйверов как для win7 так и win10, последняя до 10% медленнее работа с диском.

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

И главное, интерфейс windows10 менее отзывчивый, это видно везде, и в стартовом меню и в проводнике (правда winxp/win7 можно было сильно замедлить просто устанавливая больше приложений, регистрирующих activex компоненты и com классы, полагаю именно это и произошло с win10, объектов идущих в комплекте с ОС стало больше), я сейчас не говорю про сломанную юзабилити, в win10 в конце концов больше телодвижений для многих настроек (чтобы добраться до старых не метро настроек, попробуйте открыть старое меню настройки времени, чтобы к примеру отключить или сменить сервер времени, с которого идет синхронизация часов)

Я помню для меня было шоком, что в win10 запуск приложений по горячим клавишам (свойства ярлыка, настройка комбинаций клавиш) да просто запуск системных приложений по нажатию мультимедиа клавиш занимает время (где то пол секунды), запустите калькулятор, поймете о чем я. Изучая вопрос я понял что во первых это метро приложения, их запуск в принципе не мгновенный, но еще страшнее, если 'сломать' интернет (например указать неверный dns или прописать неправильный route) то запуск приложений еще сильнее замедляется, но не регулярно, как будто почти каждый запуск приложения заставляет ОС отправлять сетевой пакет в интернет и ждать ответ (антивирус при этом само собой отключен). Я специально искал не metro приложение калькулятор, и даже оно могло через раз запускаться не мгновенно

так что ответ - да, win10 заметно медленнее win7 почти по всем аспектам, но при условии что драйвера на железо имеются под обе версии ОС, что с каждым днем все сложнее и сложнее.

Само собой, если активно заниматься тюнингом системы, с некоторыми шансами можно довести скорость работы win10 до win7, к сожалению когда с интервалом в год несколько раз, приезжающие комулятивные обновления почти полностью сбрасывали все критичные для скорости настройки до дефолтных, мне надоело бороться с ветряными мельницами, а позже полностью ушел на linux, оставив полупустую установку win для виртуалки.

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

советую включать 2x скорость проигрывания (или подбирай скорость по ситуации) - помогает

p.s.

w |tail -n +3|awk '{print $1}'|grep 'r$\|x$\|z$'|wc -l

(вот только чему вы научитесь, копипастя преподу готовенькие ответы?)

Обрати внимание на сроки поддержки...

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 страниц мануала.
Девопсу приходится читать примерно в сто раз больше документации. В год. Подумайте хорошенько, а надо ли оно вам, если перспектива выучить даже самые примитивные основы вас пугает настолько, что вы пришли на тостер поторговаться?

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

Если брать в расчёт одинаковых противников с высокой реакций, то противник с большим fps будет доминировать (он лучше будет прогнозировать движение противника). Особенно сильна разница между 20-60 fps.

Пример, как это выглядит https://youtu.be/pUvx81C4bgs

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

Внимательно посмотрите на свой swap.

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

Самое быстрое - консольные утилиты, из мира linux, awk, cut, grep,... сможешь разобрать свой файл хоть на калькуляторе (можно поставить отдельно или взять готовое с помощью майкрософтовского wsl или cygwin).

Любое другое решение будет сильно медленнее и будет требовать больше ресурсов.

пример, если тебе нужны строки (csv - текстовый формат, по строке на запись), в которых есть нужная тебе подстрока, то используй grep:

grep "искомая строка в кодировке файла" имя_файла.csv > новый_файл.csv

почти наверняка тебе хватит подстроки или регулярного выражения (ключ -e)
p.s. если там очень сложное условие, и недостаточно филтации в пределах строки, то импортируй csv в базу данных, например sqlite (импорт из csv встроен), правда 7гб может не шибко быстро импортировать, потом индексы создавать (я советую такие операции делать на ram диске) зато потом почти любые фильтрации

У Вас неверное понимание принципа построения программ в Linux.
В Windows любая программа, когда начинает расти - непременно тащит все фичи в себя, потому что интеграция между программами невозможна в принципе (за исключением программ одного производителя).
В Linux любая программа может интегироваться с любой другой программой (за исключением некоторых платных), поэтому "почтовый сервер" в Linux - это обычно комбинация различных программ: SMTP-сервер, IMAP-сервер, а средства интеграции с AD и всем, чем угодно входят непосредственно в систему - PAM, OpenLDAP, SSS etc.

Можно действительно поднять Zimbra Community Edition - там внутри все то же самое, просто поверх этого натянута морда.

Судя по сообщению, он не может прогрузить репозитории из зеркала mirror.inode.at
Просто смените зеркало и попробуйте снова обновить

pipe - это механизм коммуникации между процессами. pipe, как уже было сказано выше, является однонаправленным потоком данных, все данные, записанные процессом в пайп перенаправляются ядром другому процессу для чтения.
pipe это объект VFS (Virtual File System), поэтому pipe не имеет соответсвутющего образа на диске, грубо говоря он хранится в памяти (pipefs).
Главным недостатком pipe является тот факт, что невозможно открыть уже существующий pipe. Поэтому два произвольных процесса не могут использовать одновременно один и тот же pipe, за исключением случаев если pipe был создан общим родительским процессом.

fifo (named pipe) - это специальный файл, очень похожий на pipe, за исключением того, что fifo inode содержится в файловой системе, плюс fifo это двунаправленный механизм обмена данными между двумя и более процессами, поэтому доступ к fifo на чтение и запись может получить любой процесс. Грубо говоря процесс общения с использованием fifo выглядит следующим образом - "сервер" создает fifo файл, который успользуется "клиентами" для выполнения запросов. Каждый "клиент", прежде чем установить соединение с "сервером", создает другой fifo файл, в который "сервер" может записать ответ клиенту, при это указывая имя fifo в изначальном запросе.

socket (unix socket) - это специальный файл, используемый для коммуникации между двумя и более различными процессами, выполняющимися на одной машине. Процессы обращаются к socket по его inode.

Итак в чем же отличие fifo (named pipe) от unix socket:
1. "Сервер" (или принимающий процесс) в fifo не умеет различать "Клиентов".
"Клиенты", использующие unix socket имеют отдельные соединения с сервером. В fifo различные "клиенты" могут писать в pipe, но "Сервер" не может различить "Клиентов" друг от друга.
2. При создании fifo и unix socket используются различные системные вызовы.
Unix socket создается системным вызовом "socket()". fifo создается "mkfifo()"
3. Для подключения к fifo и unix используюся различные системные вызовы.

Сравнение по производительности - fifo vs unix socket:
1. unix socket обеспечивает лучшую производительнось при передаче большого объема данных
2. для малых объемов unix socket уступает в производительности fifo. это вызвано накладными раскодами, связанными с созданием сокета, инициализацией и подключением к нему.

Поставьте на форточку bash

Можно начать с man utmp.

Я бы задачу разбил на два этапа - сначала собираете find`ом все пути к файлам, потом натравливаете на получившийся список архиватор. И зачем -regex, который наверняка даёт оверхед, если можно просто искать по маске?