как по мне, так в ипотеке там просто меньшие суммы страховок/комиссий. "нечестность" калькулятора только в том, что он не разбивает платёж на проценты и доп.платежи.
Все платежи одинаковые. Это ваша придумка про последний платёж. Если платежи разные, то это уже дифференцированные платежи.
вы хоть раз брали кредит? )
ваша фундаментальная ошибка тут - в вере калькулятору на сайте, а не окончательному графику платежей в договоре. ну и, похоже, опыта нет, иначе бы не писали выше процитированное.
ну и вдобавок вы смешиваете тёплое с мягким в виде процентной ставки и навязанных услуг.
если нормально посчитать всё с учётом ставки и этих самых услуг, суммы сойдутся.
если учесть стоимость услуг, процент за пользование кредитом вырастёт, а процентная ставка по кредиту - нет.
это вам уже несколько раз в комментах пытались объяснить, и я потерпел неудачу как и все остальные)
мне кажется, в договоре всё будет по вашему сценарию, как всегда и было. либо там в этих 70к участвуют страховки/комиссии и в калькуляторе это опять же реализовано в угоду простоте формы, а в договоре будет расписано математически верно.
вы хоть в одном банке из опробованных видели посчитанный график платежей, а не форму калькулятора с одним числом?
последний платеж всегда меньше ежемесячного, это очевидно, и никому наверное даже в голову не приходило писать в калькуляторе "ежемесячный платёж 263759р, а вот в последний месяц 193504!!"
вряд ли нужно родиться до 1930 года.
вероятнее всего триггер на начале эпохи, то есть 1970 год, когда unix timestamp становится отрицательным. и в переводе отрицательного timestamp в человекочитаемую дату скорее всего и зарыта собака в Safari.
да, ещё забыл, если вы в своём приложении имеете разветвлённые зависимости от сторонних чартов или контейнеров с докерхаба — тушите свет :)
перепиливать самостоятельно придётся 90% оных.
если изначально на это закладываться, то не так страшно.
как минимум, не запускать контейнеры под root, не использовать в контейнерах привилегированные порты, заложиться на разнообразие ingress-контроллеров, не использовать volume с типом emptyDir, корректно работать с limits/requests.
если соблюдать эти базовые вещи, то переточить приложение под ограничения (их может быть много самых извращённых, и опеншифт этому потакает :)) конкретной большой конторы — будет уже сильно проще. ну и это всё больше про крупные приложения, если у вас в чарте десяток файликов и пара-тройка контейнеров, то переход делается за день
так что, если планируется выкат в openshift, будет очень разумно либо разрабатывать сразу под него (на бесплатном okd), либо накрутить все полиси на ванильном k8s максимально близко к опеншифту.
нужно будет сначала удалить то, что нужно перегенерить, или в отдельной папке это делать. там, в принципе, всё интуитивно. kubeadm будет ругаться на всё, что ему не нравится, нужно это устранять и запускать заново :)
если нужно восстановить работу кластера здесь и сейчас, то путь через kubeadm займёт буквально пару минут.
Если вы чувствуете в себе желание запускать RDBMS в docker, то в статье systemctl start поменяется на docker run, всё остальное плюс-минус останется тем же. Статья же про миграцию, а не про запуск. Либо я не понял суть комментария :)
Рассматривались мельком. Прорабатывать вопрос начали с pglogical, и к счастью он нас в итоге полностью устроил. Возможно, для кого-то будет интереснее Slony (он как минимум умеет реплицировать версии старше 9.4) или что-то ещё.
По цифрам у вас производительность СХД 1 ГБ/с на запись + 1 ГБ/с на чтение одновременно? Как говорится, остаётся только позавидовать :)
Но в общем и целом, да, совершенно согласен, и написал об этом — если вы можете себе позволить даунтайм на время работы pg_upgrade — незачем городить огород.
Да, этот чарт в принципе качественный и хорош для случаев «нет времени объяснять, нужен кролик здесь и сейчас». Когда мы используем инструмент, то хотим понять, как он работает. Решения вроде «включи рубильник и иди домой» нам не подходят, потому что если что-то пойдёт не так, мы хотим понять, в чём проблема, а для этого нужно понимание, как это работает.
как по мне, так в ипотеке там просто меньшие суммы страховок/комиссий. "нечестность" калькулятора только в том, что он не разбивает платёж на проценты и доп.платежи.
вы хоть раз брали кредит? )
ваша фундаментальная ошибка тут - в вере калькулятору на сайте, а не окончательному графику платежей в договоре. ну и, похоже, опыта нет, иначе бы не писали выше процитированное.
ну и вдобавок вы смешиваете тёплое с мягким в виде процентной ставки и навязанных услуг.
если нормально посчитать всё с учётом ставки и этих самых услуг, суммы сойдутся.
если учесть стоимость услуг, процент за пользование кредитом вырастёт, а процентная ставка по кредиту - нет.
это вам уже несколько раз в комментах пытались объяснить, и я потерпел неудачу как и все остальные)
мне кажется, в договоре всё будет по вашему сценарию, как всегда и было. либо там в этих 70к участвуют страховки/комиссии и в калькуляторе это опять же реализовано в угоду простоте формы, а в договоре будет расписано математически верно.
что не отменяет, конечно, несомненное зло в виде всяких страховок и комиссий
вы заплатите 193504.
вы хоть в одном банке из опробованных видели посчитанный график платежей, а не форму калькулятора с одним числом?
последний платеж всегда меньше ежемесячного, это очевидно, и никому наверное даже в голову не приходило писать в калькуляторе "ежемесячный платёж 263759р, а вот в последний месяц 193504!!"
вероятнее всего триггер на начале эпохи, то есть 1970 год, когда unix timestamp становится отрицательным. и в переводе отрицательного timestamp в человекочитаемую дату скорее всего и зарыта собака в Safari.
перепиливать самостоятельно придётся 90% оных.
как минимум, не запускать контейнеры под root, не использовать в контейнерах привилегированные порты, заложиться на разнообразие ingress-контроллеров, не использовать volume с типом emptyDir, корректно работать с limits/requests.
если соблюдать эти базовые вещи, то переточить приложение под ограничения (их может быть много самых извращённых, и опеншифт этому потакает :)) конкретной большой конторы — будет уже сильно проще. ну и это всё больше про крупные приложения, если у вас в чарте десяток файликов и пара-тройка контейнеров, то переход делается за день
нет, нет и ещё раз нет. переход с ванильного k8s на openshift лежит через страдания, как devops, так и разработчиков.
если нужно восстановить работу кластера здесь и сейчас, то путь через kubeadm займёт буквально пару минут.
systemctl startпоменяется наdocker run, всё остальное плюс-минус останется тем же. Статья же про миграцию, а не про запуск. Либо я не понял суть комментария :)Но в общем и целом, да, совершенно согласен, и написал об этом — если вы можете себе позволить даунтайм на время работы pg_upgrade — незачем городить огород.
Основные причины: персистентные ID контейнеров и упорядоченный запуск.