Да, я понимаю вас. Телеметрия так или иначе собирается со всего сейчас, чем вы пользуетесь — от вагона метро до приложений. Мы за этичность, то есть обезличенность и отсутствие любого злонамеренного использования. Но при этом мы считаем нормальным обезличенно (и агрегированно) собирать те же ситуации, приводящие к ошибкам или задержкам, что является абсолютно общепринятой практикой. Можем ли не собирать? Да, и в беклоге сделать этот функционал отключаемым, как я уже сказал выше.
Что касается cookie и разнообразных трекеров, я еще понимаю: зло в них в том, что они отслеживают активность за пределами отдельно взятого сайта. Но что плохого сделала пользователю продуктовая аналитика на конкретном ресурсе? От того, что разработчик лучше поймет, как используется его продукт, кому это вред наносит и какой?
Вас смущает, что данные о вашем взаимодействии с продуктом собирают разработчики этого продукта?
В планах глобальный выпуск, там будет соблюдение требований по передающимся данным с возможностью выбирать, что именно о пользователе собирается. В России пока достаточно написать «мы собираем куки».
Мы рассмотрим инференс чужих моделей и продажу токенов, если это будет востребовано, но пока у нас уже заезжают крупные заказчики и всё-таки фокус на том, чтобы дать им инфраструктуру как сервис.
Мы вроде бы о том-же говорим: вместо множества середнячков — энное число профи.
Там, где два сильных специалиста могут закрыть функционал службы из десятка средних — какой же тут риск все уронить? Наоборот, каждый из таких сотрудников знает, что делать и как это делать профессионально.
На то мы и предупреждаем везде, что это бета и что-то может пойти не так. Конкретно в этом случае были потери на стороне оператора связи, не все вызовы сервиса завершались вовремя, и, как следствие, вылезала ошибка, которую Next.JS переварить не мог. Мы это сразу увидели в мониторинге и оперативно пофиксили.
Пилить фичи в прод без тестов — это слабоумие. Среды dev/test/stage/prod — это база. Конечно, мы тестим всё дважды, в т. ч. на стейдже непосредственно перед выкаткой. И вайбкодинг тут ни при чём.
Ваш посыл ясен, сами задрали планку так высоко. Обещали качественный сервис — предоставляйте. В целом, пока с этим все норм. Клиентские ресурсы ситуация не затронула.
Боже упаси! Для создания ВМ надо указать SSH-ключ, иначе это будет чемодан не просто без ручки, но и без защелок — ни достать, ни положить. Профиль сейчас пилим, а для связи почта и TG.
Мы так и сделали, мы любим Nag. И много у них берем. Но именно таких патч-кордов в Москве на складе не было, отсюда СДЭК и всё вытекающее.
Нет. Как и про белорусов с казахами. Просто вежливо послали.
Мы для скорости можем и от физ.лица с возмещением через авансовый отчет, много таких моментов бывает. Проблем именно в том, что их нет!
Спасибо, исправил.
Да, я понимаю вас. Телеметрия так или иначе собирается со всего сейчас, чем вы пользуетесь — от вагона метро до приложений. Мы за этичность, то есть обезличенность и отсутствие любого злонамеренного использования. Но при этом мы считаем нормальным обезличенно (и агрегированно) собирать те же ситуации, приводящие к ошибкам или задержкам, что является абсолютно общепринятой практикой. Можем ли не собирать? Да, и в беклоге сделать этот функционал отключаемым, как я уже сказал выше.
Раздел Pricing на сайте Matomo ответит на этот вопрос: всё кроме базовых фич стоит денег. Например, Session recording — от 219 € в год.
Что касается cookie и разнообразных трекеров, я еще понимаю: зло в них в том, что они отслеживают активность за пределами отдельно взятого сайта. Но что плохого сделала пользователю продуктовая аналитика на конкретном ресурсе? От того, что разработчик лучше поймет, как используется его продукт, кому это вред наносит и какой?
Вас смущает, что данные о вашем взаимодействии с продуктом собирают разработчики этого продукта?
В планах глобальный выпуск, там будет соблюдение требований по передающимся данным с возможностью выбирать, что именно о пользователе собирается. В России пока достаточно написать «мы собираем куки».
Мы рассмотрим инференс чужих моделей и продажу токенов, если это будет востребовано, но пока у нас уже заезжают крупные заказчики и всё-таки фокус на том, чтобы дать им инфраструктуру как сервис.
А как вы предлагаете, плодить штат только чтобы распределить знания? Это ж не контейнеры, вроде.
Мы сейчас работаем над двумя сервисами с GPU: VDI и ML-платформа.
Это три автономные эксплуатационные службы, которые обычно разделены. Они существуют у провайдеров помимо техподдержки.
Я ранее рассказывал, почему удаленка — это не наш формат. Да и экономия на офисе мизерная.
Мы вроде бы о том-же говорим: вместо множества середнячков — энное число профи.
Там, где два сильных специалиста могут закрыть функционал службы из десятка средних — какой же тут риск все уронить? Наоборот, каждый из таких сотрудников знает, что делать и как это делать профессионально.
Таковы реалии рынка. Плюс хочется сделать облако так, как надо. А после того, как мы этого добьёмся, думаем, уровень входа в сферу будет ещё выше.
На то мы и предупреждаем везде, что это бета и что-то может пойти не так. Конкретно в этом случае были потери на стороне оператора связи, не все вызовы сервиса завершались вовремя, и, как следствие, вылезала ошибка, которую Next.JS переварить не мог. Мы это сразу увидели в мониторинге и оперативно пофиксили.
Пилить фичи в прод без тестов — это слабоумие. Среды dev/test/stage/prod — это база. Конечно, мы тестим всё дважды, в т. ч. на стейдже непосредственно перед выкаткой. И вайбкодинг тут ни при чём.
Ваш посыл ясен, сами задрали планку так высоко. Обещали качественный сервис — предоставляйте. В целом, пока с этим все норм. Клиентские ресурсы ситуация не затронула.
Возможен конфликт ssh.socket и ssh.service
Посмотреть их статусы: systemctl is-active ssh.service ssh.socket
Самое простое решение (ubuntu):
Отключить ssh.socket сервис — sudo systemctl disable --now ssh.socket
Установить Port для ssh.service — sudo nano /etc/ssh/sshd_config
Перезапустить ssh.service — sudo systemctl restart ssh.service
Новый порт должен быть в логе сервиса — sudo systemctl status ssh.service
Но вы уже знаете что это решение работает, потому что в нашей группе мы с вами решили этот вопрос.
Да, логично, сейчас подсветим.
Мы так не делаем, потому что это не так секьюрно. Как минимум, провайдер знает ваш пароль.
Боже упаси! Для создания ВМ надо указать SSH-ключ, иначе это будет чемодан не просто без ручки, но и без защелок — ни достать, ни положить. Профиль сейчас пилим, а для связи почта и TG.