Каковы ваши отношения с программированием?

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

Собственно ради этого у меня линукс.

Это ещё почему? Тебе при приёме на работу говорят «первые пару месяцев ЗП меньше»?

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

Обычно, никто в шею не гонит.

В смысле, работа требует больше усилий, так как не отточена до автоматизма. И параллельно надо тратить время и силы на учёбу.

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

Намного сложнее. Впрочем, YMMV.

Собственно ради этого у меня линукс.

У меня тоже. Но именно поэтому я перестал пытаться нести линукс в массы. Может благодаря санкциям Альту придётся сделать цельную ОС ил линукса, иначе так и будет профессиональный набор инструментов.

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

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

В смысле, работа требует больше усилий, так как не отточена до автоматизма. И параллельно надо тратить время и силы на учёбу.

Да, немного больше. Но это не сильная проблема. Какой-то месяц можно и потерпеть. Один фиг, больше 8 часов работать никто не требует.

Как противоречит? Она не меньше МРОТа же всё равно. То есть приняли на маленькую зп, потом повышают - так нельзя?

От единого стандарта установочного пакета (типа MSI и DMG)

Так он есть. В дебиане .deb например. Популярное возражение: а вот в шапке .rpm, значит не единый. Ответ: rhel - это другая ОС. И вообще, это как раз тот случай, когда «линукс - не ОС а ядро» - не просто флуд, а существенный факт. Операционной системы «линукс» не существует, есть пачка разных операционных систем с похожими ядрами и прогами. Выбери себе одну и смотри только на неё. А так то, вот у винды и мака тоже формат установочных пакетов друг от друга отличается, значит не единый.

Нельзя указывать ограничение по ЗП на время испытательного периода.

Миф № 2. На испытательном сроке заработная плата меньше.

Правда. На период испытательного срока работодатель не вправе снижать уровень оплаты труда новому работнику.

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

deb-пакет для конкретного дистрибутива не имеет никаких гарантий работы на другом, потому что список зависимостей не портируем.

Т.е. формально deb переносим, но реально это манямирок. Обычный appimage уделывает всякие deb как некий Тузик - медицинский инвентарь.

Ты специально дальше второго предложения не прочитал? Прочти, там отвечено сразу на это.

Я выступил не с возражением, а с дополнением. Просто пример приведён фиговый какой-то.

Ну ладно. Итог такой: у разных ОС на базе линукса повышенная (по сравнению с просто рандомными ОС) взаимная совместимость, отчего многие начинают думать что совместимость должна быть вообще 100% и расстраиваются от того, что это не так. А на самом деле должны радоваться что она вообще есть. А 100% совместимые друг с другом ОС это на самом деле одна и та же ОС с разными названиями. Вот например болгенос наверно был 100% совместим с убунтой их которой его сделали. Но толку от такого «разнообразия» нет. Разные ОС они потому и разные, что в них что-то отличается и следовательно не всё совместимо (а ты, выбирая дистр, выбираешь какой из предложенных путей тебе более приятен). Это не баг, это фича.

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

Не так. Приходишь, говоришь «я 10 лет писал сайты магазинов на Jakarta». Тебя спрашивают про volatile (который за 10 лет ни разу не встречался), работу с Jira и Quarkus. Ты естественно про них не знаешь. Получаешь место начинающего программиста, а нормальную зарплату может быть через год после переаттестации.

Один фиг, больше 8 часов работать никто не требует.

В эти 8 часов тебя будут грузить как начинающего (будешь писать документацию, бегать курьером и переписывать код под требование линтера). А если хочешь самообразовываться, то в свободное от работы время.

Так он есть. В дебиане .deb например.

Этот .deb почти всегда требует очень конкретную версию дистрибутива. В результате выкладывают программу для Windows (любого), MacOS (почти любого) и Ubuntu 20.04. А на Ubuntu 19 или Ubuntu 21 нужен уже другой пакет.

Инсталлятор 1С 8 для Win98 можно поставить на Win10. А пакет от Debian 4 на современный Debian почти невозможно.

Итог такой: у разных ОС на базе линукса повышенная (по сравнению с просто рандомными ОС) взаимная совместимость, отчего многие начинают думать что совместимость должна быть вообще 100% и расстраиваются от того, что это не так.

Я про другое. Я про то, что практически все ОС на базе линукса не совсем ОС в нормальном смысле (почему и предпочитают называться дистрибутивами, то есть наборами ПО).

Вспомнил, кстати, один пример, когда компания вложила деньги и на базе Линукса сделала ОС: Google Android.

Если в жёстких зависимостях один glibc, причём умеренно старой версии – то переносим вполне.

Ах, если бы. Большую часть разработчиков не парит портянка при выхлопе ldd, к можалению.

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

Крупные пакеты нередко так и делают: универсальный DEB и универсальный RPM. А про манямирок пусть вещают неосиляторы.

Если в жёстких зависимостях один glibc, причём умеренно старой версии – то переносим вполне.

Но как? Предположим, у меня программа на GTK 3.1 и использует libicu для юникода. Как в рамках ОС, основанной на Линукс, сделать deb-пакет?

Даже если пойти по стопам Столярова и использовать исключительно glibc, а всё остальное только через сокеты. Так даже glibc ломает совместимость, причём без изменения имени библиотеки. Старый libc.so.6 позволял писать extern errno, а новый ломается.

Но как? Предположим, у меня программа на GTK 3.1 и использует libicu для юникода. Как в рамках ОС, основанной на Линукс, сделать deb-пакет?

На уровне мейнтейнера дистрибутива: разрешить установку GTK 3.1 параллельно, собрать пакеты с ним, прописать зависимость именно от него.

На уровне проприетарщика, которых хочет, чтобы просто везде работало: тащить GTK 3.1 с собой, ставить всю прогу вместе с либами в /opt (шиндовс-стайл).

На уровне мейнтейнера дистрибутива: разрешить установку GTK 3.1 параллельно, собрать пакеты с ним, прописать зависимость именно от него.

И так для каждого дистрибутива. Вот поэтому в Windows можно использовать старые программы на Delphi1, а в Linux если репозиторий хотя бы полгода не обновляется, то программа мертва и в современном дистрибутиве уже не запустить.

На уровне проприетарщика, которых хочет, чтобы просто везде работало: тащить GTK 3.1 с собой, ставить всю прогу вместе с либами в /opt (шиндовс-стайл).

В том-то и беда, что этот стайл в случае линукса совсем убогий. Потому что в Windows можно сделать общий vcredist и он будет для всех, а в Linux только каждому полную копию GTK в подкаталоге /opt.

P. S. При том, что диды ещё во времена UNIX придумали и версионирование библиотек и семантическую модель нумерации версий. Но нет. Номера версий не гарантируют совместимость. Даже идентичное имя библиотеки не гарантирует совместимость. А поставить на один компьютер три-четыре версии Qt и GTK в мире линукса жуткий харам (есть пара дистрибутивов, которые позволяют так сделать, но для них делать пакеты ещё сложнее).

В том-то и беда, что этот стайл в случае линукса совсем убогий. Потому что в Windows можно сделать общий vcredist и он будет для всех, а в Linux только каждому полную копию GTK в подкаталоге /opt.

Так в линуксе тоже можно сделать общий, и это так и работает.

При том, что диды ещё во времена UNIX придумали и версионирование библиотек и семантическую модель нумерации версий. Но нет. Номера версий не гарантируют совместимость. Даже идентичное имя библиотеки не гарантирует совместимость.

Это проблема, согласен.

Даже идентичное имя библиотеки не гарантирует совместимость. А поставить на один компьютер три-четыре версии Qt и GTK в мире линукса жуткий харам

Но можно. Просто не хочется. И это хорошо.

(есть пара дистрибутивов, которые позволяют так сделать, но для них делать пакеты ещё сложнее).

Если в каких-то дистрибутивах так нельзя, то это проблемы этих дистрибутивов, а не пакетной системы как таковой. И уж точно не формата пакетов. При всём моём неоднозначном отношении к deb и особенно rpm, в них точно так же, как и в арче с этим проблем нет. Они есть в конкретных дистрибутивах.

Так в линуксе тоже можно сделать общий, и это так и работает.

В какой из ОС на базе линукса можно? И каким образом? Например, нужен мне GTK-3.1-redist, что я в нём должен написать?

Но можно. Просто не хочется. И это хорошо.

Хочется. Но вместо этого ставишь виртуальную машину или хотя бы chroot для отдельного приложения, потому что это проще, чем забороть пакетный менеджер. Или как частичное решение docker (не знаю, можно ли в него упаковать GTK).

Аналогичная проблема под Windows с Haskell. При сборке тривиального графического приложения он вытягивает половину линукса и из этих 6 гигабайт непонятно, что можно выкинуть, чтобы приложение не перестало запускаться (если просто взять то, что показывает ldd, гарантированно ломается).

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

Так я и не пишу, что пакетная система плоха. Я пишу, что никто не хочет тратить свои ресурсы, чтобы сделать ОС на основании Линукса. Вместо ОС у нас наборы Лего. Причём в каждой версии кубики чуть-чуть разного размера, чтобы нельзя было кубик из одной коробки добавить к другому набору.

В какой из ОС на базе линукса можно?

В любой. У меня вот и Qt5 и Qt6 сейчас стоит.

Я не знаю, есть ли где-то конкретно GTK-3.1, речь ведь не о том, что есть, а о том, что можно.

Я пишу, что никто не хочет тратить свои ресурсы, чтобы сделать ОС на основании Линукса.

Весь «зоопарк дистрибутивов» самозародился? Никто не хотел и не тратил, оно само?

Вместо ОС у нас наборы Лего.

И это хорошо.

В любой. У меня вот и Qt5 и Qt6 сейчас стоит.

Я так понимаю, предоставляемые дистрибутивом.

Это две. А Qt4 и Qt3 в этот же дистрибутив сможете?

Я не знаю, есть ли где-то конкретно GTK-3.1, речь ведь не о том, что есть, а о том, что можно.

Я не про существование его в одном из дистрибутивов. Я про возможность сделать некий gtk-3.1.deb, который можно было бы поставить на любую версию Debian. И прописать своему пакету зависимость от этого deb, чтобы эта пара пакетов могла быть установлена на любую версию Debian. Возможно? Если да, то как такой gtk-3.1.deb должен выглядеть (в смысле, что содержать)?

Весь «зоопарк дистрибутивов» самозародился? Никто не хотел и не тратил, оно само?

Сделать дистрибутив на два порядка дешевле, чем сделать ОС. Поэтому дистрибутивов сотни, а ОС ни одной только Android.

Я так понимаю, предоставляемые дистрибутивом.

Да.

Это две. А Qt4 и Qt3 в этот же дистрибутив сможете?

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

Я про возможность сделать некий gtk-3.1.deb, который можно было бы поставить на любую версию Debian. И прописать своему пакету зависимость от этого deb, чтобы эта пара пакетов могла быть установлена на любую версию Debian. Возможно?

Я не знаю, какие зависимости у самого gtk-3.1. Если его можно собрать так, чтобы он работал на той версии glibc и всего прочего, которые есть «в любой версии Debian», то да, возможно. Если нет, то цепочку придётся продолжать дальше.

Сделать дистрибутив на два порядка дешевле, чем сделать ОС.

Дистрибутив — это и есть ОС.

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

Поэтому дистрибутивов сотни, а ОС ни одной только Android.

В общем, я примерно понял, чего ты хочешь. К счастью, с GNU/Linux такого не происходит. Хотя RedHat очень старается.

Если его можно собрать так, чтобы он работал на той версии glibc и всего прочего, которые есть «в любой версии Debian», то да, возможно.

Проблема с именами библиотек. Все Gtk-3.* создают библиотеку libgtk-3.so.0. Соответственно, поставить одновременно Gtk-3.1 и Gtk-3.2 как системные нельзя. При этом внутри ветки Gtk-3 ломающие изменения: https://github.com/linuxmint/cinnamon/issues/5731

Ну тогда только класть в другой подкаталог, например /usr/lib/gtk-3.1/, а в софте жёстко зависящем именно от 3.1 юзать полный путь (ну или враппер к нему просто сделать, прописав в LD_LIBRARY_PATH).

Проблема с тем, что имя сошки не меняют при изменениях, ломающих совместимость, есть. За это надо бить по рукам.

Дистрибутив — это и есть ОС.

ОС имеет стабильный интерфейс для внешних программ. Единообразный графический интерфейс, единообразные настройки для всех системных компонентов. FreeBSD ближе к ОС.

К счастью, с GNU/Linux такого не происходит. Хотя RedHat очень старается.

И поэтому каждый дистрибутив GNU/Linux является вещью в себе. Можно ставить только компоненты дистрибутива, а всё остальное через docker/виртуальную машину. Даже в случае RHEL приходится каждую версию рассматривать как отдельную операционную систему, потому что совместимости нет даже между соседними версиями.

Ну тогда только класть в другой подкаталог, например /usr/lib/gtk-3.1/, а в софте жёстко зависящем именно от 3.1 юзать полный путь

Да. Но в дистрибутиве такой путь не поддерживается. Как в Windows инсталляторы были до появления MSI.

За это надо бить по рукам.

Поздно. У разработчиков дистрибутива нет власти над разработчиками компонентов, а разработчикам компонентов и так хорошо. Если бы была ОС общего назначения на базе линукс, то разработчики такой ОС контролировали бы все системные компоненты и могли бы навести порядок. Но это дорого, поэтому у нас только дистрибутивы и Android (заметь, там этой проблемы нет: один APK ставится на десяток версий Андроида).

Да. Но в дистрибутиве такой путь не поддерживается. Как в Windows инсталляторы были до появления MSI.

Что значит не поддерживается? Положить туда либы можно. Каталога этого не будет в LD_LIBRARY_PATH, это да. Но в том и суть же, чтоб они друг другу не мешаели.

Поздно.

Лишь отчасти. Но можно хотя бы для нового софта не пользоваться такими либами.

Если бы была ОС общего назначения на базе линукс, то разработчики такой ОС контролировали бы все системные компоненты и могли бы навести порядок.

К счастью, такое не грозит.

один APK ставится на десяток версий Андроида

Ты их объём видел, APK этих? Там как в винде — всё с собой, а не лучшее управление зависимости, как я понимаю. Могу, впрочем, тут частично ошибаться, с андроидом знаком крайне поверхностно, не пользуюсь им.

Не так. Приходишь, говоришь «я 10 лет писал сайты магазинов на Jakarta». Тебя спрашивают про volatile (который за 10 лет ни разу не встречался), работу с Jira и Quarkus. Ты естественно про них не знаешь. Получаешь место начинающего программиста, а нормальную зарплату может быть через год после переаттестации.

В моём представлении о мире все работает немного не так. Люди не знающие volatile на проект с требованием знания volatile не попадают. Это как две лиги. При переходе из non-volatile лиги в volatile лигу человек сначала сам дома читает параграф 17 JLS (ну или просто смотрит Шипилёва, читает пару статей) и потом его успешно берут на работу в volatile-лигу.

В эти 8 часов тебя будут грузить как начинающего (будешь писать документацию, бегать курьером и переписывать код под требование линтера). А если хочешь самообразовываться, то в свободное от работы время.

Я никогда не видел прям такой кастовости. Не говорю, что её не бывает, но это далеко не правило. Зачем в такие команды тогда идти?

Да, есть такое, я как-то не подумал с такой стороны.

Причём, самое интересное, что Debian как приложение действительно одна программа. Я могу поставить Debian 1.0 и последовательными обновлениями обновить до актуальной. Даже настройки практически все перенесутся. Обновить с Windows 3.1 на Windows 11 почти невозможно.

Но вот как ОС, то есть инфраструктура для запуска программ, написанных третьими лицами, не то что Debian 12 и Debian 13 разные ОС. Зачастую, даже Debian 13 и Debian 13 backports уже разные ОС.

Что значит не поддерживается?

Нет единого правила, определяемого ОС. Как в Windows было правило, что библиотека будет в windows/system32.

Лишь отчасти. Но можно хотя бы для нового софта не пользоваться такими либами.

Всем бойкотировать GNU libc?

К счастью, такое не грозит.

RedHat пыталась, но надорвалась. Фактически, им достаточно стать единственным источником финансов для ядра, libc, компилятора и GNOME или форка всего вышеперечисленного, тогда они смогут зафиксировать интерфейс для «программ для RedHat».

Ты их объём видел, APK этих? Там как в винде — всё с собой, а не лучшее управление зависимости, как я понимаю.

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

И даже если так: ОС - это не про управление зависимости, а про наличие опубликованного интерфейса для написания программ для этой ОС. Случайный APK для Android 9 заработает на любом телефоне с Android 9. И легко можно сделать APK, например для Android с 4 по 11. Написать deb для Debian с 4 по 11 практически невозможно, и даже deb для Debian 11 пойдёт не на всех Debian 11 (могли обновить какую-то библиотеку из зависимостей и уже не сходится).

Нет единого правила, определяемого ОС. Как в Windows было правило, что библиотека будет в windows/system32.

Есть FHS. Но здесь как раз смысл в том, чтобы это единое правило обойти. Именно потому что библиотека с данным именем уже есть. Не тупи.

Всем бойкотировать GNU libc?

Ну я MUSL юзаю :)

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

Может и так. Статистику я не знаю, личный опыт у каждого свой.

Мой опыт показывает, что человеку, чтобы выучить огромный объём знаний в свободное от работы время, нужна очень веская мотивация. То есть, есть разработчик, который пилит магазины на джакарте и хорошо получает (потому что в этой узкой области он фактически сеньор). Что должно произойти, чтобы он в свободное время (в рабочее он магазины пилит) начал изучать части JLS, которые ему до сих пор были не нужны, библиотеки, которые были не нужны, причём понимая, что на сеньора его сразу в другой области не возьмут?

Я никогда не видел прям такой кастовости.

Это не кастовость. Это просто требование на работе работать. Если я устроился программистом, но на работе вместо работы буду штудировать учебники, то работодатель вряд ли будет доволен.

Именно потому что библиотека с данным именем уже есть.

При этом делает другое. В этом и проблема. Но «тут так принято».

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

Так почти всех всё устраивает.

При этом делает другое. В этом и проблема. Но «тут так принято».

Мы в этом вопросе давно пришли к консенсусу. Я согласен, что проблема такая есть, зачем мне продолжать про неё рассказывать?

Далее ты спросил, как сделать такой пакет и зависящие от него. Я ответил как — положить эту либу именно что по пути, которого нет в LD_LIBRARY_PATH, который не является стандартным для дистрибутива, дабы она не конфликтовала с другой с тем же именем, а в пакетах, зависящих от этого — использовать либу по полному пути, или прописать в скрипт запуска export LD_LIBRARY_PATH="/usr/lib/gtk-3.1:$LD_LIBRARY_PATH. Могло бы быть лучше, и без этого? Могло, но есть то, что есть. Ты спросил, как это сделать в тех условиях, что есть, я ответил.

Мне кажется, тут дело не столько в мотивации и затраченном времени, а в способностях человека. Я убежден, что 90% людей не могут в принципе осилить свою профессию [1] до уровня «хороший специалист», вот просто нету у них природных задатков для этого. Это ещё в школе хорошо видно: весь класс слушает один и тот же урок, но реально осваивают его лишь единицы.

Это не кастовость. Это просто требование на работе работать. Если я устроился программистом, но на работе вместо работы буду штудировать учебники, то работодатель вряд ли будет доволен.

Ни разу не слышал о работе, где нельзя почитать что-то пару часов в неделю.

[1] Более-менее сложную профессию. Также процент отличается от сложности профессии, так профессию математик не осилит уже 99.9%.

Я убежден, что 90% людей не могут в принципе осилить свою профессию [1] до уровня «хороший специалист».

Если определить «свою профессию» именно как то, что с человека спрашивают, то примерно за 10 лет любой человек становится хорошим специалистом. Если как то, что написано в дипломе на профессию с таким наименованием, то, разумеется: зачем изучать то, за что не платят?

Ни разу не слышал о работе, где нельзя почитать что-то пару часов в неделю.

Любая работа, где есть ежедневный отчёт и постоянное наличие задач. Если за пределами программирования, так вообще любая рабочая специальность.

Согласен. Мои претензии не по адресу. И они даже не претензии (меня тоже на самом деле всё устраивает), а скорее объяснение слов (чем операционная система отличается от дистрибутива).

Если определить «свою профессию» именно как то, что с человека спрашивают, то примерно за 10 лет любой человек становится хорошим специалистом. Если как то, что написано в дипломе на профессию с таким наименованием, то, разумеется: зачем изучать то, за что не платят?

Ну мне сложно назвать профессионалом человека, который 10 лет программирует и не знает/понимает элементарных вещей. Наверное, у каждого свое понимание профессионализма. :)

Любая работа, где есть ежедневный отчёт и постоянное наличие задач. Если за пределами программирования, так вообще любая рабочая специальность.

Нигде не заставляют отчитываться за каждый час.

Ну мне сложно назвать профессионалом человека, который 10 лет программирует и не знает/понимает элементарных вещей.

Если он именно эту элементарную вещь 10 лет не использовал, то может и не знать. Вот я когда-то успешно сдавал экзамены по матану и аналитической геометрии. Но сейчас правильно отвечу может на 1 вопрос из 20 по тем темам.

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

Нигде не заставляют отчитываться за каждый час.

За каждый час нет, за каждый день да. Можно, конечно, читать урывками по 12 минут пару раз в день (получаются те самые 2 часа в неделю как-бы), но сомневаюсь, что в таком режиме можно что-то крупное выучить.

который 10 лет программирует и не знает/понимает элементарных вещей

Понятие элементарных вещей у каждого программиста своё.

Вспоминается https://imgs.xkcd.com/comics/average_familiarity_2x.png

Если он именно эту элементарную вещь 10 лет не использовал, то может и не знать.

Я же тебе не про порядок параметров в arraycopy() говорю, а про фундаментальные вещи. Это вещи, которые не используют напрямую, но их «помнят» всегда. Это про понимание а не память. Это как площадь прямоугольника. Как площадь прямоугольного треугольника, к которой без памяти можно прийти за секунду.

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

Так я же про *примитивные* вопросы. На всякую базу ты же ответишь, нет? Никто не спрашивает алгоритм Кнута-Мориса-Пратта.

За каждый час нет, за каждый день да. Можно, конечно, читать урывками по 12 минут пару раз в день (получаются те самые 2 часа в неделю как-бы), но сомневаюсь, что в таком режиме можно что-то крупное выучить.

Кто пишет код 8 часов в день пусть первый кинет в меня камень.

Понятие элементарных вещей у каждого программиста своё.

Нет, элементарное это элементарное. Открываешь любую книгу для новичков и оно там есть.

Вспоминается https://imgs.xkcd.com/comics/average_familiarity_2x.png

А зря вспоминается. В меме про average person, а мы, напомню, про профессионала говорим.