Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова

Чтобы ещё больше зависеть от чужих сервисов.

Но надо держать в уме, что автор концептуально застрял в 90-х - начале нулевых, а в некоторых вопросах и вообще весьма странен.

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

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

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

давно нет необходимости страдать с динамическими библиотеками

Бред. Статически собранный софт не роляет в малых масштабах, пока такого софта единицы. Но как только у тебя весь софт в системе будет статическим, ты охренеешь от трат диска и оперативной памяти, потому что 50-100мб на бинарник станет нормой. И это безотносительно того, что для исправления проблем с безопасностью внутри динамической библиотеки, которую использует весь системный софт, достаточно обновить только библиотеку, а не ждать, пока мейнтейнер конкретной софтины почешется и закроет дыру.

В расте сделали статическую линковку, потому что так проще и удобнее для деплоя серверного софта. А сейчас они работают над динамической по причинам, которые я описал выше.

И он прав. Бездумное использование готового

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

И к ограничению функциональности программы

К ограничению функциональности ведет не библиотека, а мозги разработчика, которому религия не позволяет взять другую библиотеку, хотя бы допускающую возможность реализации необходимых фичей. И яркий тому пример - столь любимый столяровым FLTK, из-за использования которого в TigerVNC не могут реализовать херову гору важных пользовательских фичей.

Причём, опять же, при статической линковке я могу доработать библиотеку до состояния

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

А я начинаю подозревать в тебе не умеющего читать.

А я вас предупреждал. Я же предупреждал?

Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова (комментарий)

Да мне всё интересно, вдруг какую полезную рекомендацию по выкладыванию пакетов смогу добыть.

Продолжаю наблюдение, но столько попкорна в меня уже не лезет :).

Бред. Статически собранный софт не роляет в малых масштабах, пока такого софта единицы. Но как только у тебя весь софт в системе будет статическим, ты охренеешь от трат диска и оперативной памяти, потому что 50-100мб на бинарник станет нормой.

50-100Мб на сжираемую бинарником память и так норма. Бинарников в памяти не больше сотни, для современного компьютера ни о чём. Бинарников на диске порядка пары тысяч. 200 ГБ тоже ни о чём.

В реальности заметно меньше, потому что -flto выкинет ненужное.

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

Если на ней написана моя программа и эти баги мешают моей программе, их всё равно мне придётся исправлять.

И яркий тому пример - столь любимый столяровым FLTK, из-за использования которого в TigerVNC не могут реализовать херову гору важных пользовательских фичей.

А линковали бы статически и могли бы дописать всё, чего не хватает.

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

Ага. Написал программу, всё работает. Не хватает пары фичей. Выкидываем FLTK, берём Qt, переписываем всю программу. Потом не хватит ещё какой фичи, можно будет с Qt на Gtk переписать. Зато всегда есть чем заняться…

В подавляющем же большинстве случаев тебе это не понадобится вообще никогда.

Выше ты привёл два примера, когда это надо: исправить в баг в библиотеке, дописать недостающую функциональность в библиотеке.

Что лишний раз показывает нам, чего именно стоят академические регалии этой страны

Не перегибай. Академические регалии везде фрикам могут дать (и дают).

Я думал что уже давно всем очевидно, зачем изобретена динамическая линковка и почему RedHat убил статическую линковку glibc, но оказывается это очевидно не всем. Для меня очевидно, что динамическая линковка придумана для независимой разработки частей продукта разными группами разработчиков. Всё. Никаких других целей не было и нет. Сказка про «сокращение потребляемой памяти» - это старая сказка о заботе о пользователях, котрая легко убивается как и давно используемым форматом в маках, так и недавним распространением контейнеров.

Эту тему обсудили на этом сайте лет двадцать назад, и вот опять! Там ещё вопрос поднимали, существует ли дистр, в котором используется только статическая линковка, и я приводил в пример Cray Linux.

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

А какая разница для разработки от способа линковки? Чтобы те, кто используют библиотеку, не могли её изменять?

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

Сказка про «сокращение потребляемой памяти» - это старая сказка о заботе о пользователях, котрая легко убивается как и давно используемым форматом в маках, так и недавним распространением контейнеров.

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

Эту тему обсудили на этом сайте лет двадцать назад, и вот опять!

Потому что вы всё еще заблуждаетесь.

50-100Мб на сжираемую бинарником память и так норма.

Нет.

Бинарников в памяти не больше сотни

Нет.

200 ГБ тоже ни о чём.

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

Если на ней написана моя программа и эти баги мешают моей программе, их всё равно мне придётся исправлять.

Отсылаешь патч и исправляешь.

А линковали бы статически и могли бы дописать всё, чего не хватает.

А потом поддерживать свой ни с чем не совместимый велосипед.

Выкидываем FLTK, берём Qt, переписываем всю программу.

Просто вместо того, чтобы писать программу на нормальном тулките, ваша братия берет FLTK, а затем мучительно дополняет его платформозависимыми костылями под иксы, винду и мак. И будем честными, в кишки библиотеки с хорошей архитектурой тебе почти никогда не придется лезть, потому что она будет спроектирована так, чтобы всё нужное торчало наружу и было доступно для переопределения. В крайнем случае - закидываешь патч. А если твоя библиотека настолько дохлая, что патчи там принимают раз в полгода - то и использовать ее, конечно же, не нужно. Там где плохое сопровождение - там и баги.

Выше ты привёл два примера, когда это надо: исправить в баг в библиотеке, дописать недостающую функциональность в библиотеке.

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

В любом случае вопрос безопасности и потребляемого места здесь первостепенный.

Независимость. Твои косяки локализованы.

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

Вот только жизнь разрабам библиотеки это не облегчает жизнь никак: приходится очень внимательно следить за стабильностью public API & ABI, заморачиваться с версированием символов итд.

Берёшь https://ocw.mit.edu/collections/introductory-programming/

Вы серьёзно эту х*ту в картинках уровня сельскохозяйственного техникума в Лаосе считаете достойным введением в программирование для ВУЗа с международным именем?!

или https://www.w3schools.com/programming/index.php

Ещё более достойный способ зря потратить время. Если после первого можно хотя бы на Питоне уметь что-то лабать, то это вообще ни уму, ни сердцу.

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

Вы серьёзно эту х*ту в картинках уровня сельскохозяйственного техникума в Лаосе

Это ты с позиции профессора калифорнийского технологического университета судишь, или с позиции бюджетника в усть-урюпинском заборостроительном училище, преподавателем в котором на полставки с трубочистом ты примерно и являешься? Нам действительно надо знать мнение о курсе MIT от человека, который не в состоянии прочитать две страницы мануала по systemctl, чтобы решить свою проблему, и потом бегающего и рассказывающего небылицы по форуму?

Ещё более достойный способ зря потратить время.

Более чем. Не умея в веб ни в зуб ногой, я в него научился по мануалам с w3schools и запилил коммерческий продукт, который меня теперь кормит.

Независимость. Твои косяки локализованы.

Опять не понял. Вот есть две программы с одинаковым кодом и одинаковыми библиотеками. Одна слинкована динамически, вторая статически. В них проявляется одинаковая ошибка. Как она более локализована в первой?

Это правда. Никак. И не должно. Цель была лишь разделить разработку.

Идите дальше. Вот есть проект на, скажем 10000 строк. Вы сделали inline всех функций и процедур и получили один длинный main(). В какой исходник легче внести изменения, в тот, в котором действия разбиты и функционально локализованы, или в одну длинную портянку?

Цель была лишь разделить разработку.

Дык. Разрабам апликух практически без разницы дали им headers + .so или headers + .a. Если что-то и упрощается так это деплоймент фиксов.

Есть ещё schedule, roadmap, budget, human force, FTEs, и вообще независимая поставка всего проекта и подпроектов. Динамическая линковка очевидно позволяет поставлять проект по частям.

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

То есть все программы занимают не больше 20% диска. Ни о чём.

Отсылаешь патч и исправляешь.

И ждёшь, пока патч примут в библиотеку (если не откажут, потому что патч от русского). Потом ждёшь пока, новую версию примут в дистрибутив, потом пока пользователь обновится на новую версию. И только тогда пользователь сможет увидеть программу без надоедливого бага.

А в статической линковке исправил и сразу отдал пользователю.

А потом поддерживать свой ни с чем не совместимый велосипед.

В чём проблема его поддерживать, если он часть программы?

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

И какую же библиотеку с хорошей архитектурой рекомендуете вместо FLTK?

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

И ждёшь, пока этот патч доползёт до разработчика дистрибутива.

В любом случае вопрос безопасности и потребляемого места здесь первостепенный.

Безопасность при статической линковке тоже выше. При динамической для безопасности надо все библиотечные функции считать заведомо вредоносными, так как что там будет у пользователя с учётом LD_PRELOAD заранее неизвестно. При статической весь код можно считать доверенным.

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

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

Так механизм линковки никак не меняет исходник. Как была библиотека с н файлов по м функций и программа с н1 файлов по м1 функций, так при статической линковке и осталось. Бинарных файлов стало вместо двух один, но в бинарные файлы изменения не вносят.

Динамическая линковка очевидно позволяет поставлять проект по частям.

Статическая тоже. Для запуска программы её всё равно надо слинковать и нет разницы, сделано это один раз при компиляции или каждый раз при запуске.

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

Нам действительно надо знать мнение о курсе MIT от человека, который не в состоянии прочитать две страницы мануала по systemd?

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

Не умея в веб ни в зуб ногой, я в него научился по мануалам с w3schools

Затратя сколько времени? Листали для сравнения другие книги? Заходили в тупик при изучении?

Я же писал про предложенный вводный курс, а не про все материалы.

Ну, вот открыл я курс (https://www.w3schools.com/bash/bash_commands.php) по всем известный Bash. Первый вам вопрос, с какого перепугу они называют «Common Bash Commands» такие общеюниксовые утилиты, как ls, chmod, rm? А echo есть даже в cmd.com.

man bash много полезнее и информативнее.

Посмотрел их материалы про Си. Пользоваться можно, если ничего другого нет.

Подобный способ подачи материала подходить только для учеников с СДВГ, для остальных, способных читать хотя бы 2 страницы текста за раз, это мучение – скармливать мозгу столь крошечные порции.

В случае динамической линковки вы можете независимо править, изменять, дополнять свой код и не зависимы от основного цикла разработки. Скомпилировали - отослали заказчику, изменили, скомпилировали, отослали опять. Не нужно собирать всё.

В случае статической тоже. Для LGPL явно описано, как именно (заказчику отправляются объектные файлы и библиотека, чтобы он мог слинковать). Так что можно и независимо. Разве что часть преимуществ статической при этом исчезает: модифицированную версию так просто не обновить, ответственность за работоспособность программы размывается.

А в статической линковке исправил и сразу отдал пользователю.

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

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

вообще независимая поставка всего проекта и подпроектов

Крайне рисковая затея, должен заметить. Даже изменения в конфигурации могут привести к крайне неприятным последствиям - перетестировать всё придётся по-любому, в «mission critical» случаях так точно.

А что делать? когда нужно “mission critical”, тогда один способ, когда нужно «тяп ляп и в прод», тогда другой.

Давайте, я как программист программисту, сейчас набросаю иллюстрацию того, что я имею в виду, хорошо? Эх, давно не брал я в руки шашек … ну ничего, сейчас наваляю что-нибудь.

То есть все программы занимают не больше 20% диска. Ни о чём.

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

ждёшь

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

И какую же библиотеку с хорошей архитектурой рекомендуете вместо FLTK?

Qt или GTK.

И ждёшь, пока этот патч доползёт до разработчика дистрибутива.

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

Безопасность при статической линковке тоже выше.

Нет. Я уже объяснил, почему, перечитывай заново мои комментарии выше.

При статической весь код можно считать доверенным.

Нельзя.

Вам действительно надо знать мнение профессионального педагога

Это правда. Вот только я пока не вижу в этом треде ни одного комментария от профессионального педогога.

Затратя сколько времени?

Пару недель.

Листали для сравнения другие книги? Заходили в тупик при изучении?

Нет и нет.

с какого перепугу они называют «Common Bash Commands»

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

люди все одинаковые, просто ты считаешь, что академики отличаются.

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

Проблема с высером Столярика в том что он не ставит задачу «научить программированию», он ставит задачу «научить программировать так как нравится Столярику» - именно отсюда идиотские определения, не имеющие отношения к общепринятым, дохлые языки и полная каша из концепций.

Наверное любой автор, если не по заказу пишет, учит как нравится ему. С определением побочных эффектов он что-то мутное навертел, но насчёт дохлости языка не уверен, что язык настолько дохлый и настолько негодный для обучения. FreePascal + Lazarus в общем-то достаточно неплохи.

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

Может я чего-то пропустил, но вроде против функциональных языков, вроде Haskell, Столяров ничего не имеет. Python же, хотя и содержит элементы функциональщины, сложно их к ним отнести.

А вот для Столярика групповая идентичность это всё - любой, пишущий не в строгом соответствии с его идиосинкразиями это предатель и идиот.

А вот это, к тому же ещё и нежелание свои идиосинкразии не то, что пересмотреть, а даже обсудить - это и есть за что его критикуют.

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

то может ты что то не знаешь?

Ага. Например я не знаю, каким образом эти существа доживают до возраста, где им каким-то чудом дают кандидатскую.

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

Динамическая библиотека - это не только про экономию памяти, но мы ещё и привыкли к динамическим библиотекам, а если все программы станут таскать статику с собой никакой памяти не хватит.

И он прав. Бездумное использование готового приводит к крайней хрупкости: https://xakep.ru/2016/03/24/left-pad/

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

Тот же Rust, с моей точки зрения главное чем плох, особенно, если в качестве системного языка, так это тем, что он завязан на интернет и хотя раст и позволяет организовать локальный репозиторий, но сделать так, чтобы можно было компилировать свои программы без выхода в интернет не очень просто и может потребовать непредсказуемо больших объёмов памяти на диске. При этом из самих по себе механизмов языка Rust ничего подобного не вытекает.

Но требование готовности включить сторонние либы в свой проект как свои собственные, очевидно, что с ростом сложности решаемых задач и поэтому неизбежным ростом объёма и сложности кода библиотек становится невыполнимым. В итоге, «по Столярову» надо или отказаться решать задачу. Или решать её вместо пары дней пару лет ;-) Или отказаться от идиотского требования, но за отказ он назовёт идиотом или ещё похуже.

У новичков нет никакого бекграунда, позволяющего отделить бредни автора от сносной информации непосредственно по теме.

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

А линковали бы статически и могли бы дописать всё, чего не хватает.

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

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

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

@monk

Пришлось отвлечься, всё-таки на работе сижу. Итак, имеем код. Строки 2-16 - главный код, строка 3 - всё, что даётся разработчику библиотеки. После того, как строка 19.5 выполнена, вы можете продолжать разрабатывать сврю библиотеку и поставлять новые версии println.so, как в строках 32-33. Да, идея плохая для mission critical applications, but who cares?

     1  Hello$ cat hello.c
     2  #include <stdio.h>

     3  void printlib( char * );

     4  int main()
     5  {
     6      printf("Hello, main!\n");
     7      printlib( "Hello, shared library!\n");
     8      return 0;
     9  }

    10  Hello$ cat println.c

    11  #include <stdio.h>

    12  void printlib( char *str )
    13  {
    14      printf( "%s", str );
    15      return;
    16  }

    17  Hello$ gcc -O2 -g -c -o hello.o hello.c
    18  Hello$ gcc -O2 -g -fPIC -c -o println.o println.c
    19  Hello$ gcc -O2 -g -shared -o println.so println.o
    19.5 Hello$ gcc -O2 -g -o hello hello.o println.so
    20  Hello$ ./hello
    21  Hello, main!
    22  Hello, shared library!

    23  ////// Now adding modifications to println.c //////////

    24  Hello$ cat println.c

    25  #include <stdio.h>

    26  void printlib( char *str )
    27  {
    28      printf( "%s", str );
    29      printf( "Added my new and independent modification\n" );
    30      return;
    31  }

    32  Hello$ gcc -O2 -g -fPIC -c -o println.o println.c
    33  Hello$ gcc -O2 -g -shared -o println.so println.o
    34  Hello$ ./hello

    35  Hello, main!
    36  Hello, shared library!
    37  Added my new and independent modification

но это у всех преподов

Да хрен там плавал! Это я тебе как бывший (хотя кому я вру - всяко ещё не раз припашут :) преподаватель говорю. Любой адекватный препод без проблем отделит объективно неправильное от эстетически несимпатичного ему персонально - и пояснит это студенту у которого возникло желание разобраться в теме глубже чем требует базовый курс. Это самая что ни на есть базовая часть профессиональной этики.

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

Golden boy by Fillipe Dick

19.5 Hello$ gcc -O2 -g -o hello hello.o println.so

Вместо

cp /distr/println.so /usr/lib

в статике будет

cp /distr/println.a /usr/lib
ld -o /usr/bin/hello /usr/lib/println.a /usr/lib/hello.o

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

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

Паскаль был достаточно массовым тогда, в начале 1970-х ?

Но там дело не в динамической линковке, а в привычке тащить в рантайме модули из интернета и слишком сильной зависимости от сторонних репозиториев.

Я здесь не про линковку, а про зависимость от чужой библиотеки. Если ты решил использовать для графического интерфейса Gtk, то за тебя решили, что новые версии твоей программы не будут поддерживать X. Если решил использовать recaptcha, то внезапно от твоих пользователей требуется зарегистрировать учётку в гугле.

Как только используешь чужое, часть решений от тебя уже никак не зависит. Причём если заложился при расчёте затрат на то, что чужое «всегда есть и бесплатно», то у тебя даже нет возможности отказаться (так как ресурсов на написание самостоятельно у тебя нет).

Но требование готовности включить сторонние либы в свой проект как свои собственные, очевидно, что с ростом сложности решаемых задач и поэтому неизбежным ростом объёма и сложности кода библиотек становится невыполнимым. В итоге, «по Столярову» надо или отказаться решать задачу. Или решать её вместо пары дней пару лет ;-) Или отказаться от идиотского требования, но за отказ он назовёт идиотом или ещё похуже.

Вот под этим лозунгом люди обсуждают коммерческую тайну при включенных смартфонах с Интернетом. Ставят ИИ-колонки к себе домой. Ставят ИИ-агенты на рабочие компьютеры. Передают гуглу всю рабочую и личную информацию https://habr.com/ru/articles/785874/. Ведь иначе «решать её вместо пары дней пару лет».

Бесплатный сыр только в мышеловке.