Да даже копируя простой tail --lines=100 из ответа стаковерфлоу
Вы не правы, совсем. Языки прячут os-specific штуки за абстракциями. Добится неработоспособности какого-то кода на одной из платформ - очень и очень сложно. Нужно прямо хорошенько постаратся.
.. нет, не можете. То, что вы хотите, называется не библиотека, а целое консольное приложение. Что бы у нее была точка входа, парсер аргументов, вывод exit code, stdout и stderr. Это в разы дольше и сложнее, чем просто библиотека, которую можно использовать только как зависимость к другому проекту и никак иначе.
Не могу, к сожалению. Этот конкретный пример - вообще не место для скриптового языка. А другого примера не знаю, но уверен, что у скриптовых языков есть применение. И именно о таких местах надо было говорить изначально)
Я поэтому и уточнил, что мы взяли этот кейс для примера.
Речь вообще может идти не об обновлении. И даже если говорить об обновлении, то аргумент "подавляющее большинство" не валиден, ибо если есть хоть одна софтинка, которой нужно что-то кроме нее самой, то с этим подходом в корне уже что-то не так, раз он не универсален.
Имел в виду то, что для самих скриптов может быть нужно что-то еще. Такие же доп. зависимости, какие могут быть нужны и в примере выше.
Понятно, что простенькие баш скрипты скорее всего будут работать везде. Но даже у этого нет никаких гарантий! Если у ls на макоси или у ls на ubuntu 10 какого-то одного флажка нет, потому что там ls кастомный или старой версии, то даже с "популярными" gnu tools ваш скрипт завалится.
Условная котлин библиотека не компилируется в баш и, обьективно, никогда не будет. А использовать такую библиотеку как executable вы не сможете, так как это библиотека, а не executable :/
Я вел к тому, что решения типа докер компоуза подходят сюда намного лучше, чем любая полу-ручная автоматизация.
Принимаем решение исходя из цены и выгоды обеих решений.
Обьективно, уязвимости находятся довольно редко.
Я просто хотел узнать, что нужно впитать до того, как приступить к изучению уже языков, потому что языки, как по мне, это уже вторая ступень к становлению джуном.
И да, вот, кстати, карта, по которой я, незнающий некоторых элементарных вещей в этой области, должен стать геймразработчиком.
Ну мы же для примера взяли базу и вообще процесс обновления) Явно не может быть такого, что всегда обойдется без зависимостей, это нонсенс.
Для баша? Или для типичных (опять же, типичных в моем понимании) скриптов на нем? Первое - это понятно, а второе - отписал выше)
Нет. Вы же спросили про "метод", я про него и ответил. Фронт и бэк априори не могут быть на одном фреймворке, но легко могут использовать библиотеку, написанную на одном языке.
Ну не прям руками. Но и не автоматически. Опять же: есть у вас 50 девов и в придачу еще 6-8 стейдж/прод енвов. На каждом будете вручную запускать скрипт, даже если допустить, что он универсально выполнится на linux/macos/docker разработчиков и условный ubuntu/docker стейджов? А если через день найдется бажок и нужно будет откатить? Опять все руками?
Это, все таки, разные вещи. Если вас в команде 3 человека и у вас только стейдж и прод - ок, это терпимо. Но с любым более-менее большим проектом это совсем не работает.
Патч и даже минорная - нет, не требует, иначе вам стоит сменить фреймворк. Если мажорную - конечно, но мажорные версии любых больших продуктов выходят не чаще раза в год. Там подготовка, согласование и костыли при апдейте - вполне нормальны.
Вообще я не понимаю, как это связанно с тем, о чем мы разговариваем. Но все проходит через пулл реквесты, встроенные автоматические секьюрити чеки и проверку лицензий. Если имеется в виду ручной аудит, то это либо просто еб*нутые конторы, которым некуда потратить сотни тысяч на разработку собственных решений (вместо тех, которые предполагаемо не пройдут аудит), либо очень большие конторы, которым это даже выгодно.
новые патч версии наоборот более стабильны. Возможно выше назвал их "минорными" - если так, то имел в виду именно патч. В них только багфиксы, они априори не могут быть менее стабильными)
А ваши апгрейды базы не требуют доп. зависимостей? Вот прям никаких? На голом alpine все запустится? Не смешите.
чем тонна непонятных бинарников на уровне системы непонятных версий и, как сказали выше, с непредсказуемым IO.
Одно, конечно же. Либо один микросервис, либо одна общая библиотека.
Да не будет никаких проблем, поднимая патч версию. А остальное - о чем я и говорю. Поднимать версию руками так точно никто не станет чаще раза в год. Если оно обновляется по указанной где-то там версии само, одновременно на всех енвайронментах и у всех девов - та хоть раз в месяц.
Я не говорил про уязвимости) Я говорил про очевидные баги базы, вызывающие проблемы у конечных юзеров проекта.
Да, если в фреймворке есть таковые и оно решено в новых версиях - мы поднимаем версию, конечно.
И обновляем мы его меняя циферки версии в одном файле, diff на одну строчку :)