Ладно, не важно, мы в каких-то разных мирах живем. Я исключительно как выбор одной из коробок (и для этого табличка выше вполне подходит), вы хотите еще улучать коробки.
> эксплуатацию, поддержку, отлажку
ну, девопсы запустили очередной микросервис, ничего особенного
> поиск ошибок и повышение качества на нужных доменах
вот этим "прикладники" как раз редко занимаются: либо считается, что работает, либо выбирают другое решение, либо вообще отключают функционал.
я правильно понимаю, что Yandex/Сбер/Т сервисы позволяют себя дообучать? Если да, то не знал, может быть даже интересно на свой голос и лексикон дообучить.
Я может что-то не понимаю, но зачем исправлять ошибки и тренировать рекурентную модель? Я думал, что датасет (звуковые файлы) скрамливается этому приложению, текст на выходе сверяется с ожидаемым и формируется циферка для таблички.
Зачем сравнивать? Чтобы показать, все то, что описано выше (Галлюцинации, translatese, ...) в каких-то цифрах. Тогда проще принимать решение какое решение использовать: сойдет качество на бесплатном ПО или лучше доплатить и получить лучше качество.
Конечно, статье уже год, но добавлю свои 5 копеек, т.к. она гуглится и прочее:
Как сервер до сих пор использовать на практике не возможно, т.к. нет клиентов к Redis, Postgres и тем более к другим сетевым БД. Это печально, но факт. Вроде бы что-то и есть (https://github.com/madhead/kn-redis), но там в репозитарии всего 4 комита 4 года назад, т.е. все-таки самим нужно писать и поддерживать. А уж что проще для БД, чем текстовый протокол Redis.
Конкретно про Kotlin Native бенчмарки не искал, но уже давно были сравнения Java и С++. Да, JVM медленнее стартует, но работает быстро, иногда даже быстрее за счет своих оптимизаций в runtime.
`и для высокопроизводительных задач можно рассматривать сочетание Kotlin Native + Ktor + KStore для хранения данных` -- все-таки KStore для мобилок, локально хранить данные на сервере странно, т.к. непонятно что делать с бекапами, масштабированием и прочим.
В итоге, Kotlin Native перспективен для консольных утилит (быстро стартует, нет внешних зависимостей -- примерно как у golang), для слабых устройств (быстро стартует, малый размер, ест мало памяти, легко поставлять(один файл)), для сценариев быстрого масштабирования (типа облачных лямбда-функций), для поставок коммерческих решений (как вариант обфускации кода). Насколько эти перспективы реализованы пока что непонятно: полазил по их сайту, не понял, видимо, нужно отдельно искать, а они, в основном, про мобилки.
Интересно сравнение Kotlin Native с JVM Native -- может Kotlin Native на серверах сейчас вообще не нужен, если он будет хуже (тем более с учетом скудности библиотек)
Тем кросскомпиляции не раскрыта, поэтому скорее ее нет, что хуже, чем golang.
Что имеется в виду? Я же правильно понимаю, что данных для обучения нет, а есть уже готовые "бинарники" модели и код, чтобы их запускать?
Может быть лучше было бы, если бы вообще не выкладывали -- т.к. такая бесплатная версия убивает (не дает появится) действительно открытой версии.
Gemma поставляется с инструментами "ответственного ИИ". Это важно, т.к. открытые модели сложнее контролировать. Инструменты позволяют создавать правила и отлаживать модель.
Непонятно почему открытые модели сложнее контролировать. Потому что код этого контроля обычно не пишут (не открывают)? Или?
Вывод, к сожалению, пока что другой: современный Kubernetes (у всех провайдеров) все еще предоставляется не как чистая услуга, а клиенту нужно иметь своих devops, которые в нем разбираются.
В этом случае, уже часто непонятно зачем брать услугу K8s, а не виртуалки, если все равно есть инженеры которые это поддерживают. Или не так?
Почему сразу изоляция? Нужно продавать не только в России.
Опять же, это постепенное движение. Его нужно делать, а не обсирать любой шаг...
Объясните мне тупому почему сборка серверов должна быть иностранной? А это неплохой кусок маржи сам по себе. На его базе можно и дальше локализовывать производство.
Нет, это как с экологичностью: ее можно увеличить, но 100% вряд ли будет. Все-таки мир уже давно глобален, что-то, но придется докупать у союзных стран.
Замена вендоров готовых систем (сервера, схд, мфу) -- шаг вперед, но, понятно, не полный. Далее нужно переходить и на собственную компонентную базу.
При этом банк готов поддержать подобные решения, если они будут подходить под заявленные требования.
А вот эта фраза действительно несколько огорчает. Основное заявленное требование хотя бы для критичных систем должно быть российское производство, а остальное уже под это подстраивается, а не наоборот... Так можно реально доиграться
Надеюсь, хотя бы на наш софт полностью перейдут -- уже хоть какая-то возможность бороться с рисками и проблемами. И не к 2030 году...
Что работает? Да, я написал, что в маке Ранчер и эту новую штуку можно использовать через консоль. Как поставить докер-совместимое окружение (чтобы была команда docker), но без лицензионного ограничения docker desktop через консоль без gui приложения в маке не знаю. Знаете — поделитесь.
В целом, я поддерживаю стремление к простоте. И от JEE на Rails переходил, и на Golang программировал, и на Python FastAPI.
При этом у меня немного другой приоритет: не простота всего приложения в целом, а именно кода, который читает и пишет программист. Без относительно того сколько кода написано в библиотеках и фреймворках. Важно, чтобы минимальное время тратилось на технологический код и максимальное на бизнес-код.
С этой точки зрения представленный шаблон во многом закрывает технологические аспекты и направляет как писать бизнес-код. Как по мне, получается весьма хорошо.
При этом, вполне возможно, есть подходы и лучше. Чтобы собрать обратную связь это и публиковалось. Например, тот же Ktor предлагается несколькими людьми. Но у меня с ним опыта нет, а замена Spring -- это практически весь шаблон переделать. Если мы при этом ничего не потеряем (читаемость и кол-во кода приложения и всю дополнительную функциональность, которая уже заложена в шаблоне), а только приобретем более быстрый старт и меньший размер на диске и в памяти -- я двумя руками "За". Но хотелось бы такое увидеть не от неофита в Ktor фреймворке и его окружении (меня), а от человека, который это уже использует года, т.к. наверняка есть моменты в конфигурации и лучших практиках, которые можно показать в шаблоне. Если же это окажется примерно то же самое или хуже, то переходить нет смысла.
В итоге, в любом случае нужно будет как-нибудь посмотреть что-то подобное на Ktor, чтобы понять оно лучше или хуже.
Не, вы не так поняли. Docker Desktop стал платным (с условиями, но все же). Поэтому народ, кого это затронуло, начал массово ставить Rancher Desktop. RH посмотрел на это и выпустил свой.
Все, что вы перечислили, это не основной функционал (который для пользователей именно чистый Docker в большинстве случаев), а что-то вроде триала, чтобы больше людей познакомились с RH версией Кубернетеса. Та же схема, что и в Rancher Desktop.
Вводя понятие основной проекции переизобретается велосипед снапшот - это построенный по первым N ивентам слепок агрегата. Тогда если в команде нужен агрегат, он строится не по всем ивентам, а начиная с N+1. Если снапшот обновлять после каждого нового ивента, то получится ровно то, что в статье называется основной проекцией.
Все-таки снапшот -- это обычно тоже событие. Соответственно, он сокращает количество проигрываемых событий при построении агрегата. Это же проекция, но с необходимой полнотой данных, чтобы не нужно было отдельно строить агрегат, и с единой транзакцией с событием, которая исключает eventual consistency.
Кстати снапшот никак не влияет на eventual consistency. Не важно, строится в команде агрегат по всём ивентам с первого или с N+1, всё равно между добавлением ивентов в ивент стор и обновлением проекций для чтения будет лаг.
Да, классический снапшот никак не влияет, но основная проекция -- не снапшот (в классическом смысле). Идет 1 транзакция на БД с созданием события и обновлением основной ("встроенная" даже более точное определение) проекции, так что это уже никак не отличается по консистентности от обычных (не event sourcing) систем.
Опять же, я не считаю это каким-то своим изобретением -- нечто подобное наверняка есть и у других. Моя роль скорее подсветить этот вариант и показать пример реализации.
Ладно, не важно, мы в каких-то разных мирах живем. Я исключительно как выбор одной из коробок (и для этого табличка выше вполне подходит), вы хотите еще улучать коробки.
> эксплуатацию, поддержку, отлажку
ну, девопсы запустили очередной микросервис, ничего особенного
> поиск ошибок и повышение качества на нужных доменах
вот этим "прикладники" как раз редко занимаются: либо считается, что работает, либо выбирают другое решение, либо вообще отключают функционал.
я правильно понимаю, что Yandex/Сбер/Т сервисы позволяют себя дообучать? Если да, то не знал, может быть даже интересно на свой голос и лексикон дообучить.
Я может что-то не понимаю, но зачем исправлять ошибки и тренировать рекурентную модель? Я думал, что датасет (звуковые файлы) скрамливается этому приложению, текст на выходе сверяется с ожидаемым и формируется циферка для таблички.
Зачем сравнивать? Чтобы показать, все то, что описано выше (Галлюцинации, translatese, ...) в каких-то цифрах. Тогда проще принимать решение какое решение использовать: сойдет качество на бесплатном ПО или лучше доплатить и получить лучше качество.
https://github.com/ggerganov/whisper.cpp
Было бы интересно сравнить с https://github.com/openai/whisper -- как бесплатной базы.
Спасибо за статью, было интересно.
У меня примерно то же самое, только только NextCloud и планшет Apple.
Единственно, Apple совместимые метки, как по мне, недорого и получше (все-таки iPhone'ов побольше, чем Samsung в среднем по больнице).
Конечно, статье уже год, но добавлю свои 5 копеек, т.к. она гуглится и прочее:
Как сервер до сих пор использовать на практике не возможно, т.к. нет клиентов к Redis, Postgres и тем более к другим сетевым БД. Это печально, но факт. Вроде бы что-то и есть (https://github.com/madhead/kn-redis), но там в репозитарии всего 4 комита 4 года назад, т.е. все-таки самим нужно писать и поддерживать. А уж что проще для БД, чем текстовый протокол Redis.
Конкретно про Kotlin Native бенчмарки не искал, но уже давно были сравнения Java и С++. Да, JVM медленнее стартует, но работает быстро, иногда даже быстрее за счет своих оптимизаций в runtime.
`и для высокопроизводительных задач можно рассматривать сочетание Kotlin Native + Ktor + KStore для хранения данных` -- все-таки KStore для мобилок, локально хранить данные на сервере странно, т.к. непонятно что делать с бекапами, масштабированием и прочим.
В итоге, Kotlin Native перспективен для консольных утилит (быстро стартует, нет внешних зависимостей -- примерно как у golang), для слабых устройств (быстро стартует, малый размер, ест мало памяти, легко поставлять(один файл)), для сценариев быстрого масштабирования (типа облачных лямбда-функций), для поставок коммерческих решений (как вариант обфускации кода). Насколько эти перспективы реализованы пока что непонятно: полазил по их сайту, не понял, видимо, нужно отдельно искать, а они, в основном, про мобилки.
Интересно сравнение Kotlin Native с JVM Native -- может Kotlin Native на серверах сейчас вообще не нужен, если он будет хуже (тем более с учетом скудности библиотек)
Тем кросскомпиляции не раскрыта, поэтому скорее ее нет, что хуже, чем golang.
Что имеется в виду? Я же правильно понимаю, что данных для обучения нет, а есть уже готовые "бинарники" модели и код, чтобы их запускать?
Может быть лучше было бы, если бы вообще не выкладывали -- т.к. такая бесплатная версия убивает (не дает появится) действительно открытой версии.
Непонятно почему открытые модели сложнее контролировать. Потому что код этого контроля обычно не пишут (не открывают)? Или?
Вывод, к сожалению, пока что другой: современный Kubernetes (у всех провайдеров) все еще предоставляется не как чистая услуга, а клиенту нужно иметь своих devops, которые в нем разбираются.
В этом случае, уже часто непонятно зачем брать услугу K8s, а не виртуалки, если все равно есть инженеры которые это поддерживают. Или не так?
Почему сразу изоляция? Нужно продавать не только в России.
Опять же, это постепенное движение. Его нужно делать, а не обсирать любой шаг...
Объясните мне тупому почему сборка серверов должна быть иностранной? А это неплохой кусок маржи сам по себе. На его базе можно и дальше локализовывать производство.
Т.е. предлагается лечь в гроб и ничего не делать? В чем конструктив в текущей ситуации, а не про прошлое?
Согласен, что все далеко не хорошо, но это не значит, что любые шаги в правильном направлении нужно объявлять попилом бюджетов.
Надо все закупать. И то, и то.
И радоваться, когда есть прогресс.
При этом тоже огорчаюсь, что он слишком медленный, но я просто сторонний наблюдатель.
Не производится. И мне это тоже не нравится -- об этом мой абзац про огорчает.
При этом закупка серверов российской сборки увеличивает локализацию. Это не что-то итоговое, но шаг в правильном направлении.
да, главное, что российский. Падение раз в час можно купировать и на программном уровне. Полное отключение работы (и внезапное) гораздо хуже.
Нет, это как с экологичностью: ее можно увеличить, но 100% вряд ли будет. Все-таки мир уже давно глобален, что-то, но придется докупать у союзных стран.
Замена вендоров готовых систем (сервера, схд, мфу) -- шаг вперед, но, понятно, не полный. Далее нужно переходить и на собственную компонентную базу.
А вот эта фраза действительно несколько огорчает. Основное заявленное требование хотя бы для критичных систем должно быть российское производство, а остальное уже под это подстраивается, а не наоборот... Так можно реально доиграться
Надеюсь, хотя бы на наш софт полностью перейдут -- уже хоть какая-то возможность бороться с рисками и проблемами. И не к 2030 году...
Так или иначе пропагандировать бесплатно работать неделю неправильно. Даже если люди от отчаяния на это соглашаются.
Что работает? Да, я написал, что в маке Ранчер и эту новую штуку можно использовать через консоль. Как поставить докер-совместимое окружение (чтобы была команда docker), но без лицензионного ограничения docker desktop через консоль без gui приложения в маке не знаю. Знаете — поделитесь.
В целом, я поддерживаю стремление к простоте. И от JEE на Rails переходил, и на Golang программировал, и на Python FastAPI.
При этом у меня немного другой приоритет: не простота всего приложения в целом, а именно кода, который читает и пишет программист. Без относительно того сколько кода написано в библиотеках и фреймворках. Важно, чтобы минимальное время тратилось на технологический код и максимальное на бизнес-код.
С этой точки зрения представленный шаблон во многом закрывает технологические аспекты и направляет как писать бизнес-код. Как по мне, получается весьма хорошо.
При этом, вполне возможно, есть подходы и лучше. Чтобы собрать обратную связь это и публиковалось. Например, тот же Ktor предлагается несколькими людьми. Но у меня с ним опыта нет, а замена Spring -- это практически весь шаблон переделать. Если мы при этом ничего не потеряем (читаемость и кол-во кода приложения и всю дополнительную функциональность, которая уже заложена в шаблоне), а только приобретем более быстрый старт и меньший размер на диске и в памяти -- я двумя руками "За". Но хотелось бы такое увидеть не от неофита в Ktor фреймворке и его окружении (меня), а от человека, который это уже использует года, т.к. наверняка есть моменты в конфигурации и лучших практиках, которые можно показать в шаблоне. Если же это окажется примерно то же самое или хуже, то переходить нет смысла.
В итоге, в любом случае нужно будет как-нибудь посмотреть что-то подобное на Ktor, чтобы понять оно лучше или хуже.
Не, вы не так поняли. Docker Desktop стал платным (с условиями, но все же). Поэтому народ, кого это затронуло, начал массово ставить Rancher Desktop. RH посмотрел на это и выпустил свой.
Все, что вы перечислили, это не основной функционал (который для пользователей именно чистый Docker в большинстве случаев), а что-то вроде триала, чтобы больше людей познакомились с RH версией Кубернетеса. Та же схема, что и в Rancher Desktop.
Это прежде всего для macOS и Windows: чтобы там локально запускать Docker (в том числе и через консоль). Для Linux да, особо не нужно.
Спасибо за комментарий)
Все-таки снапшот -- это обычно тоже событие. Соответственно, он сокращает количество проигрываемых событий при построении агрегата. Это же проекция, но с необходимой полнотой данных, чтобы не нужно было отдельно строить агрегат, и с единой транзакцией с событием, которая исключает eventual consistency.
Да, классический снапшот никак не влияет, но основная проекция -- не снапшот (в классическом смысле). Идет 1 транзакция на БД с созданием события и обновлением основной ("встроенная" даже более точное определение) проекции, так что это уже никак не отличается по консистентности от обычных (не event sourcing) систем.
Опять же, я не считаю это каким-то своим изобретением -- нечто подобное наверняка есть и у других. Моя роль скорее подсветить этот вариант и показать пример реализации.