vop

Ну, обычно для таких вещей имеет смысл, основном, ядро. Какое вам нужно, такое ядро и ставьте.

А какая принципиальная разница?

Его надо не удалять, а маскировать: ln -s /dev/null /etc/systemd/network/99-default.link PS А то в один прекрасный день он возникнет при обновлении.

Да, там многое что стало работать не так. У меня повзрывалось много скриптов из-за того, что iptables -F chain ... на несуществующую цепочку перестало возвращать код ошибки. :)

Опенсорс ныне включает настолько разнообразный "жанр" изделий и поделок, начиная от качественных инструментов и заканчивая откровенным говноделом, что пытаться характеризовать его, как единый инструмент немножечко глупо... :)

Да уж, сеть в офисе 192.168.1.0/24 - это ккаккой-та пазор, что ли... :) Переводить офис на другую подсеть, хотя бы начать с установки вторых адресов.

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

Пара комментов: - интернет юрикам биллинг не отрубает по истечению баланса. Решение принимает менеджер при определенном уровне задолженности, прописанной в договоре с учетом выходных дней. - и да, менеджер просматривает результаты работы авто-учетной системы, где ему показывают оплаты, которые "не нашли свои счета". Менеджер помогает системе их найти.

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

Биллингу, естественно, нечего делать с банковским API. Но автоматическое получение банковских выписок через API в бухгалтерский софт через уполномоченные аккаунты уже давно не редкость. Просто делается API между бухгалтерским софтом и биллингом для автоматического проброса платежей. Это информационный API с низким уровнем критичности (т.е. ошибочный платеж запросто убирается из биллинга), что снимает много ручной работы (тот же копи-паст - бухгалтеру и без этого есть чем заняться). В тех случаях, с которыми имел дело я, была сделана сквозная система с автоматический выпиской привязанного к аккаунту счета до оплаты этого счета. Хотя, как по мне, само по себе это криво. Но не от меня зависел выбор алгоритма.

Насколько я помню, есть ограничение на размер кук - до 4k. Это не в nginx, а в протоколе.

Все зависит от того, есть ли API у вашего банка.

Пишут:

В Шенчжене и других китайских городах такие магазинчики стоят давно. Зашел, набрал жрачки/вещей, пошел домой. :) А у японцев стоят кассы самообслуживания, такие же, как и в наших магазинах, с одним отличием - там не надо сканировать товар поштучно. Просто поставил корзинку с товаром, "пупьсь" - на экране список покупок. :)   Немного не так. Смартфон платеж не проводит. Платеж проводит банк и пс. Смартфон собирает список товаров. :) И да, в Украине закон предусматривает электронный чек. В РФ если не ошибаюсь, тоже.

Ну, батенька, вы от жизни отстали. :) Теперь общаются на митингах. А в некоторых случаях и странах - в автозаках .:) :) :)

Хотел вот что еще рассказать, может кто не знает. Если к кассам самообслуживания вроде все давно привыкли, то одна из украинских сетей супермаркетов пошла дальше - где-то год назад они предложили бескассовое обслуживание. Точнее, кассой является ваш собственный смартфон. Вы ходите по магазину, набираете товар, сканируя его в своем приложение, проверяя цены, и на выход к check point, где тем же приложением сканируете qr-код магазина, что делает checkout и оплату в том же телефоне. И все. Кроме грустного дядьки, который, скучая, наблюдает со сторона за этой процедуры, вообще ни с кем не общаешься. Очередь пенсионерок в кассы спокойно обходишь, не теряя времени. PS Это, конечно, не так прикольно, как пиво покупать мордой-лица, но все же.:)

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

Ну вот это я и назвал идеологической ошибкой. :)

А можно и не разрешать, а сделать идеологически правильную схему, сконфигурировать backup radius, настроить server failover, а биллингу оставить биллингово. :)

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

Вы путаете два разных понятия - биллинг в облаке, и биллинг, как SaaS (в т.ч. бесплатный).

Кому доступно? Продавцу? А я про продавца писал. :) А вы про кого подумали? :) :) :) Кстати, телефон не надо разблокировать при оплате до 170 евро, если не ошибаюсь в размере лимита. Его надо просто разбудить, что делается одной рукой. Просто об этом как-то не много написано, и многие, тупо, не в курсе, начинают разблокировать, запускать приложение и т.д. А, кстати, все бонусные карты давно в телефоне.

Главное отличие карты от телефона заключается в том, что карта ВСЕГДА активна для оплаты, а телефон надо разбудить. Ходила история лет 10 назад о том, что какие-то кренделя в транспорте лазили с pos-терминалом и вылавливали карты в карманах и сумках пассажиров. :) Я думаю, что это был чёс конкретный, но факт присутствует. Не главное - в случае карты продавец получает информацию о плательщике. В случае телефона - неперсонализованный токен платежной системы.

Я думаю, что это зависит от того, кто получатель платежа. Если ты деньги даешь массажисту в руки, или сидящей рядом тёте на рецепшене, то ты оплачиваешь услугу и получаешь квитанцию (в любой форме). А вот если массажист наклепал ваучеров, и отдал их в ларёк дяде Ване, то то приобретая ваучер у дяди Вани ты покупаешь у него товар (ведь он услугу не оказывает, и проводит ваучеры у себя, как товар - кто выпускал карты пополнения счета, тот в курсе). Тут примерно та же схема, как по мне. Оплачивая проезд кондуктору, водителю или билетной машине в вагоне - ты оплачиваешь услугу, получая квитанцию. А если оплачиваешь при помощи приложения третьей стороне (банку, платежной системе и т.д,), которая не оказывает услугу, то они тебе выдают электронный документ, являющийся товаром, который в дальнейшем можно применить для оплаты услуги, например, как те же талончики, которые надо было компостировать (а мне мой купленный электронный билет так же надо активировать, нажав на нем же кнопочку, что бы он позеленел, и у него начался отсчет времени действия. Такая система не без проблем. Прикладуха со списком оплат у контролера есть. Он может проверить код оплаты. Правда, не делает этого обычно. Про интерфейс-обманку я тоже думал, пока не увидел у одной блондинки более просто решение. Она просто в графическом редакторе держит изображение электронного билета, вручную забивая туда номер трамвая или автобуса. Но это не надолго, так-как электронный билет все же динамический с часами и истекающими минутами и секундами. Но с оплатами по qr все же есть огромное преимущество - оно не требует никакой дополнительной электроники. В троллейбусе просто наклейки на каждом углу, а у людей - просто смартфоны в руках. Все остальное - программное. Ну и тот, кто не хочет, или нечем - не пользуется. А оплатой картой в висящем терминале с получением SMS etc. мало кто пользуется. Я вообще за три года видел один раз такого. Когда-то в транспорте были компостеры (кое-где есть и сейчас). Я купил пачку талончиков в книжном магазине на кассе. Прошло полтора года, мне талончики попались на глаза и я начал их компостировать при проезде, часть я отдал маме, часть - детям. Вот интересно, что я купил в книжном магазине? :)

Точно, не стоит путать. Метода оплаты только два - наличный и безналичный. Что мы оплачиваем? Мы оплачиваем проезд (собс-на говоря - услугу). Каким путем? Путем приобретения билета, который является в данной сделке товаром. Товар может быть физический (билет, талончик, проездной в бумажном виде), так и в электронной форме (в виде SMS с кодом товара, или специального rich изображения в приложении телефона, как у нас). Какой используем метод оплаты при приобретении товара - правильно, наличный или безналичный (во всех формах, от банковского перевода до погашения ваучера). В СССР электронных товаров не было в виду отсутствия надлежащей технологии. Но при этом, методы оплаты были те же, что и сейчас, правда, в более патриархальных формах.