Я имею в виду бенчмаркинг эффективности анализа логов (насколько с вашим подходом модель чаще/реже корректно определяет проблему по логам, чем если бы ей просто скормить логи). Компрессия input токенов понятна, да.
А у вас есть какие-то бенчмарки эффективности работы с логами, какая методика исследования? Например, можно 100 раз прогнать один и тот же лог в одном формате, посмотреть процент корректно распознанных проблем, и сравнить с таким же процентом, если просто давать сырые логи. Это было бы интересно глянуть, учитывая, что у современных LLM достаточно большой контекст (сотни тысяч-миллионы токенов), и они и так должны были бы неплохо справляться с такими задачами.
Спасибо за статью. Такой вопрос по site based tunneling: он же не заворачивает весь трафик с сайта, а просто роутит по IP/SNI/Host, верно? Что мешает условному max.ru проверить доступность зарубежных сервисов через fetch в no-cors режиме или ещё как-то? Например, вы добавили telegram.org в список сайтов, которые должны идти через прокси. Тогда любое приложение (и даже сайты?) могут увидеть, что telegram.org доступен, хотя он явно не должен быть доступен.
Плюс с таким подходом есть проблема: шпионскому приложению достаточно на любом из распространенных сайтов, которые обычно добавляют в список проксирования (Telegram, ChatGPT, Discord, ...) найти внутреннюю ручку или уязвимость, которая раскрывает IP.
Поэтому явно безопаснее/интереснее было бы посмотреть на обзор решений с per browser tab / per desktop app routing.
Зачем использовать позднее связывание, если, как вы говорите, нейронки в это не умеют без дополнительных настроек? Понимаю, что хочется иметь свой личный стиль во всех проектах, но в эпоху ИИ как минимум имеет смысл ревьюить свой стиль кода на наличие паттернов, которые на ровном месте ухудшают эффективность ИИ (больший шанс, что нейронка налажает в этом коде, так как такого кода нет/мало в данных обучения модели; больше токенов на то, чтобы прочитать скилл и держать его в контексте, что тоже влияет на дороговизну разработки и на качество, если контекст у вас забит не реально нужными знаниями о проекте, а формальностями, которые можно опустить).
Вы пишите, что размер спецификаций у вас превышает размер кода в несколько раз, и это ожидаемое поведение. Почему вы так считаете? Как будто весь смысл в том, что снижается сложность реализации проектов с нуля, что достаточно написать относительно короткую спеку, а нейронка ее заимплементит, вместо того, чтобы самому писать десятки тысяч строк кода. Возможно, проблема в том, что спека у вас тоже сгенерирована ИИ и поэтому она размытая и такая большая.
Это тоже не панацея. Во-первых факт обхода блокировки все равно будет виден (скам может сделать запрос к telegram.org и увидеть, что он доступен).
Во-вторых, цензору даже необязательно покупать свой сервер за рубежом для этого. Достаточно найти в любом сервисе из вашего белого списка (Telegram, Discord, ChatGPT, всякие зарубежные CDN и так далее) один скрытый пусть даже сервисный или не предназначенный для публичного использования endpoint, который отдает ваш IP — и все.
И не получится гарантировать, что сервисы в вашем белом списке никаким образом не могут спалить ваш IP самостоятельно.
В целом не очень понятно, как оценить "продуктивность" или даже просто рост числа проектов, связанных с ИИ.
Упрощает ли ИИ разработку каких-то простых личных программ для не-разработчиков? Безусловно. Только эти люди скорее всего даже не будут пользоваться GitHub, поэтому непонятно, как включить их в статистику.
А метод анализа на основе числа пакетов PyPI вообще странный. Очевидно же, что большинство новых проектов, созданных ИИ — это какие-то личные или рабочие проекты, там сайты, телеграм-боты, но уж точно не пакеты.
Есть как минимум 2 (https://github.com/loyldg/mytelegram, https://github.com/teamgram/teamgram-server), но они урезанные и их полные версии продаются за десятки тысяч долларов.
Вполне возможно, что с сегодняшними возможностями вайбкодинга и spec-driven development проще навайбкодить свой собственный бекенд, благо вся необходимая документация и референсные реализации клиентской части есть. Как интересный эксперимент.
Как обсуждали в предыдущей статье автора, приватные поля можно было получить и раньше через замыкания (хотя и не стоит использовать такой подход, потому что это ломает оптимизации движков).
Вообще глубоко убежден, что private поля были ошибкой. На практике нередко случается, например, что вам нужно какое-то поле в классе из библиотеки, а разработчик библиотеки подумал, что он лучше всех знает ООП не подумал о такой возможности и сделал его приватным. Это сильно ухудшает гибкость для сторонних разработчиков. В большинстве языков это нерешаемая проблема, приходится делать форк и поддерживать его в актуальном состоянии. В TS например действительно кейворд private ни на что не влияет в рантайме, что позволяет обойти его через приведение типов, если очень-очень нужно. Чего не скажешь про "#name" поля в JS.
Зачем делать альтернативный клиент, если тврщ майор все равно будет иметь доступ к любым коммуникациям внутри Max? Если беспокоитесь за слив данных с устройства (фотографии, установленные приложения и другие подозрительные разрешения), проще купить отдельный телефон или, ещё проще, поставить Max в полностью изолированный Workspace. Это можно сделать на Android через приложение Island.
Что любопытно, так это то, что десктопный клиент Аськи (ICQ New, пока ее не убили, от MailRu), был форком Telegram Desktop. И работало, и выглядело очень неплохо.
А это вообще смех какой-то, "нативное приложение" на Electron. Кстати, статьи за дискредитацию мессенджера Max ещё не завезли? 😁
Помню, что ещё совсем недавно Google Play требовал очень строгого обоснования этого разрешения. Вряд ли его смогли добавить просто так, скорее всего какой-то функционал, хотя бы ради прохождения ревью они сделали. Или Google уже забил?
Если он уже скачал данные (то есть эксплуатировал найденную уязвимость), нет, в лучшем случае его бы просто поблагодарили и лишили bounty, в худшем - засудили.
Последнее, что мы исправим, — использовать COPY вместо ADD. Оба почти одинаковы, но COPY более точный.
Дело в не том, что он "более точный". ADD содержит магию - возможность добавлять в образ файлы по URL и разархивировать tar архивы, что может привести к неожиданному поведению. Поэтому рекомендуют, если возможно, использовать COPY.
У меня есть подозрение, что статистика может быть некорректной. Судя по названию таблицы, которое включает слово cache, вероятнее всего, это кеш всех проигранных треков за время, которое приложение Яндекс Музыки было установлено на вашем смартфоне. А значит, скорее всего, некоторая часть кеша образовалась ДО того, как Яндекс поддержал loseless формат, и данные о качестве там, соответственно, старые.
Для чистоты эксперимента было бы здорово удалить приложение и снести все его данные, а после установить заново и сравнить результаты, чтобы убедиться, что статистику не испортил старый кеш.
Я имею в виду бенчмаркинг эффективности анализа логов (насколько с вашим подходом модель чаще/реже корректно определяет проблему по логам, чем если бы ей просто скормить логи). Компрессия input токенов понятна, да.
А у вас есть какие-то бенчмарки эффективности работы с логами, какая методика исследования? Например, можно 100 раз прогнать один и тот же лог в одном формате, посмотреть процент корректно распознанных проблем, и сравнить с таким же процентом, если просто давать сырые логи. Это было бы интересно глянуть, учитывая, что у современных LLM достаточно большой контекст (сотни тысяч-миллионы токенов), и они и так должны были бы неплохо справляться с такими задачами.
Спасибо за статью. Такой вопрос по site based tunneling: он же не заворачивает весь трафик с сайта, а просто роутит по IP/SNI/Host, верно? Что мешает условному max.ru проверить доступность зарубежных сервисов через fetch в no-cors режиме или ещё как-то? Например, вы добавили telegram.org в список сайтов, которые должны идти через прокси. Тогда любое приложение (и даже сайты?) могут увидеть, что telegram.org доступен, хотя он явно не должен быть доступен.
Плюс с таким подходом есть проблема: шпионскому приложению достаточно на любом из распространенных сайтов, которые обычно добавляют в список проксирования (Telegram, ChatGPT, Discord, ...) найти внутреннюю ручку или уязвимость, которая раскрывает IP.
Поэтому явно безопаснее/интереснее было бы посмотреть на обзор решений с per browser tab / per desktop app routing.
Спасибо за статью. У меня возникло два вопроса:
Зачем использовать позднее связывание, если, как вы говорите, нейронки в это не умеют без дополнительных настроек? Понимаю, что хочется иметь свой личный стиль во всех проектах, но в эпоху ИИ как минимум имеет смысл ревьюить свой стиль кода на наличие паттернов, которые на ровном месте ухудшают эффективность ИИ (больший шанс, что нейронка налажает в этом коде, так как такого кода нет/мало в данных обучения модели; больше токенов на то, чтобы прочитать скилл и держать его в контексте, что тоже влияет на дороговизну разработки и на качество, если контекст у вас забит не реально нужными знаниями о проекте, а формальностями, которые можно опустить).
Вы пишите, что размер спецификаций у вас превышает размер кода в несколько раз, и это ожидаемое поведение. Почему вы так считаете? Как будто весь смысл в том, что снижается сложность реализации проектов с нуля, что достаточно написать относительно короткую спеку, а нейронка ее заимплементит, вместо того, чтобы самому писать десятки тысяч строк кода. Возможно, проблема в том, что спека у вас тоже сгенерирована ИИ и поэтому она размытая и такая большая.
Это тоже не панацея. Во-первых факт обхода блокировки все равно будет виден (скам может сделать запрос к telegram.org и увидеть, что он доступен).
Во-вторых, цензору даже необязательно покупать свой сервер за рубежом для этого. Достаточно найти в любом сервисе из вашего белого списка (Telegram, Discord, ChatGPT, всякие зарубежные CDN и так далее) один скрытый пусть даже сервисный или не предназначенный для публичного использования endpoint, который отдает ваш IP — и все.
И не получится гарантировать, что сервисы в вашем белом списке никаким образом не могут спалить ваш IP самостоятельно.
В целом не очень понятно, как оценить "продуктивность" или даже просто рост числа проектов, связанных с ИИ.
Упрощает ли ИИ разработку каких-то простых личных программ для не-разработчиков? Безусловно. Только эти люди скорее всего даже не будут пользоваться GitHub, поэтому непонятно, как включить их в статистику.
А метод анализа на основе числа пакетов PyPI вообще странный. Очевидно же, что большинство новых проектов, созданных ИИ — это какие-то личные или рабочие проекты, там сайты, телеграм-боты, но уж точно не пакеты.
Есть как минимум 2 (https://github.com/loyldg/mytelegram, https://github.com/teamgram/teamgram-server), но они урезанные и их полные версии продаются за десятки тысяч долларов.
Вполне возможно, что с сегодняшними возможностями вайбкодинга и spec-driven development проще навайбкодить свой собственный бекенд, благо вся необходимая документация и референсные реализации клиентской части есть. Как интересный эксперимент.
Это не nightly сборка, это альтернативный официальный Android клиент.
https://telegram.org/blog/telegram-x
Пишу вам из 2026. Вероятно, пришельцы понаблюдали за тем, что у нас происходило в начале года, и решили обойти Солнечную систему стороной.
Obsidian не имеет открытого исходного кода.
А в чем принципиальные отличия с системами вроде https://github.com/tigerbeetle/tigerbeetle?
Как обсуждали в предыдущей статье автора, приватные поля можно было получить и раньше через замыкания (хотя и не стоит использовать такой подход, потому что это ломает оптимизации движков).
Вообще глубоко убежден, что private поля были ошибкой. На практике нередко случается, например, что вам нужно какое-то поле в классе из библиотеки, а разработчик библиотеки
подумал, что он лучше всех знает ООПне подумал о такой возможности и сделал его приватным. Это сильно ухудшает гибкость для сторонних разработчиков. В большинстве языков это нерешаемая проблема, приходится делать форк и поддерживать его в актуальном состоянии. В TS например действительно кейворд private ни на что не влияет в рантайме, что позволяет обойти его через приведение типов, если очень-очень нужно. Чего не скажешь про "#name" поля в JS.Слушайте, действительно, вы правы. Я почему-то был убежден в том, что видел "forked from tdesktop" на гитхабе.
Зачем делать альтернативный клиент, если тврщ майор все равно будет иметь доступ к любым коммуникациям внутри Max? Если беспокоитесь за слив данных с устройства (фотографии, установленные приложения и другие подозрительные разрешения), проще купить отдельный телефон или, ещё проще, поставить Max в полностью изолированный Workspace. Это можно сделать на Android через приложение Island.
Что любопытно, так это то, что десктопный клиент Аськи (ICQ New, пока ее не убили, от MailRu), был форком Telegram Desktop. И работало, и выглядело очень неплохо.
А это вообще смех какой-то, "нативное приложение" на Electron. Кстати, статьи за дискредитацию мессенджера Max ещё не завезли? 😁
Помню, что ещё совсем недавно Google Play требовал очень строгого обоснования этого разрешения. Вряд ли его смогли добавить просто так, скорее всего какой-то функционал, хотя бы ради прохождения ревью они сделали. Или Google уже забил?
Если он уже скачал данные (то есть эксплуатировал найденную уязвимость), нет, в лучшем случае его бы просто поблагодарили и лишили bounty, в худшем - засудили.
Дело в не том, что он "более точный". ADD содержит магию - возможность добавлять в образ файлы по URL и разархивировать tar архивы, что может привести к неожиданному поведению. Поэтому рекомендуют, если возможно, использовать COPY.
https://stackoverflow.com/questions/24958140/what-is-the-difference-between-the-copy-and-add-commands-in-a-dockerfile
https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-large-files-on-github#repository-size-limits
Пишут, что 5 гигабайт спокойно выдадут, а дальше могут возникнуть вопросы. Но строгих лимитов нет.
У меня есть подозрение, что статистика может быть некорректной. Судя по названию таблицы, которое включает слово cache, вероятнее всего, это кеш всех проигранных треков за время, которое приложение Яндекс Музыки было установлено на вашем смартфоне. А значит, скорее всего, некоторая часть кеша образовалась ДО того, как Яндекс поддержал loseless формат, и данные о качестве там, соответственно, старые.
Для чистоты эксперимента было бы здорово удалить приложение и снести все его данные, а после установить заново и сравнить результаты, чтобы убедиться, что статистику не испортил старый кеш.