Человек всегда выбирает на что тратить своё время. В маленьком городе - больше времени на себя, семью, но вероятно меньше зароботок. В большом городе - больше зароботок. Но нет времени самому приготовить себе обед, погулять с ребенком и в целом провести время с семьёй. И эти пробемы создают не технологии, а всё та же проблема плотности начеления и пробок. Либо ты будешь тратить 15-20 минут похода на работу пешком. Либо 2-3 часа сидеть в пробках в автомобиле, а потом пытаться выкроить время для спорзала. А все эти технологии - это лишь средства удовлетворить запрос конретного общества в конкретных условиях.
Каршеринг, всё таки несколько снижает транспортную нагрузку хоть и косвенно. Такие авто - меньше простаивают, а значит в случае приехал на работу и нет частной парковки, такое авто будет меньше занимать крайнюю полосу там где парковка допустима. Хотя, конечно общественный транспорт справляется с этой задачей намного лучше. Так же хорошо справляются электроскутеры, которые мопеды. Но это вещь тоже сезонная.
Что-то много недосказанности. А как же сторона DevOps и тулов? ИМХО - мидл, должен хорошо знать техническую предментную область - язык программирования, паттерны, архитектуры - это всё легко учится из теории. А старшой - должен уже обладать более широкими софт скилами, знать разницу гибких и строгих методологий. И главное уметь плясать от продукта, а не от того что он умеет. Не совать везде - я так 20 лет он-лайн магазины писал и UI на приборку авто так же буду делать. А уметь выбрать оптимальную методику, архитектуру, паттерны. Уровень документации от самодокументируемого кода, до Detailed Design, Software&System Architecture документов. Объяснять мидлам и джунам, почему их супер-навыки в Vim в данной команде будут только во вред и что он не просто так потратил время на конфиг для IDE и настроили pre-commit git hooks. И сколько дрвгоценного времени это экономит. Ну и опять же это всё если проект для команды или нескольких команд. А если проект на 2 недели на коленке в одно лицо что-то состряпать. То тут не стоит убиваться и поднимать CI/CD на 4 энвайронментах. И писать конфиги, ревью чек-листы и архитектурные документы.
Даже если исключить финансовое неравество. У жителей мегаполисов и меньших городов - разные запросы и потребности. В мегаполисе сложно без авто добраться до работы, кинотеатра, любимого ресторана и т.д. В маленьких городах - это зачастую довольно просто сделать пешком. Кроме того улицы не столь перегружены автомобилями, поэтому собственный автомобиль доставляет больше радости. Вот еду можно заказывать одинаково. Хотя в целом, чем меньше город, тем размереннее ритм жизни. Поэтому для скорейшего возврата инвестиций сервисы и откатывают в районах с большей плотностью населения, а значит упрощенной логистикой, большим колличеством потенциальных клиентов и более высокой платежеспособность. В меньших городах, даже при равной плетажеспособности, люди реже будут пользоваться такими же сервисами, просто потому что не нужно. До 1991 года города строились по принципу пешей доступности, чтобы людям не нужен был личный автомобиль, всё необходимое можно было получить пешком, школы, детские сады, магазины, рынки, поликлиники. В остальных случаях общественный транспорт всё решает. Даже время работы практически всего в городах разное. В небольших, практически всё открывается к 8 часам утра. В крупных даже детские сады и школы могут начинать занятия в 9-10 часов. Потому что иначе просто не успеют родители привезти детей через пол-города по пробкам, а сотрудники также не успеют на работу. Но и заканчивают в малых городах к 4 часам после полудня. А в мегаполисах вполне нормально работать до 7-8 часов вечера. Современный мегаполис - это страшный микс устаревающих районов с пешей доступностью всего, непонятного хаоса застройки на протяжении 20 лет. И потом опять вернулись к комплексной застройке с сервисами в пешей доступности на территории ЖК. В меньших городах за те самые 20 лет не строилось практически ничего за редким исключением. В сёлах, опять же другая картина, там без авто никто не живёт практически из за больших растояний. Но и там картина изменилась, всё меньше людей живут с подсобного хозяйства. И всё больше живут обеспеченные люди, которые могут себе позволить и дом побольше и соответственно и автомобиль или 2-3 на семью. Они опять же вряд ли будут пользоваться каршерингом, а предпочтут купить в личное пользование. Например, как выглядит доставка продуктов в Греции в городке с населением 4-5 тысяч. Просто в определённое время один и тот же фермер едет на своём грузовичке, останавливается каждые 500 метров. К нему выходят люди и покупают необходимые им продукты. Зачем им отдельный сервис доставки? Ну и размеры города - таковы, что за 10 минут его можно полностью пройти пешком.
Патенты вышли и сейчас идёт активный бум на рынке. Год назад участвовал в проекте нового робота от Medtronic. Самая интересная часть не раскрыта, синхронизация времени между кучей нод в устройстве. Особенно, учитывая, что далеко не все они используют RTOS. Как правило на консоли хирурга все таки не QNX.
Тут всё несколько глубже. DevOps - человек, растёт из того же места, что и модное заблуждене под названием SCRUM. В котором из ролей всего ничего Product Owner, Scrum Master и Scrum Team. И все равно, что в этот Scrum Team нужны: разработчики, тестировщики, бизнес-аналитики, дизайнер ...
К чему это я всё? А к тому что это классная абстракция-прослойка удобная для рубахи парня - менеджера. Недавно вычитал на просторах, как бедным менеджерам без технического образования и бэкграунда тяжело живётся разбираясь между всеми этими разношёрстными трудягами из-за кого не попадают сроки или упал прод. И мол вот она серебрянная пуля - а мы скажем, что нет между ними разницы и помогут нам тут SCRUM и DevOps. И сразу жизнь у менеджера стала сладкая, сразу понятно у кого перфоманс просел. И руководить сразу проще стало, а что SCRUM ведь про self-organized team. Так и появились мифы о Universal Soldier(aka Cross-functional Team) и DevOps - человек.
Лучшая ложь - это та, в которой есть примерно 15% правды.
Если статьи пишутся для зачёта - это печально. Как вариант для статей необходимых перед защитой магистерской работы - думаю должно иметь право на жизнь. Habr - довольно уважаемый ресурс, полагаю лучше многих "изданий", которые печатают статьи без редакции и пруфридинга. Возможно в этом и кроется разница в качестве статей. Смотря какую задачу решали студенты, допуск к защите или один из многих зачётов.
Молодцы конечно, но выглядит как микроскопом по гвоздями. Ключевая проблема - заказчик постоянно меняет требования. Я понимаю,когда речь в рынке и необхомисти перехода с ДВА на электромотор. Но когда так поступает внутренний заказчик, это прямой вопрос к его компетенции в коммуникации. Зачем терпеть кучу не компетентные людей в компании и исключительно в угоду им устраивать дорогую смену процессов? Смена 20 десятков людей на более компетентные и умеющих думать наперед даст ещё больший эффект,за гораздо более скромные вложения.
И ещё вопрос если нужен был Enterprise Agile + Scrum, почему не SAFE или Nexus SCRUM?
Вот есть пару моментов в которые верится с трудом.
Что будет с камерами, если их заслепят криво настроенные встречные или дальним на подъёме?
Камеры на столько крутые что уже отличают картинки от реальности? Это в Европе хорошо, рекламой дороги не усыпаны. А у нас можно увидеть огромные рекламные щиты в десять метров от дороги. А если там повесят рекламу с другой дорогой или еще чем.
Есть еще весёлые фигурки школьников возле пешеходных переходов. Тут конечно и радары с лидерами не спасут, но очень интересно как Тесла себя поведёт.
Просто нужно найти того кто будет готов платить за твои навыки в том что тебе нравиться. Сложно найти в своей стране, ищи в другой. Это требует времени, навыков в коммуникации и изучения иностранных языков. Так что это действительно не проблема программирования, это проблема людей, которые готовы ради сиюминутных денег угробить свою жизнь, семью, карьеру. Это просто очередной карго-культ. Редко заканчивается чем-то хорошим для участников культа. И может непредсказуемо выстрелить в окружающих. Сейчас это в основном усложняет жизнь HR, где так уж совпало тоже оказалось много желющих, без понимания что они там делают. Поэтому необходимо просматривать в N раз больше резюме и примерно во столько же раз больше проводить собеседований. Иногда, правда, некоторые личности всё равно просачиваются и могут стать проблемой для ряда проектов. Правда это чаще связано с менеджментом пришедшем в IT нежели с программистами/тестировщиками/аналитиками. Нескольких человек технических можно нейтрализовать или разбавить грамотными. А вот 5 менеджеров на проект не поставят, чтобы нейтрализовать 1го не особо компетентного.
АСУТП пошло путем создания своих языков, потому что все остальные языки программирования возникли позже. Тут смысл был дать возможность программировать технологам и инженерам, потому что слова программист тогда еще даже толком небыло. А когда появилось, таких людей было крайне мало, чтобы обслужить всю промышленность. Как должен был данный инструмент быть создан для людей которых еще не существовало?
SCADA тут конечно несколько сбоку, но отрасль накладывает свой отпечаток. Изначально для отображения использовались картонно-деревянные стенды с лампочками и цифровыми блоками. Вероятно, они были даже более читаемые, менее вредные для зрения, и даже возможно красивее интерфейсов особенно на первых дисплеях. Когда производство дисплеев стало дешевле, чем работа напильником по дереву, стали ставить дисплеи и изобрели SCADA системы для отрисовки всего того с чем прекрасно справлялись стенды из картона или дерева с лампочками. Собственно инструмент создавался для людей которые уже работали на производстве и создан намеренно просто, чтобы не требовалось дорогостоящее переобучение персонала. Вероятно сейчас стоит пересмотреть данную парадигму, потому как программисты уже не такой дефицит и скорее инженеров способных разобраться в релейных схемах или хорошо оперирующих элементами Буллевой логики найти будет посложнее.
Ну тут скорее проблема только в том что это особое исключение для русского языка. Например, в иврите этим вообще никого не напугаешь. Гласные практически отсутсвуют и отображаются огласовками, которые не применяются в 90% случаев при печати. И все умудряются читать вполне себе.
Вообще-то это инструмент из-за которого программисты возникли как класс. Почитайте историю. Программирование вообще возникло как весьма примитивная программа управления ткацкими станками, где полёта фантазии вообще нет. Да есть легаси, потому что именно промышленность оказалась первой сферой готовой тратить средства на программистов. Да эта сфера не особо терпит всего нового, модного, молодёжного. Потому как надёжность — гораздо, гораздо дороже. Если думаете, что это проблема АСУТП и SCADA, то глубоко ошибаетесь. Этот отпечаток несут все Safety Critical сферы, где можно кого-то зашибить ненароком или подвисание программы выльется в милионы долларов. Я такое встречал как в АСУТП, так и в написании ПО для Medical Devices, авионике, морской навигации, даже в мега-портале юридической направленности. А всё потому что "красота" там спонсируется в последний момент. Средства скорее потратят на 5 лишних туров тестирования, чем на перерисовку. Потому что за "не красивый" интерфейс — максимум напишут просьбу улучшить. А за прокол в функционале, либо посадят, либо потребуют много денег. Именно поэтому в Enterprise и той же SCADA крайне мало OpenSource. Заказчик не хочет OpenSource по одной причине, если что-то случится по вине 3rd party библиотеки за которую заплатили деньги, отвечать будет разработчик той библиотеки, а в случае OpenSource — тот кто разрешил ее использовать в своём продукте. Никто не хочет неcти ответственность за то что сам не делал. Именно по этой причине данные отрасли так "нетерпимы" к OpenSource.
Если вам такое не по душе, лучше смотреть на IoT, web/mobile/application, game dev. Не даром эти отрасли являются локомотивами новых технологий.
Часть команды работает на VS Code, часть на QtCreator. Стэк не очень распространённый: C — под микроконтроллеры, С++ — под QNX и Windows и Python. В QtCreator до недавнего времени не очень ладилось с Python. Поэтому стали смотреть в сторону. CLion несколько разочаровал. Хоть и не заявлена поддержка qcc, но обламаться потому что в IDE наглухо вшиты ключи компиляции под gcc, которые не поддерживаются в qcc было обидно. Неужели нельзя было это в конфигурацию вынести?
Попробую еще WSL2. Но моя попытка работать с WSL убилась об отсутствие поддержки tun интерфейсов. А VPN заказчика подразумевает их использование для подключения к инфраструктуре. Так что далеко не всё там идеально.
Мне кажется мы дискутируем о деталях. Биплан — это схема с 2мя рядами крыльев в любой конфигурации. Частным случаем которой является биплан-тандем. Расположение рядов вертикально или горизонтально не меняет факта что есть 2 ряда крыльев. Трипланы тоже бывают разные. Как с вертикальной конструкцией, так и горизонтальной, СУ-33 или СУ-47.
Я вам блольше скажу. Алгоритмы, нынче, даже у тестировщиков на собеседованиях спрашивают.
Человек всегда выбирает на что тратить своё время. В маленьком городе - больше времени на себя, семью, но вероятно меньше зароботок. В большом городе - больше зароботок. Но нет времени самому приготовить себе обед, погулять с ребенком и в целом провести время с семьёй. И эти пробемы создают не технологии, а всё та же проблема плотности начеления и пробок. Либо ты будешь тратить 15-20 минут похода на работу пешком. Либо 2-3 часа сидеть в пробках в автомобиле, а потом пытаться выкроить время для спорзала. А все эти технологии - это лишь средства удовлетворить запрос конретного общества в конкретных условиях.
Каршеринг, всё таки несколько снижает транспортную нагрузку хоть и косвенно. Такие авто - меньше простаивают, а значит в случае приехал на работу и нет частной парковки, такое авто будет меньше занимать крайнюю полосу там где парковка допустима. Хотя, конечно общественный транспорт справляется с этой задачей намного лучше. Так же хорошо справляются электроскутеры, которые мопеды. Но это вещь тоже сезонная.
Что-то много недосказанности. А как же сторона DevOps и тулов?
ИМХО - мидл, должен хорошо знать техническую предментную область - язык программирования, паттерны, архитектуры - это всё легко учится из теории. А старшой - должен уже обладать более широкими софт скилами, знать разницу гибких и строгих методологий. И главное уметь плясать от продукта, а не от того что он умеет. Не совать везде - я так 20 лет он-лайн магазины писал и UI на приборку авто так же буду делать. А уметь выбрать оптимальную методику, архитектуру, паттерны. Уровень документации от самодокументируемого кода, до Detailed Design, Software&System Architecture документов. Объяснять мидлам и джунам, почему их супер-навыки в Vim в данной команде будут только во вред и что он не просто так потратил время на конфиг для IDE и настроили pre-commit git hooks. И сколько дрвгоценного времени это экономит. Ну и опять же это всё если проект для команды или нескольких команд. А если проект на 2 недели на коленке в одно лицо что-то состряпать. То тут не стоит убиваться и поднимать CI/CD на 4 энвайронментах. И писать конфиги, ревью чек-листы и архитектурные документы.
Даже если исключить финансовое неравество. У жителей мегаполисов и меньших городов - разные запросы и потребности. В мегаполисе сложно без авто добраться до работы, кинотеатра, любимого ресторана и т.д.
В маленьких городах - это зачастую довольно просто сделать пешком. Кроме того улицы не столь перегружены автомобилями, поэтому собственный автомобиль доставляет больше радости.
Вот еду можно заказывать одинаково. Хотя в целом, чем меньше город, тем размереннее ритм жизни.
Поэтому для скорейшего возврата инвестиций сервисы и откатывают в районах с большей плотностью населения, а значит упрощенной логистикой, большим колличеством потенциальных клиентов и более высокой платежеспособность. В меньших городах, даже при равной плетажеспособности, люди реже будут пользоваться такими же сервисами, просто потому что не нужно.
До 1991 года города строились по принципу пешей доступности, чтобы людям не нужен был личный автомобиль, всё необходимое можно было получить пешком, школы, детские сады, магазины, рынки, поликлиники. В остальных случаях общественный транспорт всё решает. Даже время работы практически всего в городах разное. В небольших, практически всё открывается к 8 часам утра. В крупных даже детские сады и школы могут начинать занятия в 9-10 часов. Потому что иначе просто не успеют родители привезти детей через пол-города по пробкам, а сотрудники также не успеют на работу. Но и заканчивают в малых городах к 4 часам после полудня. А в мегаполисах вполне нормально работать до 7-8 часов вечера. Современный мегаполис - это страшный микс устаревающих районов с пешей доступностью всего, непонятного хаоса застройки на протяжении 20 лет. И потом опять вернулись к комплексной застройке с сервисами в пешей доступности на территории ЖК. В меньших городах за те самые 20 лет не строилось практически ничего за редким исключением.
В сёлах, опять же другая картина, там без авто никто не живёт практически из за больших растояний.
Но и там картина изменилась, всё меньше людей живут с подсобного хозяйства. И всё больше живут обеспеченные люди, которые могут себе позволить и дом побольше и соответственно и автомобиль или 2-3 на семью. Они опять же вряд ли будут пользоваться каршерингом, а предпочтут купить в личное пользование.
Например, как выглядит доставка продуктов в Греции в городке с населением 4-5 тысяч. Просто в определённое время один и тот же фермер едет на своём грузовичке, останавливается каждые 500 метров. К нему выходят люди и покупают необходимые им продукты. Зачем им отдельный сервис доставки? Ну и размеры города - таковы, что за 10 минут его можно полностью пройти пешком.
Поднять локальное зеркало репозитория пакетов и прописать настройки на него.
Как никак все менеджеры пакетов должны их откуда-то скачивать.
Патенты вышли и сейчас идёт активный бум на рынке. Год назад участвовал в проекте нового робота от Medtronic. Самая интересная часть не раскрыта, синхронизация времени между кучей нод в устройстве. Особенно, учитывая, что далеко не все они используют RTOS. Как правило на консоли хирурга все таки не QNX.
Тут всё несколько глубже. DevOps - человек, растёт из того же места, что и модное заблуждене под названием SCRUM. В котором из ролей всего ничего Product Owner, Scrum Master и Scrum Team. И все равно, что в этот Scrum Team нужны: разработчики, тестировщики, бизнес-аналитики, дизайнер ...
К чему это я всё? А к тому что это классная абстракция-прослойка удобная для рубахи парня - менеджера. Недавно вычитал на просторах, как бедным менеджерам без технического образования и бэкграунда тяжело живётся разбираясь между всеми этими разношёрстными трудягами из-за кого не попадают сроки или упал прод. И мол вот она серебрянная пуля - а мы скажем, что нет между ними разницы и помогут нам тут SCRUM и DevOps. И сразу жизнь у менеджера стала сладкая, сразу понятно у кого перфоманс просел. И руководить сразу проще стало, а что SCRUM ведь про self-organized team. Так и появились мифы о Universal Soldier(aka Cross-functional Team) и DevOps - человек.
Лучшая ложь - это та, в которой есть примерно 15% правды.
"Половина - не бывает большей или меньшей. Но, к сожалению, большая половина класса этого не понимает." (с)
Если статьи пишутся для зачёта - это печально. Как вариант для статей необходимых перед защитой магистерской работы - думаю должно иметь право на жизнь. Habr - довольно уважаемый ресурс, полагаю лучше многих "изданий", которые печатают статьи без редакции и пруфридинга.
Возможно в этом и кроется разница в качестве статей. Смотря какую задачу решали студенты, допуск к защите или один из многих зачётов.
Молодцы конечно, но выглядит как микроскопом по гвоздями. Ключевая проблема - заказчик постоянно меняет требования. Я понимаю,когда речь в рынке и необхомисти перехода с ДВА на электромотор. Но когда так поступает внутренний заказчик, это прямой вопрос к его компетенции в коммуникации. Зачем терпеть кучу не компетентные людей в компании и исключительно в угоду им устраивать дорогую смену процессов? Смена 20 десятков людей на более компетентные и умеющих думать наперед даст ещё больший эффект,за гораздо более скромные вложения.
И ещё вопрос если нужен был Enterprise Agile + Scrum, почему не SAFE или Nexus SCRUM?
Вот есть пару моментов в которые верится с трудом.
Что будет с камерами, если их заслепят криво настроенные встречные или дальним на подъёме?
Камеры на столько крутые что уже отличают картинки от реальности? Это в Европе хорошо, рекламой дороги не усыпаны. А у нас можно увидеть огромные рекламные щиты в десять метров от дороги. А если там повесят рекламу с другой дорогой или еще чем.
Есть еще весёлые фигурки школьников возле пешеходных переходов. Тут конечно и радары с лидерами не спасут, но очень интересно как Тесла себя поведёт.
Просто нужно найти того кто будет готов платить за твои навыки в том что тебе нравиться. Сложно найти в своей стране, ищи в другой. Это требует времени, навыков в коммуникации и изучения иностранных языков. Так что это действительно не проблема программирования, это проблема людей, которые готовы ради сиюминутных денег угробить свою жизнь, семью, карьеру. Это просто очередной карго-культ. Редко заканчивается чем-то хорошим для участников культа. И может непредсказуемо выстрелить в окружающих. Сейчас это в основном усложняет жизнь HR, где так уж совпало тоже оказалось много желющих, без понимания что они там делают. Поэтому необходимо просматривать в N раз больше резюме и примерно во столько же раз больше проводить собеседований. Иногда, правда, некоторые личности всё равно просачиваются и могут стать проблемой для ряда проектов. Правда это чаще связано с менеджментом пришедшем в IT нежели с программистами/тестировщиками/аналитиками. Нескольких человек технических можно нейтрализовать или разбавить грамотными. А вот 5 менеджеров на проект не поставят, чтобы нейтрализовать 1го не особо компетентного.
АСУТП пошло путем создания своих языков, потому что все остальные языки программирования возникли позже. Тут смысл был дать возможность программировать технологам и инженерам, потому что слова программист тогда еще даже толком небыло. А когда появилось, таких людей было крайне мало, чтобы обслужить всю промышленность. Как должен был данный инструмент быть создан для людей которых еще не существовало?
SCADA тут конечно несколько сбоку, но отрасль накладывает свой отпечаток. Изначально для отображения использовались картонно-деревянные стенды с лампочками и цифровыми блоками. Вероятно, они были даже более читаемые, менее вредные для зрения, и даже возможно красивее интерфейсов особенно на первых дисплеях. Когда производство дисплеев стало дешевле, чем работа напильником по дереву, стали ставить дисплеи и изобрели SCADA системы для отрисовки всего того с чем прекрасно справлялись стенды из картона или дерева с лампочками. Собственно инструмент создавался для людей которые уже работали на производстве и создан намеренно просто, чтобы не требовалось дорогостоящее переобучение персонала. Вероятно сейчас стоит пересмотреть данную парадигму, потому как программисты уже не такой дефицит и скорее инженеров способных разобраться в релейных схемах или хорошо оперирующих элементами Буллевой логики найти будет посложнее.
Ну тут скорее проблема только в том что это особое исключение для русского языка. Например, в иврите этим вообще никого не напугаешь. Гласные практически отсутсвуют и отображаются огласовками, которые не применяются в 90% случаев при печати. И все умудряются читать вполне себе.
Вообще-то это инструмент из-за которого программисты возникли как класс. Почитайте историю. Программирование вообще возникло как весьма примитивная программа управления ткацкими станками, где полёта фантазии вообще нет. Да есть легаси, потому что именно промышленность оказалась первой сферой готовой тратить средства на программистов. Да эта сфера не особо терпит всего нового, модного, молодёжного. Потому как надёжность — гораздо, гораздо дороже. Если думаете, что это проблема АСУТП и SCADA, то глубоко ошибаетесь. Этот отпечаток несут все Safety Critical сферы, где можно кого-то зашибить ненароком или подвисание программы выльется в милионы долларов. Я такое встречал как в АСУТП, так и в написании ПО для Medical Devices, авионике, морской навигации, даже в мега-портале юридической направленности. А всё потому что "красота" там спонсируется в последний момент. Средства скорее потратят на 5 лишних туров тестирования, чем на перерисовку. Потому что за "не красивый" интерфейс — максимум напишут просьбу улучшить. А за прокол в функционале, либо посадят, либо потребуют много денег. Именно поэтому в Enterprise и той же SCADA крайне мало OpenSource. Заказчик не хочет OpenSource по одной причине, если что-то случится по вине 3rd party библиотеки за которую заплатили деньги, отвечать будет разработчик той библиотеки, а в случае OpenSource — тот кто разрешил ее использовать в своём продукте. Никто не хочет неcти ответственность за то что сам не делал. Именно по этой причине данные отрасли так "нетерпимы" к OpenSource.
Если вам такое не по душе, лучше смотреть на IoT, web/mobile/application, game dev. Не даром эти отрасли являются локомотивами новых технологий.
Часть команды работает на VS Code, часть на QtCreator. Стэк не очень распространённый: C — под микроконтроллеры, С++ — под QNX и Windows и Python. В QtCreator до недавнего времени не очень ладилось с Python. Поэтому стали смотреть в сторону. CLion несколько разочаровал. Хоть и не заявлена поддержка qcc, но обламаться потому что в IDE наглухо вшиты ключи компиляции под gcc, которые не поддерживаются в qcc было обидно. Неужели нельзя было это в конфигурацию вынести?
Попробую еще WSL2. Но моя попытка работать с WSL убилась об отсутствие поддержки tun интерфейсов. А VPN заказчика подразумевает их использование для подключения к инфраструктуре. Так что далеко не всё там идеально.
А все качали навык лука на людоеде, который не мог добраться к персонажу через деревья? Оставляя компьютер включенным на ночь.
Мне кажется мы дискутируем о деталях. Биплан — это схема с 2мя рядами крыльев в любой конфигурации. Частным случаем которой является биплан-тандем. Расположение рядов вертикально или горизонтально не меняет факта что есть 2 ряда крыльев. Трипланы тоже бывают разные. Как с вертикальной конструкцией, так и горизонтальной, СУ-33 или СУ-47.