У меня двоякое ощущение. С одной стороны, автор описал вполне здравый и практичный путь развития AI‑кодинга. Он ничего явно не продаёт: кроме ссылки на свой ТГ - никаких офферов и курсов. Статья в плюсе, тезисы выглядят разумно.
Но при этом почти все комментарии автора под собственной статьёй заминусованы. Такой диссонанс вижу нечасто. Обычно, если подход действительно ошибочный, это видно и в тексте.
Я новичок в теме и пытаюсь разобраться, где здесь подводные камни. В комментариях звучала мысль, что при такой модели разработки экономика может не сходиться: стоимость токенов становится сопоставимой с зарплатами разработчиков. При этом внутренняя экономика OpenAI закрыта, а автор утверждает, что у него расчёты положительные.
Вопрос скорее общий: какие ограничения или слабые места у подобного подхода вы видите на практике? Где он перестаёт работать - по деньгам, по качеству кода, по масштабированию?
Спасибо за сжатый и честный вывод без маркетинговой обертки.
Достоверной информации на эту тему довольно мало. Была вирусная новость про исследование, где несколько топовых моделей торговали на рынке акций. Результаты описывали примерно так: все проиграли, прибыль дал только DeepSeek. Даже не смешно такое читать.
Хотя идея понятна. Любой, кто получает в руки инструмент с претензией на интеллект, первым делом думает: а не заработать ли на бирже? Это инстинктивно. Причем если такие исследования вдруг дадут по-настоящему положительный результат - это должно вызвать огромное беспокойство у всех участников рынка по понятным причинам. Благодаря автору теперь мы знаем, что мир в ближайшее время не рухнет.
Помню, в далеком 1994-м однокурсник на кафедре вычислительной математики МФТИ рассказывал, что они уже тогда натравливали нейросети на предсказание биржевых курсов - и результаты были, по его словам, обнадеживающими. Не знаю были ли тогда российские биржи или смотрели на западные. Нейросети уже были. Исследователи будут всегда.
Web‑клиенты же. Сейчас почти все ВКС позволяют гостям подключаться из браузера по ссылке, без установки своего ПО или спецоборудования.
В статье как раз указано, что к конференциям можно подключаться с телефонов. Логично предположить, что в требованиях был и веб‑доступ, и сценарии с внешними участниками, иначе для экспортной компании это было бы совсем странное решение.
Автору и комментаторам - огромное спасибо, было интересно почитать и про совсем современные, и про совсем «олдскульные» носители в одном контексте. Доступность FDD стала приятным сюрпризом. Статью, кстати, уже сохранил на компьютер (SSD), который бэкапится на NAS (HDD).
Отдельное спасибо автору именно за освещение технологий носителей. Но в комментариях закономерно пошло сравнение уже стратегий хранения с использованием этих носителей. А аккуратно отделить одно от другого, по-хорошему, невозможно: обсуждать «голый» носитель без схемы его применения - это пол картины.
По сути. По-моему, в обсуждении немного смешались три разных вещи:
- Аппаратная надежность самого носителя. - Доступность оборудования для чтения. - Организационные меры, которые обеспечивают надежность хранения.
Упираться только в «супернадежные» носители, не обсуждая организацию хранения, выглядит странно. В итоге все упирается в субъективное понимание достаточной надежности и допустимой сложности, которые у каждого свои:
- для кого-то нормально раз в пару лет мигрировать данные, - кто-то хочет записать и забыть «на 100+ лет».
Но вот вопрос: какой смысл в дисках со сроком жизни 100+ лет, если через эти самые 100 лет, ИМХО, будет огромная проблема считать эти данные?
Постоянно сталкиваюсь с тем, что в области сохранения данных люди подвержены куче когнитивных искажений. Многие системные администраторы уверены, что диски в RAID 5 - это «надежно». Настолько надежно, что критичные данные спокойно хранятся на встроенных дисках серверов без поддержки вендора. И дальше они впадают в ступор на простом вопросе: как ты будешь восстанавливать данные через 5 лет, если сгорит контроллер? Это же какой‑нибудь конкретный LSI, который: быстро не купишь, а через несколько лет можешь не купить вообще. Самые прошаренные говорили: «Мы купили запасной контроллер в холодный резерв». Да, это повышает шансы, но лишь частично. Второй вопрос: а ты слышал про случаи, когда сгоревший контроллер утягивал за собой все данные? Слышал, но стараюсь об этом не думать и у меня есть бэкап на ленты. А когда начинаешь спрашивать про их ленточные библиотеки, тоже выясняется, что там тоже далеко не так радужно.
С любым носителем история примерно одинаковая. Чтобы прочитать данные, нужны:
- привод; - интерфейс для подключения привода; - драйверы к этому железу под доступную в данный момент ОС; - ПО под доступную в данный момент ОС, которое умеет читать данные в нужном формате.
Сложится ли вся эта цепочка через 100 лет? Формально шансы не нулевые. Сейчас все больше «почти вечных» форматов и интерфейсов, но точно расслабляться нельзя.
Поэтому любую стратегию хранения стоит рассматривать только в конкретном временном горизонте. И у каждой такой стратегии будут свои организационные задачи - как минимум, периодически добывать и поддерживать в рабочем состоянии совместимое железо и софт.
Я бы все таки разделил "закрытый" и "надежный" протокол.
Для меня надежный протокол - это тот, который не завязан на одного вендора, предсказуем в поведении и хотя бы теоретически может иметь несколько реализаций. Не так важно, открыт он или нет.
Истории с WebRTC - это не проблема открытости, а проблема того, кто и как рулит изменениями. Закрытый вендор в любой момент может так же спокойно что-нибудь поменять по своим бизнес причинам, и эффект для заказчика будет таким же внезапным.
Сейчас ваша позиция понятна: есть прямой контакт с TrueConf, ресурс влиять на решения, все быстро чинится. В таких условиях собственный протокол правда выглядит надежно (удобно). Вопрос в другом: всегда ли у вас будет такой ресурс, есть ли он у остальных заказчиков и что будет через несколько лет, если приоритеты компании или вендора сменятся. Тут уже начинается классический vendor lock.
При этом я как раз надеюсь, что при выборе архитектурных решений у вас были и другие соображения, а не только связка "надежный = закрытый". В таком проекте масштаба Сибура просто не могло все упираться в один этот критерий.
Спасибо, что поделились опытом! Понятно, что реальных технических задач там было гораздо больше, чем уместилось в статье. Сам факт успешного запуска на таком масштабе говорит, что либо все, либо как минимум ключевые проблемы были решены. И работ там, очевидно, было сильно больше, чем «просто взяли и заменили ВКС».
Решение заходить в доработку TrueConf — явно нетривиальное и, видимо, принималось уже на достаточно высоком уровне. В результате, судя по описанию, получилась система с функциональностью уровня telepresence, которую уже можно всерьёз сравнивать с решениями лидеров рынка — Cisco и Microsoft.
Немного смутили в статье вот эти тезисы:
TrueConf разработал протокол с нуля. Никаких внешних зависимостей. Никто не может его ограничить или остановить.
Это намёк на Роскомнадзор, который может ограничить что угодно, включая то, что изначально и не собирались ограничивать? Иначе непонятно, кто ещё в РФ может «ограничивать протоколы».
При этом новый, уникальный и никому до этого не известный протокол никогда не был техническим препятствием для ограничений со стороны Роскомнадзора или других регуляторов — достаточно заблокировать адреса/диапазоны, и вопрос закрыт. Плюс, если честно, уникальные протоколы — это обычно зло: проблемы совместимости, зависимость от одного вендора и усложнение сопровождения на долгой дистанции.
Второй момент: заявленная поддержка унаследованных устройств с SIP и H.323 немного диссонирует с тезисом про отсутствие внешних зависимостей. Если нужно дружить с классическими протоколами, полной автономности всё равно нет — приходится учитывать чужие стеки и совместимость.
В любом случае, удачи вам! Дальше самое интересное — эксплуатация и эволюция системы под реальные потребности пользователей.
Есть не новая штука: TTS через Microsoft Edge. Есть несколько реализаций. Например: https://github.com/hinaichigo-fox/rus-edge-tts-webui Выглядит так, как будто работает локально, но места занимает всего 450МБ и при работе создает сетевой трафик, а не грузит процессор. Похоже, что у microsoft торчит наружу api, которым научились пользоваться. Аккаунтов вводить не нужно, лимитов не видно, Русским владеет прекрасно.
У меня двоякое ощущение. С одной стороны, автор описал вполне здравый и практичный путь развития AI‑кодинга. Он ничего явно не продаёт: кроме ссылки на свой ТГ - никаких офферов и курсов. Статья в плюсе, тезисы выглядят разумно.
Но при этом почти все комментарии автора под собственной статьёй заминусованы. Такой диссонанс вижу нечасто. Обычно, если подход действительно ошибочный, это видно и в тексте.
Я новичок в теме и пытаюсь разобраться, где здесь подводные камни. В комментариях звучала мысль, что при такой модели разработки экономика может не сходиться: стоимость токенов становится сопоставимой с зарплатами разработчиков. При этом внутренняя экономика OpenAI закрыта, а автор утверждает, что у него расчёты положительные.
Вопрос скорее общий: какие ограничения или слабые места у подобного подхода вы видите на практике? Где он перестаёт работать - по деньгам, по качеству кода, по масштабированию?
Спасибо за сжатый и честный вывод без маркетинговой обертки.
Достоверной информации на эту тему довольно мало. Была вирусная новость про исследование, где несколько топовых моделей торговали на рынке акций. Результаты описывали примерно так: все проиграли, прибыль дал только DeepSeek. Даже не смешно такое читать.
Хотя идея понятна. Любой, кто получает в руки инструмент с претензией на интеллект, первым делом думает: а не заработать ли на бирже? Это инстинктивно. Причем если такие исследования вдруг дадут по-настоящему положительный результат - это должно вызвать огромное беспокойство у всех участников рынка по понятным причинам.
Благодаря автору теперь мы знаем, что мир в ближайшее время не рухнет.
Помню, в далеком 1994-м однокурсник на кафедре вычислительной математики МФТИ рассказывал, что они уже тогда натравливали нейросети на предсказание биржевых курсов - и результаты были, по его словам, обнадеживающими. Не знаю были ли тогда российские биржи или смотрели на западные. Нейросети уже были. Исследователи будут всегда.
Web‑клиенты же. Сейчас почти все ВКС позволяют гостям подключаться из браузера по ссылке, без установки своего ПО или спецоборудования.
В статье как раз указано, что к конференциям можно подключаться с телефонов. Логично предположить, что в требованиях был и веб‑доступ, и сценарии с внешними участниками, иначе для экспортной компании это было бы совсем странное решение.
Автору и комментаторам - огромное спасибо, было интересно почитать и про совсем современные, и про совсем «олдскульные» носители в одном контексте. Доступность FDD стала приятным сюрпризом. Статью, кстати, уже сохранил на компьютер (SSD), который бэкапится на NAS (HDD).
Отдельное спасибо автору именно за освещение технологий носителей. Но в комментариях закономерно пошло сравнение уже стратегий хранения с использованием этих носителей. А аккуратно отделить одно от другого, по-хорошему, невозможно: обсуждать «голый» носитель без схемы его применения - это пол картины.
По сути. По-моему, в обсуждении немного смешались три разных вещи:
- Аппаратная надежность самого носителя.
- Доступность оборудования для чтения.
- Организационные меры, которые обеспечивают надежность хранения.
Упираться только в «супернадежные» носители, не обсуждая организацию хранения, выглядит странно. В итоге все упирается в субъективное понимание достаточной надежности и допустимой сложности, которые у каждого свои:
- для кого-то нормально раз в пару лет мигрировать данные,
- кто-то хочет записать и забыть «на 100+ лет».
Но вот вопрос: какой смысл в дисках со сроком жизни 100+ лет, если через эти самые 100 лет, ИМХО, будет огромная проблема считать эти данные?
Постоянно сталкиваюсь с тем, что в области сохранения данных люди подвержены куче когнитивных искажений. Многие системные администраторы уверены, что диски в RAID 5 - это «надежно». Настолько надежно, что критичные данные спокойно хранятся на встроенных дисках серверов без поддержки вендора. И дальше они впадают в ступор на простом вопросе: как ты будешь восстанавливать данные через 5 лет, если сгорит контроллер? Это же какой‑нибудь конкретный LSI, который: быстро не купишь, а через несколько лет можешь не купить вообще. Самые прошаренные говорили: «Мы купили запасной контроллер в холодный резерв». Да, это повышает шансы, но лишь частично. Второй вопрос: а ты слышал про случаи, когда сгоревший контроллер утягивал за собой все данные? Слышал, но стараюсь об этом не думать и у меня есть бэкап на ленты. А когда начинаешь спрашивать про их ленточные библиотеки, тоже выясняется, что там тоже далеко не так радужно.
С любым носителем история примерно одинаковая. Чтобы прочитать данные, нужны:
- привод;
- интерфейс для подключения привода;
- драйверы к этому железу под доступную в данный момент ОС;
- ПО под доступную в данный момент ОС, которое умеет читать данные в нужном формате.
Сложится ли вся эта цепочка через 100 лет? Формально шансы не нулевые. Сейчас все больше «почти вечных» форматов и интерфейсов, но точно расслабляться нельзя.
Поэтому любую стратегию хранения стоит рассматривать только в конкретном временном горизонте. И у каждой такой стратегии будут свои организационные задачи - как минимум, периодически добывать и поддерживать в рабочем состоянии совместимое железо и софт.
Я бы все таки разделил "закрытый" и "надежный" протокол.
Для меня надежный протокол - это тот, который не завязан на одного вендора, предсказуем в поведении и хотя бы теоретически может иметь несколько реализаций. Не так важно, открыт он или нет.
Истории с WebRTC - это не проблема открытости, а проблема того, кто и как рулит изменениями. Закрытый вендор в любой момент может так же спокойно что-нибудь поменять по своим бизнес причинам, и эффект для заказчика будет таким же внезапным.
Сейчас ваша позиция понятна: есть прямой контакт с TrueConf, ресурс влиять на решения, все быстро чинится. В таких условиях собственный протокол правда выглядит надежно (удобно). Вопрос в другом: всегда ли у вас будет такой ресурс, есть ли он у остальных заказчиков и что будет через несколько лет, если приоритеты компании или вендора сменятся. Тут уже начинается классический vendor lock.
При этом я как раз надеюсь, что при выборе архитектурных решений у вас были и другие соображения, а не только связка "надежный = закрытый". В таком проекте масштаба Сибура просто не могло все упираться в один этот критерий.
Спасибо, что поделились опытом! Понятно, что реальных технических задач там было гораздо больше, чем уместилось в статье. Сам факт успешного запуска на таком масштабе говорит, что либо все, либо как минимум ключевые проблемы были решены. И работ там, очевидно, было сильно больше, чем «просто взяли и заменили ВКС».
Решение заходить в доработку TrueConf — явно нетривиальное и, видимо, принималось уже на достаточно высоком уровне. В результате, судя по описанию, получилась система с функциональностью уровня telepresence, которую уже можно всерьёз сравнивать с решениями лидеров рынка — Cisco и Microsoft.
Немного смутили в статье вот эти тезисы:
Это намёк на Роскомнадзор, который может ограничить что угодно, включая то, что изначально и не собирались ограничивать? Иначе непонятно, кто ещё в РФ может «ограничивать протоколы».
При этом новый, уникальный и никому до этого не известный протокол никогда не был техническим препятствием для ограничений со стороны Роскомнадзора или других регуляторов — достаточно заблокировать адреса/диапазоны, и вопрос закрыт.
Плюс, если честно, уникальные протоколы — это обычно зло: проблемы совместимости, зависимость от одного вендора и усложнение сопровождения на долгой дистанции.
Второй момент: заявленная поддержка унаследованных устройств с SIP и H.323 немного диссонирует с тезисом про отсутствие внешних зависимостей. Если нужно дружить с классическими протоколами, полной автономности всё равно нет — приходится учитывать чужие стеки и совместимость.
В любом случае, удачи вам! Дальше самое интересное — эксплуатация и эволюция системы под реальные потребности пользователей.
Есть не новая штука: TTS через Microsoft Edge. Есть несколько реализаций. Например: https://github.com/hinaichigo-fox/rus-edge-tts-webui
Выглядит так, как будто работает локально, но места занимает всего 450МБ и при работе создает сетевой трафик, а не грузит процессор. Похоже, что у microsoft торчит наружу api, которым научились пользоваться. Аккаунтов вводить не нужно, лимитов не видно, Русским владеет прекрасно.