новые патч версии наоборот более стабильны. Возможно выше назвал их "минорными" - если так, то имел в виду именно патч. В них только багфиксы, они априори не могут быть менее стабильными)
А ваши апгрейды базы не требуют доп. зависимостей? Вот прям никаких? На голом alpine все запустится? Не смешите.
чем тонна непонятных бинарников на уровне системы непонятных версий и, как сказали выше, с непредсказуемым IO.
Одно, конечно же. Либо один микросервис, либо одна общая библиотека.
Да не будет никаких проблем, поднимая патч версию. А остальное - о чем я и говорю. Поднимать версию руками так точно никто не станет чаще раза в год. Если оно обновляется по указанной где-то там версии само, одновременно на всех енвайронментах и у всех девов - та хоть раз в месяц.
Я не говорил про уязвимости) Я говорил про очевидные баги базы, вызывающие проблемы у конечных юзеров проекта.
Да, если в фреймворке есть таковые и оно решено в новых версиях - мы поднимаем версию, конечно.
И обновляем мы его меняя циферки версии в одном файле, diff на одну строчку :)
Примитивный - это не попытка обидеть вашу любимую игрушку, это констатация факта. Если в python вы положите команду в переменную, она не начнет выполнятся при выводе на экран.
$ A="echo B"
$ echo $A
echo BВерно. И у bash нет нормальных тест-фреймворков.
Конечно, да. Но тут либо CI/CD решает 100% задач, либо приходится допиливать что-то. И, опять же, редко когда удается допилить требя строчками bash скрипта.
Ну вот помимо существующих CI/CD, с радостью попробую kotlin script.
В том, что этот метод нужно поддерживать в двух местах, вместо одного? Насобирать три-четыре таких места и никто не захочет это трогать.
И как это решает то, что люди (девопсы) за*бутся апгрейдить ее постоянно ручками? Да никак, проекты тупо забивают и скедьюлят "апгрейд архитектуры" раз в миллион лет - ну потому что не будут же они обновлятся раз в месяц. А фиксы, нужные фиксы базы, релизятся раз в месяц, если не чаще.
Если вам в жизни удастся поуправлять самолетом, вы не станете пилотом.
А вы пишите, что вполне нормально копировать все страницы памяти, для простейших операций.
Но писать про это предлагая взамен полное копирование всех страниц памяти интерпретатора (fork) даже при элементарных операциях - это показывать полное непонимание на чем можно экономить
Но, работая с Си, вы должны были заметить отличия в разделении кода и данных, кастомных типах позволяющих создавать сложные типы данных и огромное кол-во функционала который позволяет назвать Си универсальным языком программироавния в отличии bash специализирующего на запуске команд.
Но давайте поговорим не о копировании файла, а, например, о билде и деплое проекта.
Я про автоматические тесты.
Из банального:
- погрупировать таски
- записывать время выполнения каждой мелкой таски
- проверять что она не завалилась
- репортить все это в какой-нить слэк в конце
- делать ролбек в случае неудачи
- подчищать за собой остатки
Все это делается очень легко с помощью нормального языка. С bash это адская боль.
Ну, например в проекте есть код, вытаскивающий актуальную версию чего-то там с помощью какого-нить github SDK. Потом эта версия понадобилась в каком-то скрипте. Если проект и скрипты на одном языке - это элементарно шерится. Если на разных - проще вообще не шерить.
Ну да. Как часто вы обновляте базы на продакшене? Девелоперы хотят делать это условно раз в месяц, но без контейнеров заниматся этим будут в лучшем случае раз в два-три года.
Да нет, не использую. Над таким "облачным решением" обычно ноль контроля - оно падает когда захочет, обновляется только руками в дешборде, отстает по версиям от self-hosted.
Затем что обновлять его нужно одновременно у девов, QA, на тестовых, на стейдже, на продакшене. На каждом хосте ручками ставить нужную версию? А она же еще совпадать должна!
Я к тому и веду, что, имхо!!, это временно.
Только, опять же, джава легко тестируется, более удобна, легко шерит код между проектом и "скриптами" автоматизации, не использует никакие костыли.
Это "используем современные подходящие технологии, без велосипедов и заебов". Да, намного проще запустить контейнер с клиентом мускула, что бы создать базу и намного проще обновить контейнер с httpd, чем пытатся сделать это руками/косячной автоматизацией на баш.
ООП бесполезная трата ресурсов, ведь все можно сделать через if и for
Но, действительно, спорить бесполезно с человеком, кто не писал ничего сложнее скриптов автоматизации
Понимаю, что для сисадмина все разработчики занимаются фигнёй, ведь все можно просто и легко сделать в bash.
Acronis - странно, один из лидеров, и вроде хорошо умеет в разные файловые системы
Veeam - сам агент жрал много места или бэкапы? вроде как прям тоже лидер.