Антон Шаманов, что такого в Landrover, чего нет в УАЗ? Вот только Landrover банально удобнее и комфортнее.
Ещё раз: SOAP - это не самая плохая вещь, просто ничего космического при куче очевидных недостатков, первый из которых - многоэтажный XML с неймспейсами - бездарное решение в эпоху моды на XML в каждом отверстии.
Валентин, мейнтейнеры тоже все хотят чтобы ты клал какие-то файлы в хитромудрые места, причём у каждого дистрибутива и мейнтейнера свои воззрения на этот счёт. Поддерживать пакетную базу любого дистрибутива в консистентном состоянии само по себе адский труд, именно поэтому уже давно есть ppa (с кучей проблем). snap - это компромисс между Windows-way с раскидыванием непойми каких файлов непойми куда и упорядоченной установкой софта в предсказуемое место. Прекрасный компромисс, на самом деле, если не злоупотреблять, как, например, yq - snap на 7 Мб для написанной на go утилитки (то есть реально это один бинарник!).
Антон Шаманов, ну у нас в платформе WS называются исключительно SOAP-сервисы, я по привычке.
Мне не нравится что уже никому не нужные отмирающие понты из начала нулевых выдают за что-то невероятное. Это в целом приемлемый метод взаимодействия, даже не самый плохой, но его время безнадёжно ушло. В конце концов, в наше время можно и на коболе писать программы, никто не мешает, они даже работать будут, но смысл?
Отставание - это когда новый функционал добавляется в собственный протокол, но в версию протокола на базе SOAP не добавляется.
Антон Шаманов, я не визитками занимаюсь, у нас основные клиенты - банки. У нас для некоторых сервисов есть WS-интеграции, но исключительно по причине наличия таких клиентов, и эти интеграции по функционалу регулярно отстают других протоколов. А для некоторых сервисов никто WS не делал и никогда не будет делать. Ибо устаревшая бесполезная хрень, можно просто клиенту говорить "мы это не поддерживаем" и клиент прекрасно это пережёвывает.
Антон Шаманов, я рекомендую вернуться в 2005 год и пострадать там. Протокол был придуман во времена безумной моды на XML в каждое отверстие, в результате каждый реализовывал как левой пятке приспичило, и потребовались годы на то, чтобы SOAP оброс WS-I/WS-A и стал сколько-нибудь универсальным. И то, по любому чиху разваливается.
По моему опыту бизнес намного более охотно реализует интеграции на кастомных вендор-зависимых протоколах либо на промышленно-стандартных, чем на SOAP. А если говорить не о кроваых ынтерпрайзах, то за пределами заумных бизнесов популярность у SOAP вообще ниже плинтуса - его просто никто не использует. Потому что не нужен. Рыночек порешал.
Антон Шаманов, бизнес очень инертен, потому и использует даже совершенно идиотские технологии типа SOAP/WSDL. По факту же разного рода REST и прочие JSON-RPC дают всё то же самое намного проще и удобнее.
Валентин, вот именно, что мейнтейнеры, но фигня в том, что мейнтейнеры уже не могут оперативно собирать весь мыслимый софт. Особенно такой, что нужно вдоль и поперёк перепахивать под требования конкретного дистрибутива. Вон, недавно ряд дистрибутивов прямо отказались поддерживать telegram-desktop.
Поэтому существующая практика, при которой можно по желанию поставить и из snap/flatpak, и из пакетов, и из исходников - она вполне логична. Наличие выбора лучше безальтернативности.
Валентин, как правило, в stable/lts-ветке дистрибутива существенных мажорных обновлений не делают. Мейнтейнер может обновить что угодно, но многие пользователи этого не получат.
Другой вопрос, что многие программы можно собрать в пакеты из более новых исходников самостоятельно без особых проблем, я так делал неоднократно.
Валентин, я тоже с недоумением смотрю, когда в snap тащат простые утилитки, тем более если это статический бинарник, изначально написанный на go. Но всё же есть вполне тяжёлый софт, который может весить очень много сам по себе, и прыгать с бубном ради небольшой доли общих компонентов с учётом всего зоопарка систем смысл действительно спорный. Например, смотрю я тут на snap chromium, где из 320 Мб аж 230 Мб весит usr/lib/chromium-browser, в котором 160 Мб - собственно бинарник браузера, а общие и потенциально общие библиотеки в usr/lib/x86_64-linux-gnu и usr/lib/chromium-browser весят 13 и 59 Мб, и у меня действительно есть понимание, что автором этого поделия проще выпускать один дистрибутив со всем вместе, чем занимайта сопровождением сборки в каждом встречном дистрибутиве каждой из нескольких последних версий. Вот если кто-то захочет chromium в BolgenOS - пусть сам и собирает под свои нужды.
сколько докладов я смотрел везде отказывались о REST API в пользу Graphql
Крайне редко люди делают доклад о том, как они попробовали новую технологию и вообще не стали на неё переходить. Делать из подобных наблюдений выводы - когнитивная ошибка.
