Про то, что ИБ — это расходные статьи, не генерирующие доход, я с вами абсолютно согласен. И про удельные расходы тоже. О том и статья, что расходы эти неподъемны для МСБ. А вот про потребность уже не соглашусь. Дело в том, что «не понимаю, что мне это нужно» = «на самом деле не нужно». И то, что у малого бизнеса денег меньше не делает потребность меньше, и точно не снижает риски.
Прям сразу что приходит в голову — компания ESET с их антивирусом NOD32, решения Fortinet. А еще Veeam, который вообще изначально был российским. Сюда же добавим ситуацию с CloudFlare. Примеров масса, на самом деле. А вот доступных альтернатив — увы.
Действительно нейронкой быстрее. Но в вашем комментарии я вижу главное заблуждение всех противников вайб-кодинга: будто бы нейронка генерит говнокод. Это уже давно не так.
Если использовать LLM не для вайб-кодинга, а как партнёра по парному программированию, и сначала детализировать ТЗ, потом добавить это ТЗ в контекст LLM, то это ускоряет Time-to-market. Конечно, если есть такая цель — повысить скорость разработки. Если такой цели нет, например, когда компания не разрабатывает новые продукты и фичи, а просто допиливает продукт, который уже находится в стадии зрелости, то хороший middle или синьор и сам прекрасно справится без LLM (возможно даже и без IDE).
Мне кажется, только ленивый не сравнил ЗП айтишников с курьерами и таксистами, но всё же, в найме (не самозанятость) ставки в IT выше остальных. Если располагаете другой аналитикой, кроме истории про друга-сантехника — давайте вместе ознакомимся.
Да, будет. Приводите своих клиентов. Пока программная механика в разработке — напишите мне на r00t@h3llo.cloud, отметим ваш аккаунт, а в конце месяца сделаем кешбек.
Увы, без «любых сервисов» нет механизма, который бы помешал одному пользователю создавать неограниченное число аккаунтов. И, как показывает практика у коллег, бесплатные ресурсы даже перепродают (это не шутка).
Мы хотим дать попробовать по настоящему мощные серваки и хороший сервис. Не «100 систем на одной задушенной ВМ», где всё трещит и падает, а полноценную инсталляцию в облаке — с надёжностью, резервированием и отказоустойчивостью.
До IPv6 банально еще руки не дошли. Но в целом ничто не мешает нам выделять даже целые подсети — это вполне реализуемо, просто нужно сделать )
Сейчас наша основная задача — отладить стабильную работу сервисов и систем под реальной пользовательской нагрузкой. А дальше мы быстро затащим новые фичи.
Если нужны ресурсы на тест больше, чем наши лимиты — постучитесь на r00t@h3llo.cloud, придумаем что-нибудь. Только сразу кейс опишите, который хотите проверить.
Во всех историях про кубер «зачем» всегда выходит на первое место. И там, где нет нагрузки / отказоустойчивости / автомасштабирования / частого деплоя / команды разработчиков /CI-CD-пайплайна и т. д., явной потребности в кубере нет. Тогда можно докер на виртуалке или тот же L1veStack.
Мы всё же обсуждаем ситуации, когда она есть, но тогда ручками вместо AutoProvisioning — это прям тяжело. Локальные PV — не лучший вариант для продакшена, даже маленького.
Мы запускаем и грохаем свои кластеры так часто, что это не имеет значения)))
А всё о чем вы говорите просится как продолжение статьи, ведь в этой мы говорим как раз о моменте до. До того, как кластер запущен. И после этого момента начинается совсем другая жизнь.
Вопреки мнению многих про низкое качество кода, полученного от LLM еще раз повторю три важных тезиса статьи:
Что попросил, то и получил, поэтому просить нужно правильно. Это вы указали, но поделюсь парой наблюдений:
помогает просить сначала архитектуру, потом пошаговую реализацию компонентов;
помогает просить сначала тесты (и их надо отревьювить самому), а потом имплементацию;
помогает после неудачного вывода подправить промпт с учетом особенностей, в которых нейронка лажает.
Необходимость ручного ревью никто не отменял, именно в понимании того, какое должно быть решение. В многократном ревью, чтобы код стал как будто своим, и лежит вопрос качества.
Владеть кодом (пусть и сгенерированным) — критически важно. Это буквально знать его и понимать, как он работает.
В целом, практика такая: если сеть не справилась с чем-то, можно либо уточнить задание по разработке компонента (тут все сильно пляшет по архитектуре) либо попросить с нуля, и, возможно — другую сеть.
Про то, что ИБ — это расходные статьи, не генерирующие доход, я с вами абсолютно согласен. И про удельные расходы тоже. О том и статья, что расходы эти неподъемны для МСБ. А вот про потребность уже не соглашусь. Дело в том, что «не понимаю, что мне это нужно» = «на самом деле не нужно». И то, что у малого бизнеса денег меньше не делает потребность меньше, и точно не снижает риски.
Прям сразу что приходит в голову — компания ESET с их антивирусом NOD32, решения Fortinet. А еще Veeam, который вообще изначально был российским. Сюда же добавим ситуацию с CloudFlare. Примеров масса, на самом деле. А вот доступных альтернатив — увы.
Я сам офигел, когда услышал, но раскрывать источник внутри будет неправильно.
Судя по сообщению, вы пытаетесь отправить запрос больше, чем предусмотрено бесплатным планом.
Cline.
Действительно нейронкой быстрее. Но в вашем комментарии я вижу главное заблуждение всех противников вайб-кодинга: будто бы нейронка генерит говнокод. Это уже давно не так.
Если использовать LLM не для вайб-кодинга, а как партнёра по парному программированию, и сначала детализировать ТЗ, потом добавить это ТЗ в контекст LLM, то это ускоряет Time-to-market. Конечно, если есть такая цель — повысить скорость разработки. Если такой цели нет, например, когда компания не разрабатывает новые продукты и фичи, а просто допиливает продукт, который уже находится в стадии зрелости, то хороший middle или синьор и сам прекрасно справится без LLM (возможно даже и без IDE).
Тут ссылка на детали.
Мне кажется, только ленивый не сравнил ЗП айтишников с курьерами и таксистами, но всё же, в найме (не самозанятость) ставки в IT выше остальных. Если располагаете другой аналитикой, кроме истории про друга-сантехника — давайте вместе ознакомимся.
OpenRouter.
У нас и без VPN работает всё что нужно.
Да, будет. Приводите своих клиентов. Пока программная механика в разработке — напишите мне на r00t@h3llo.cloud, отметим ваш аккаунт, а в конце месяца сделаем кешбек.
Увы, без «любых сервисов» нет механизма, который бы помешал одному пользователю создавать неограниченное число аккаунтов. И, как показывает практика у коллег, бесплатные ресурсы даже перепродают (это не шутка).
Мы хотим дать попробовать по настоящему мощные серваки и хороший сервис. Не «100 систем на одной задушенной ВМ», где всё трещит и падает, а полноценную инсталляцию в облаке — с надёжностью, резервированием и отказоустойчивостью.
До IPv6 банально еще руки не дошли. Но в целом ничто не мешает нам выделять даже целые подсети — это вполне реализуемо, просто нужно сделать )
Сейчас наша основная задача — отладить стабильную работу сервисов и систем под реальной пользовательской нагрузкой. А дальше мы быстро затащим новые фичи.
Ну не совсем. Вы из уравнения выкинули LoadBalancer, Managed Postgres (2 vCPU, 4GB) и Object Storage.
Деньги со счета можно будет потратить на любые сервисы.
IPv6 — в ближайших планах.
Получится, если настраивать кластер вручную.
Если нужны ресурсы на тест больше, чем наши лимиты — постучитесь на r00t@h3llo.cloud, придумаем что-нибудь. Только сразу кейс опишите, который хотите проверить.
А что вы собираетесь делать, чтобы вас заблокировали?
Во всех историях про кубер «зачем» всегда выходит на первое место. И там, где нет нагрузки / отказоустойчивости / автомасштабирования / частого деплоя / команды разработчиков /CI-CD-пайплайна и т. д., явной потребности в кубере нет. Тогда можно докер на виртуалке или тот же L1veStack.
Мы всё же обсуждаем ситуации, когда она есть, но тогда ручками вместо AutoProvisioning — это прям тяжело. Локальные PV — не лучший вариант для продакшена, даже маленького.
Все от кейса зависит. Часто CA делается на год.
Вообще ротация сертификатов это отдельная тема. Как и любой пункт статьи — можно прям копать вглубь на целую книгу.
Мы запускаем и грохаем свои кластеры так часто, что это не имеет значения)))
А всё о чем вы говорите просится как продолжение статьи, ведь в этой мы говорим как раз о моменте до. До того, как кластер запущен. И после этого момента начинается совсем другая жизнь.
Вопреки мнению многих про низкое качество кода, полученного от LLM еще раз повторю три важных тезиса статьи:
Что попросил, то и получил, поэтому просить нужно правильно. Это вы указали, но поделюсь парой наблюдений:
помогает просить сначала архитектуру, потом пошаговую реализацию компонентов;
помогает просить сначала тесты (и их надо отревьювить самому), а потом имплементацию;
помогает после неудачного вывода подправить промпт с учетом особенностей, в которых нейронка лажает.
Необходимость ручного ревью никто не отменял, именно в понимании того, какое должно быть решение. В многократном ревью, чтобы код стал как будто своим, и лежит вопрос качества.
Владеть кодом (пусть и сгенерированным) — критически важно. Это буквально знать его и понимать, как он работает.
В целом, практика такая: если сеть не справилась с чем-то, можно либо уточнить задание по разработке компонента (тут все сильно пляшет по архитектуре) либо попросить с нуля, и, возможно — другую сеть.
С задачей написать агента, читающего топик kafka и взаимодействующего с libvirt на уровне сокетов они тоже справляются.