По порядку получится только если есть или можно создать единое централизованное место генерации — оно же единая точка отказа. Из коробки, вроде, в популярных базах с поддержкой мастер-мастер репликации только костыли разной степени лепить можно.
Недостатки этих способов я знаю, но для использования systemd с ними придётся мириться так или иначе. Предпочтительно залить кадрами, деньгами и времени а-ля отдельная если не команда, то специалист, для качества и предсказумости начальной разработки и поддержки. На практике, скорее, маны в зубы и пилить в личное время без "код-ревью" или как там процесс называется.
И здесь выясняется, что если нет гипер требований по изоляции — мы можем поверх того же железа натянуть кубер и управлять контейнерами с БОЛЕЕ ВЫСОКОЙ утилищацией аппаратных ресурсов…
Вот только кубер здесь необязательное звено. Нередко только уменьшающее утилизацию и аппаратных и человеческих ресурсов для сценариев типа "поднять 100500 сайтиков на одном хосте".
Для меня это всё обычные ошибки. Можно пояснять в теле, что не так или рекомендации какие-то давать. А когда неверный урл, то не то что обычная (пользователь ввёл что-то не то), а критическая или типа того — код неправильно написан.
Знакомый рассматривает вариант после того, как установил свой дизель-генератор в своём доме как основной источник электричества. По предварительным расчётам вроде выходит, что дешевле и удобнее время от времени завозить соляру и от неё заряжать условный лиф, чем заправлять его бензином постоянно и на сторонних платных "зарядках" заряжать.
Вроде про КПД речь шла, а не про расход заряда? Если на горку что-то поднимать, то работы больше нужно совершать исходя из физики, в которой вечный двигатель невозможен. А КПД тут только если двигатель/источник энергии в горку работает неоптимально, на сколько-то джоулей полезной работы тратит больше квт-ч час чем на ту же работу на ровном месте.
Вот не понимаю я этого максимализма "раз связались с докер, то нужно идти до конца и деплоиться в куб". Ладно когда стоят задачи масштабирования, отказоустойчивости, абстрагирования от чего угодно и бизнес готов за это платить и за железо, и администратрам (своим, аутсорсу или облака — не суть), и разработчикам (если хоть немного разделяем девопс). Но когда докер вводится в проект исключительно или почти исключительно как продвинутый chroot, то зачем туда всё это?
По порядку получится только если есть или можно создать единое централизованное место генерации — оно же единая точка отказа. Из коробки, вроде, в популярных базах с поддержкой мастер-мастер репликации только костыли разной степени лепить можно.
По авторитетным источникам я жил при коммунизме. ) Как мне не знать? ))
Недостатки этих способов я знаю, но для использования systemd с ними придётся мириться так или иначе. Предпочтительно залить кадрами, деньгами и времени а-ля отдельная если не команда, то специалист, для качества и предсказумости начальной разработки и поддержки. На практике, скорее, маны в зубы и пилить в личное время без "код-ревью" или как там процесс называется.
Докер с композом проще гораздо. ) Пока не хайлоад
Однозначно, но лезть в систему лень, чтобы удалить, если можно, и ответить "нет")
Вот только кубер здесь необязательное звено. Нередко только уменьшающее утилизацию и аппаратных и человеческих ресурсов для сценариев типа "поднять 100500 сайтиков на одном хосте".
sudo add-apt-repository ppa:ansible/ansible и ко принимается за правильный ответ? )
docker-compose (вариант docker swarm mode) очень удобны для простого разворачивания а-ля
git pull && docker-compose up. systemd же навскидку вижу несколько вариантов:Как-то все варианты простыми не выглядят.
Может возвращать только нужный стейт, может выполнять только нужные операции, по минимуму переданных данных.
За что? Удобно же. Например, если нам нужен обязательный ответ на то согласен юзер на спам )) или нет
Для меня это всё обычные ошибки. Можно пояснять в теле, что не так или рекомендации какие-то давать. А когда неверный урл, то не то что обычная (пользователь ввёл что-то не то), а критическая или типа того — код неправильно написан.
Дизель вроде выгоднее для такого режима
С 16-го этажа...
Знакомый рассматривает вариант после того, как установил свой дизель-генератор в своём доме как основной источник электричества. По предварительным расчётам вроде выходит, что дешевле и удобнее время от времени завозить соляру и от неё заряжать условный лиф, чем заправлять его бензином постоянно и на сторонних платных "зарядках" заряжать.
Вроде про КПД речь шла, а не про расход заряда? Если на горку что-то поднимать, то работы больше нужно совершать исходя из физики, в которой вечный двигатель невозможен. А КПД тут только если двигатель/источник энергии в горку работает неоптимально, на сколько-то джоулей полезной работы тратит больше квт-ч час чем на ту же работу на ровном месте.
Очень много про передачу представлений состояний) Почти ничего про операции, отличные от HTTP методов.
А вы своё время за рулём автомобиля по какому рейту считаете?
Как по мне, то гораздо чаще не исполняются правила, за нарушение которых ответственности нет или она путяковая или крайне маловероятная.
Вот не понимаю я этого максимализма "раз связались с докер, то нужно идти до конца и деплоиться в куб". Ладно когда стоят задачи масштабирования, отказоустойчивости, абстрагирования от чего угодно и бизнес готов за это платить и за железо, и администратрам (своим, аутсорсу или облака — не суть), и разработчикам (если хоть немного разделяем девопс). Но когда докер вводится в проект исключительно или почти исключительно как продвинутый chroot, то зачем туда всё это?
Так может слать с клиента на сервер тьюринг-полный байт-код, чтоб он исполнялся там?
Пост в целом в контексте REST воспринимеатся, а это оперирование представлениями, а не RPC
Вы хотели сказать (0, 2^53 — 1) чтобы влезал в JS и прочие языки и платформы, где и целых-то толком нет?