Не могу согласиться. Дата получения сертификата сама по себе подтверждает только то, что человек в конкретный момент времени прошёл сертификацию. Она не доказывает, что он потом 10 лет реально этим занимался.
Тут как с правами: они могут быть получены 20 лет назад, но по факту человек за рулём за это время был три раза. Формально стаж большой, а практического опыта почти нет.
В IT то же самое. Человек мог заинтересоваться темой, год поизучать код, подготовиться, накликать сертификат, а потом уйти в смежную область. Из IT не ушёл, но уже давно не программист, а, условно, сетевик, админ, менеджер или кто угодно ещё.
И переход в смежную область эту логику никак не ломает. У меня, например, есть знакомый, у которого в трудовой два года стажа оператором поддержки L2. Но по факту он после испытательного срока по внутренней ротации перешёл на тестировщика. Формально в документах одно, реальная деятельность - уже другое.
Поэтому дата получения сертификата, запись в трудовой, название должности на сайте - всё это может быть дополнительным маркером, но не полноценным подтверждением реального опыта и навыков.
Без проверки практики, реальных задач, кода, кейсов и способности объяснить свои решения это всё довольно слабые сигналы. Не бесполезные совсем, но точно не доказательство компетенции.
Хотя соглашусь, что даже с проверками и десятью этапами собеседования скорее все успеют устать, чем действительно поймут уровень и навыки кандидата. Особенно касательно рабочих задач, где нередко всё сводится к трём кнопкам, двум кликам и знанию конкретной внутренней системы.
Да, сертификат может немного повысить вероятность, что человек хотя бы сталкивался с темой. Но как доказательство практических навыков в IT он работает плохо. Особенно сейчас, когда запрет переключения окон почти ничего не решает: можно использовать телефон, второе устройство, нейронку, инструменты поверх экрана и т.д.
В условной сварке или электромонтаже сертификация понятнее: есть конкретная техника, безопасность, допуски, измеримый результат. Сделал шов правильно - хорошо. Нарушил технологию - плохо.
А вот с условным python-разработчиком сложнее. Одну и ту же задачу можно решить десятком способов. Код может формально работать, но быть нечитаемым, хрупким, неоптимальным или просто плохо спроектированным. И тест с вариантами ответов это почти не ловит. И даже современные нейронки не всегда прямо укажут, что код проблемный. Часто они скорее аккуратно подсветят “недочёты”, чем жёстко скажут, что решение плохое.
Поэтому в IT сертификат может быть дополнительным сигналом, но никак не полноценным фильтром. Нормальная оценка начинается там, где есть разбор реального кода, архитектурных решений, рассуждений кандидата и его умения объяснить, почему он сделал именно так. Желательно с участием живого эксперта или даже нескольких, а не только автоматической проверки.
Примеры без негатива. Просто в областях с большим количеством переменных формальная сертификация быстро превращается не в проверку навыков, а в проверку умения пройти сертификацию. Как с билетами ПДД: можно выучить правила и отвечать 20/20, но это ещё не значит, что на дороге человек сможет быстро и правильно применять эти знания
Не мало видео видел на подобные темы, и слышал мнение, мол, некоторые вакансии висят годами исключительно для создания видимости, что компания набирает работников. И в целом это подтверждается, если посмотреть на некоторые предложения, которые висят месяц-два, а то и больше. Ну неужели из пары тысяч откликнувшихся никто не подошёл? Да даже если не эксперт, то почему бы не взять человека чуть слабее и поднатаскать под свои нужды, если и правда нужен человек на конкретную позицию. Ну или я тогда вообще не понимаю, почему на некоторых вакансиях висит по паре тысяч откликов, а позиция всё ещё не закрыта. Так что работодателю даже выгодно это всё. По сути ведь человека найти всегда можно, а лишний раз вакансию открывать - лишняя морока. И вероятно, мы уже не увидим изменение ситуации. По крайней мере, я могу сделать лишь такие выводы
Проблема тг-каналов на мой взгляд простая - нет централизации никакой. То есть вакансия может висеть условно пару недель, а ты и не знаешь, она ещё активно, уже закрыта или вовсе поменялись требования. Ну банально не удобно листать это всё. Плюс фильтрация посредственная, так как обычно сообщения в тг ограничены размером, и описать достаточно подробно все детали и нюансы бывает не просто в одном сообщении, особенно если прикладывать картинки, так как они съедают не малое окно контекста сообщения. Ну и лишняя возня с просмотром информации о работодателе. На том же ХХ ты просто открываешь страницу компании и смотришь по ней основную информацию за пару секунд
ХХ всё же считается наиболее безопасным вариантом поиска работы. Но оно и понятно, ведь там левых вакансий обычно нет. Другое дело, что тебе могут и вовсе не ответить на пару сотен откликов, конечно...
Мне кажется, что довольно сложно будет выявить абсолютного победителя. Все же тематика сильно отличается у статей из разных категорий). Но вообще было бы интересно посмотреть на самого-самого в этом году
Жаль, конечно, что не прошёл в шорт-лист, но всё равно рад, что решил поучаствовать). Для меня это был интересный опыт и хороший повод наконец дооформить статью.
Отдельно поздравляю тех, кто прошёл дальше - удачи в конкурсе!
И если у редакторов или организаторов будет возможность ответить, мне было бы очень интересно узнать, чего именно не хватило статье с точки зрения конкурса. Чисто для понимания, куда расти дальше
Согласен, при наличии опыта это вполне рабочий путь, особенно если не пугают моменты с initramfs, grub и chroot.
Но у меня изначально был чуть другой фокус.
Я рассматривал сценарий, где миграция файловой системы сама по себе не входит в задачу - либо из-за ограничений, либо просто потому, что хочется минимальных изменений в уже работающей системе.
Плюс в реальной эксплуатации всплывают дополнительные нюансы: Тот же Docker может начать работать через другой storage driver; Активные сервисы (БД, очереди) требуют аккуратной остановки; Изменения в загрузке - это отдельная зона риска.
Поэтому я пошёл от обратного: не менять базовую ФС, а собрать поведение rollback поверх ext4.
То есть здесь скорее вопрос не “можно или нельзя перейти на btrfs”, а “нужно ли это в конкретном случае”.
При этом сам подход с переходом на btrfs - абсолютно нормальный и логичный, если он изначально вписывается в задачу.
Да, спасибо за ссылку - ccollect из той же категории, что и rsnapshot. Он использует ту же идею: rsync + hardlink для инкрементальных snapshot’ов.
У меня подход похож по механике, но отличается по сценарию использования.
Ccollect - это прежде всего backup-инструмент: хранение истории, ротация snapshot’ов, часто работа с несколькими хостами.
В моём случае акцент на rollback: быстро и предсказуемо вернуть локальную систему в предыдущее состояние.
Поэтому в моём решении:
Restore оформлен как отдельная операция (с обязательным dry-run) Есть явное разделение system и docker Можно гибко управлять тем, что именно snapshot’ить и восстанавливать
То есть идеи похожие, но модель применения разная: backup vs rollback.
В целом это уже не первый похожий инструмент, который всплывает в обсуждении - различие в основном именно в фокусе использования.
Да, в rsync-режиме timeshift использует тот же механизм: rsync + hardlink. Так что основной принцип тот же.
Пересечение тоже есть - хранение истории, запуск по расписанию. Но отличается основной сценарий:
Timeshift - это в первую очередь system snapshot “целиком”, с минимальной настройкой.
У меня же упор на rollback и контроль:
Можно выбирать, что именно снапшотить (весь /, только /home и т.д.). Есть разделение зон (system / docker). Есть исключения (пока задаются в коде, без вынесения в конфиг).
То есть механика похожая, но фокус другой: Не просто snapshot системы, а управляемый и точечный rollback.
По механике - да, идея та же: rsync + hardlink, как и в rsnapshot.
И частично пересечение есть - у меня тоже хранится история и можно запускать по расписанию. Но отличается основной сценарий использования.
rsnapshot - это прежде всего backup-инструмент: хранение данных и их историй.
Здесь же акцент на rollback - быстрый и предсказуемый возврат системы в предыдущее состояние.
Поэтому: restore - центральная операция (с dry-run перед применением), работа идёт именно с состоянием системы (system/docker), нет цели строить полноценную backup-систему с ретеншеном и архивом
То есть механика похожая, но фокус разный: backup vs rollback.
Сравнение идёт не “по порядку изменений”, а между двумя состояниями:
Текущей файловой системой (SRC)
Предыдущим snapshot (через --link-dest)
Каждый snapshot - это отдельная директория и фиксирует состояние файлов на момент её создания.
Дальше происходит следующее:
Если файл в текущей системе не изменился относительно предыдущего snapshot, rsync создаёт hardlink на файл из snapshot (оба указывают на один и тот же inode)
Если файл изменился, rsync записывает новую физическую копию уже в новый snapshot (с новым inode)
Snapshot’ы после создания не меняются. Изменения происходят только в текущей системе (SRC), а не в уже созданных snapshot’ах.
Поэтому “предыдущее состояние” - это просто файл в предыдущем snapshot, который остаётся неизменным.
Новая физическая копия создаётся в момент выполнения rsync.
rsync сравнивает текущее состояние файлов с предыдущим snapshot через --link-dest. Если файл считается неизменённым, он переиспользуется через hardlink.
Если файл отличается, rsync записывает новую физическую копию в директорию текущего снапшота.
То есть решение принимается на этапе синхронизации: нет изменений - hardlink, есть изменения - новая запись на диск.
Да, в своё время как только не "улучшали" эти нетбуки). Что-то флешку распаивал, кто-то sata полноценный делал. Но как по мне - это уже лишнее). Проще в кардридер вставить карту памяти или на крайний случай по usb подключить hdd через переходник sata-usb. Скорости не самые большие будут... Но зато и проблем меньше, и сам нетбук целым остаётся)
В большинстве случаев так и есть). Хотя на том же али порой бывают экземпляры новые, хоть и с корпусом не таким качественным, как оригинальный. Порой по цвету отличается, а где-то и формой.
Но такое более распространено на культовых устройства типа thinkpad x220/230, t420/430. Они ведь и до сих пор пользуются очень большой популярностью). А менее популярные по большей части с хранения - да.
Но всё же стоит понимать, что не у всех есть контактная сварка, а паяльником и банки убить можно случайно, если никогда не делал этого). Так что тут свои риски тоже есть
Если когда-то захотите апгрейдом заняться, то thinkpad себя покажет значительно лучше. На сколько помню, в него в теории и 4 ядра вставить можно, но там уже начинаются танцы вокруг охлаждения).
В целом, если вам хватает и стокового процессора, то заморачиваться нет смысла. Разве что если рассматривать его с точки зрения экспоната, то был бы смысл поскорее привести его в наилучшее состояние. Но это уже второстепенные вопросы)
Я сам с AntiX не сильно знаком, выбирал версию по советам в сети. Да и мне она не сказать, что нужна). Браузера хватает и на телефоне, а старички как терминалы нужны.
Да, я знаю что там 18650. Я не так давно думал о покупке нового аккумулятора для 701 и 900, но единственный вариант, который нашёл на али - 5 тысяч).
Пришёл к выводу, что купить 4 банки по 300 рублей будет дешевле... Но тут, конечно, всё зависит от моделей. На некоторые старенький модели всё ещё можно найти аккумуляторы за копейки.
Хотя согласен с Radish - новые банки будут получше в любом случае
Не могу согласиться. Дата получения сертификата сама по себе подтверждает только то, что человек в конкретный момент времени прошёл сертификацию. Она не доказывает, что он потом 10 лет реально этим занимался.
Тут как с правами: они могут быть получены 20 лет назад, но по факту человек за рулём за это время был три раза. Формально стаж большой, а практического опыта почти нет.
В IT то же самое. Человек мог заинтересоваться темой, год поизучать код, подготовиться, накликать сертификат, а потом уйти в смежную область. Из IT не ушёл, но уже давно не программист, а, условно, сетевик, админ, менеджер или кто угодно ещё.
И переход в смежную область эту логику никак не ломает. У меня, например, есть знакомый, у которого в трудовой два года стажа оператором поддержки L2. Но по факту он после испытательного срока по внутренней ротации перешёл на тестировщика. Формально в документах одно, реальная деятельность - уже другое.
Поэтому дата получения сертификата, запись в трудовой, название должности на сайте - всё это может быть дополнительным маркером, но не полноценным подтверждением реального опыта и навыков.
Без проверки практики, реальных задач, кода, кейсов и способности объяснить свои решения это всё довольно слабые сигналы. Не бесполезные совсем, но точно не доказательство компетенции.
Хотя соглашусь, что даже с проверками и десятью этапами собеседования скорее все успеют устать, чем действительно поймут уровень и навыки кандидата. Особенно касательно рабочих задач, где нередко всё сводится к трём кнопкам, двум кликам и знанию конкретной внутренней системы.
Я бы сказал, что это очень слабый фильтр.
Да, сертификат может немного повысить вероятность, что человек хотя бы сталкивался с темой. Но как доказательство практических навыков в IT он работает плохо. Особенно сейчас, когда запрет переключения окон почти ничего не решает: можно использовать телефон, второе устройство, нейронку, инструменты поверх экрана и т.д.
В условной сварке или электромонтаже сертификация понятнее: есть конкретная техника, безопасность, допуски, измеримый результат. Сделал шов правильно - хорошо. Нарушил технологию - плохо.
А вот с условным python-разработчиком сложнее. Одну и ту же задачу можно решить десятком способов. Код может формально работать, но быть нечитаемым, хрупким, неоптимальным или просто плохо спроектированным. И тест с вариантами ответов это почти не ловит. И даже современные нейронки не всегда прямо укажут, что код проблемный. Часто они скорее аккуратно подсветят “недочёты”, чем жёстко скажут, что решение плохое.
Поэтому в IT сертификат может быть дополнительным сигналом, но никак не полноценным фильтром. Нормальная оценка начинается там, где есть разбор реального кода, архитектурных решений, рассуждений кандидата и его умения объяснить, почему он сделал именно так. Желательно с участием живого эксперта или даже нескольких, а не только автоматической проверки.
Примеры без негатива. Просто в областях с большим количеством переменных формальная сертификация быстро превращается не в проверку навыков, а в проверку умения пройти сертификацию. Как с билетами ПДД: можно выучить правила и отвечать 20/20, но это ещё не значит, что на дороге человек сможет быстро и правильно применять эти знания
Не мало видео видел на подобные темы, и слышал мнение, мол, некоторые вакансии висят годами исключительно для создания видимости, что компания набирает работников.
И в целом это подтверждается, если посмотреть на некоторые предложения, которые висят месяц-два, а то и больше. Ну неужели из пары тысяч откликнувшихся никто не подошёл? Да даже если не эксперт, то почему бы не взять человека чуть слабее и поднатаскать под свои нужды, если и правда нужен человек на конкретную позицию.
Ну или я тогда вообще не понимаю, почему на некоторых вакансиях висит по паре тысяч откликов, а позиция всё ещё не закрыта.
Так что работодателю даже выгодно это всё. По сути ведь человека найти всегда можно, а лишний раз вакансию открывать - лишняя морока. И вероятно, мы уже не увидим изменение ситуации. По крайней мере, я могу сделать лишь такие выводы
Проблема тг-каналов на мой взгляд простая - нет централизации никакой. То есть вакансия может висеть условно пару недель, а ты и не знаешь, она ещё активно, уже закрыта или вовсе поменялись требования.
Ну банально не удобно листать это всё. Плюс фильтрация посредственная, так как обычно сообщения в тг ограничены размером, и описать достаточно подробно все детали и нюансы бывает не просто в одном сообщении, особенно если прикладывать картинки, так как они съедают не малое окно контекста сообщения.
Ну и лишняя возня с просмотром информации о работодателе. На том же ХХ ты просто открываешь страницу компании и смотришь по ней основную информацию за пару секунд
ХХ всё же считается наиболее безопасным вариантом поиска работы. Но оно и понятно, ведь там левых вакансий обычно нет. Другое дело, что тебе могут и вовсе не ответить на пару сотен откликов, конечно...
Мне кажется, что довольно сложно будет выявить абсолютного победителя. Все же тематика сильно отличается у статей из разных категорий).
Но вообще было бы интересно посмотреть на самого-самого в этом году
Жаль, конечно, что не прошёл в шорт-лист, но всё равно рад, что решил поучаствовать).
Для меня это был интересный опыт и хороший повод наконец дооформить статью.
Отдельно поздравляю тех, кто прошёл дальше - удачи в конкурсе!
И если у редакторов или организаторов будет возможность ответить, мне было бы очень интересно узнать, чего именно не хватило статье с точки зрения конкурса. Чисто для понимания, куда расти дальше
Согласен, при наличии опыта это вполне рабочий путь, особенно если не пугают моменты с initramfs, grub и chroot.
Но у меня изначально был чуть другой фокус.
Я рассматривал сценарий, где миграция файловой системы сама по себе не входит в задачу - либо из-за ограничений, либо просто потому, что хочется минимальных изменений в уже работающей системе.
Плюс в реальной эксплуатации всплывают дополнительные нюансы:
Тот же Docker может начать работать через другой storage driver;
Активные сервисы (БД, очереди) требуют аккуратной остановки;
Изменения в загрузке - это отдельная зона риска.
Поэтому я пошёл от обратного: не менять базовую ФС, а собрать поведение rollback поверх ext4.
То есть здесь скорее вопрос не “можно или нельзя перейти на btrfs”, а “нужно ли это в конкретном случае”.
При этом сам подход с переходом на btrfs - абсолютно нормальный и логичный, если он изначально вписывается в задачу.
Да, спасибо за ссылку - ccollect из той же категории, что и rsnapshot. Он использует ту же идею: rsync + hardlink для инкрементальных snapshot’ов.
У меня подход похож по механике, но отличается по сценарию использования.
Ccollect - это прежде всего backup-инструмент: хранение истории, ротация snapshot’ов, часто работа с несколькими хостами.
В моём случае акцент на rollback: быстро и предсказуемо вернуть локальную систему в предыдущее состояние.
Поэтому в моём решении:
Restore оформлен как отдельная операция (с обязательным dry-run)
Есть явное разделение system и docker
Можно гибко управлять тем, что именно snapshot’ить и восстанавливать
То есть идеи похожие, но модель применения разная: backup vs rollback.
В целом это уже не первый похожий инструмент, который всплывает в обсуждении - различие в основном именно в фокусе использования.
Да, в rsync-режиме timeshift использует тот же механизм: rsync + hardlink. Так что основной принцип тот же.
Пересечение тоже есть - хранение истории, запуск по расписанию.
Но отличается основной сценарий:
Timeshift - это в первую очередь system snapshot “целиком”, с минимальной настройкой.
У меня же упор на rollback и контроль:
Можно выбирать, что именно снапшотить (весь /, только /home и т.д.).
Есть разделение зон (system / docker).
Есть исключения (пока задаются в коде, без вынесения в конфиг).
То есть механика похожая, но фокус другой:
Не просто snapshot системы, а управляемый и точечный rollback.
По механике - да, идея та же: rsync + hardlink, как и в rsnapshot.
И частично пересечение есть - у меня тоже хранится история и можно запускать по расписанию. Но отличается основной сценарий использования.
rsnapshot - это прежде всего backup-инструмент: хранение данных и их историй.
Здесь же акцент на rollback - быстрый и предсказуемый возврат системы в предыдущее состояние.
Поэтому: restore - центральная операция (с dry-run перед применением), работа идёт именно с состоянием системы (system/docker), нет цели строить полноценную backup-систему с ретеншеном и архивом
То есть механика похожая, но фокус разный: backup vs rollback.
Да, если говорить про самый первый snapshot - то да, он создаётся как обычная копия, потому что ещё нет предыдущего состояния для сравнения.
А уже начиная со второго snapshot rsync работает через --link-dest.
То есть дальше snapshot’ы уже не копируются целиком, а собираются на основе предыдущего.
Сравнение идёт не “по порядку изменений”, а между двумя состояниями:
Текущей файловой системой (SRC)
Предыдущим snapshot (через --link-dest)
Каждый snapshot - это отдельная директория и фиксирует состояние файлов на момент её создания.
Дальше происходит следующее:
Если файл в текущей системе не изменился относительно предыдущего snapshot, rsync создаёт hardlink на файл из snapshot (оба указывают на один и тот же inode)
Если файл изменился, rsync записывает новую физическую копию уже в новый snapshot (с новым inode)
Snapshot’ы после создания не меняются. Изменения происходят только в текущей системе (SRC), а не в уже созданных snapshot’ах.
Поэтому “предыдущее состояние” - это просто файл в предыдущем snapshot, который остаётся неизменным.
Новая физическая копия создаётся в момент выполнения rsync.
rsync сравнивает текущее состояние файлов с предыдущим snapshot через --link-dest. Если файл считается неизменённым, он переиспользуется через hardlink.
Если файл отличается, rsync записывает новую физическую копию в директорию текущего снапшота.
То есть решение принимается на этапе синхронизации: нет изменений - hardlink, есть изменения - новая запись на диск.
Да, согласен - btrfs и zfs решают эту задачу гораздо лучше на уровне файловой системы.
Но идея была в другом: сделать rollback в условиях, где файловую систему менять нельзя или не хочется (например, уже развернутая система на ext4).
В таких сценариях rsync + hardlink - это попытка приблизиться к поведению снапшотов без изменения инфраструктуры.
Подобных простых и оформленных решений под ext4 найти не удалось, поэтому в итоге и появился этот инструмент.
В статье как раз пытался показать, что это не замена таким решениям, а вариант для более ограниченных условий.
Да, в своё время как только не "улучшали" эти нетбуки). Что-то флешку распаивал, кто-то sata полноценный делал. Но как по мне - это уже лишнее). Проще в кардридер вставить карту памяти или на крайний случай по usb подключить hdd через переходник sata-usb. Скорости не самые большие будут... Но зато и проблем меньше, и сам нетбук целым остаётся)
В большинстве случаев так и есть). Хотя на том же али порой бывают экземпляры новые, хоть и с корпусом не таким качественным, как оригинальный. Порой по цвету отличается, а где-то и формой.
Но такое более распространено на культовых устройства типа thinkpad x220/230, t420/430. Они ведь и до сих пор пользуются очень большой популярностью). А менее популярные по большей части с хранения - да.
Но всё же стоит понимать, что не у всех есть контактная сварка, а паяльником и банки убить можно случайно, если никогда не делал этого). Так что тут свои риски тоже есть
Если когда-то захотите апгрейдом заняться, то thinkpad себя покажет значительно лучше. На сколько помню, в него в теории и 4 ядра вставить можно, но там уже начинаются танцы вокруг охлаждения).
В целом, если вам хватает и стокового процессора, то заморачиваться нет смысла. Разве что если рассматривать его с точки зрения экспоната, то был бы смысл поскорее привести его в наилучшее состояние. Но это уже второстепенные вопросы)
Главное, чтобы он работал и радовал!
Спасибо за материал! Изучу, как время будет)
Я сам с AntiX не сильно знаком, выбирал версию по советам в сети. Да и мне она не сказать, что нужна). Браузера хватает и на телефоне, а старички как терминалы нужны.
Но всё же ради эксперимента поставить можно)
Да, я знаю что там 18650. Я не так давно думал о покупке нового аккумулятора для 701 и 900, но единственный вариант, который нашёл на али - 5 тысяч).
Пришёл к выводу, что купить 4 банки по 300 рублей будет дешевле... Но тут, конечно, всё зависит от моделей. На некоторые старенький модели всё ещё можно найти аккумуляторы за копейки.
Хотя согласен с Radish - новые банки будут получше в любом случае