Ну, это уже другой вопрос) Если собрать реализацию под iOS / Android можно – значит, реализация открытая. Почему не делают под другие платформы – нужно разбираться, но доступность кода и описание протокола это не отменяет.
Ну, у нас вот self hosted GitLab у компании был (кажется, на AWS). Заметили, что git дико тормозит. Оказалось, что бот Антропика (по крайней мере, так мне сказали) уже неделю в цикле выкачивает весь контент единственного публичного репозитория. Или бинарники из этого репозитория, уже точно не помню. Там контента всего несколько сотен мегабайт. Он качал его по кругу в течение недели, с разных IP-адресов. Настолько интенсивно, что работать стало невозможно (минимальная загрузка процессора 30%). Решили проблему закрытием репозитория.
Может бот невероятно тупой, может ботов невероятно много, может Антропик подумал, что зачем тратиться на петабайты места, когда можно просто дёргать данные со всего интернета оттуда, где они лежат? Возможно сочетание этих факторов или ещё что-нибудь.
Спасибо за статью и решение) если Вам будет интересно, подобные вещи на macOS плюс-минус легко сделать на AppleScript. Кстати, некоторые приложения даже предоставляют своего рода API, который доступен в AppleScript. Но даже если нет – там можно открывать приложения, окна в приложениях и обращаться к контролам внутри приложений. В этом случае самое сложное – выяснить, как добраться до нужного контрола. Кстати, вроде бы, можно "записать" действия, но уже точно не помню.
AppleScript – забавный язык) код пишется практически просто как предложения английского языка. Но можно делегировать LLM, конечно)
Ещё можно Shortcuts посмотреть) но на неё у меня меньше надежды.
Утверждение было: "Код закрыт у всех". А до этого выше дополнительный контекст про "хотя бы клиента". Ответ: "У Telegram открыт код клиента". Я вижу, что у Вас много вопросов, и хороших, но это не ко мне)
Уважаемый автор, если Вы серьёзно, то я Вам очень рекомендую хотя бы Стэнфордский курс Cryptography I для начала на coursera прослушать. Боюсь, пока что Ваша статья выглядит как антиреклама Ваших консультационных услуг.
Я бы только, особенно учитывая, что статья для начинающих, упомянул, что для платформеннозависимого кода лучше использовать не фабрику, а что-нибудь полходящее из if-директив. Полагаю, или #if os, или if #available. Но не знаю точно, как будет выглядить запись для Windows, не пробовал собирать Swift под Windows.
Ну и вместо NSCopying лучше, полагаю, сразу использовать Copyable. К тому же, зачем синглтону определять протокол для копирования, если его можно просто не объявлять? Даже если его объявят позже в extension-е, то всё равно не смогут создать другой экземпляр, т.к. доступа к конструктору нет.
А, ну и у синглтона лучше всё-таки let shared, а не var shared, полагаю :) Конечно, ничего другого присвоить не смогут (хотя я вот не помню: у нас класс не финальный, получится ли создать наследника и присвоить его? Может и получится), но просто зачем? К то у же, в режиме Swift 6 Xcode будет орать про shared state :)
Ну так потому что разбиение по слогам спо-и-лер звучит криво. Бо-и-лер тоже. Джо-ин пишется через "и", как раз потому, что джойн – это кривой слог, а джо-ин – нормально. По-инт туда же. И бит-ко-ин. Потому что "койн" – это не слог, а ерунда какая-то.
Значит это кривая практическая транскрипция, и нам нужна новая. Полагаю, её создали те же люди, которые легитимизировали "докУмент" и "йогУрт"? (вместо того, чтобы избавиться от брелоков, ха-ха, засудите меня!).
Вы ещё скажите, что разницы нет. Разница как между "воины" и "войны". И биткоин произносится не как "войны". Если Вы не слышите разницу, то, ну, штош.
Uporoty не высказывал собственное мнение насчёт использования оригинального XRay вместо того, что предлагается в статье. Uporoty высказал своё мнение насчёт той статьи, на которую Вы сослались. Абсолютно обоснованно. Ваша претензия неуместна.
Так киберспортсемы как раз и сидят и тренируются на 120Гц минимум
Естественно)
Разница между 60 и 120 есть, но не "на глаз", а "на руки"
Немного поспорю, что разница между 60 и 120 на глаз очень даже есть) 120 и 240 – не было возможности сравнить) В целом, чем дальше, тем меньше прирост эффекта.
Видео отличное, спасибо! Кратко, по делу, и абсолютно никаких возражений нет :)
Особенно если вы играете в соревновательных режимах и ваш скил если переводить в спорт на уровне минимум кмс, то бесспорно.
На самом деле, эффект прямо противоположный, что неожиданно) Точнее, зависимость противоположная. Чем хуже играет человек, тем больший прирост результата он получает от большей частоты кадров. Профессиональные игроки тоже получает колоссальный эффект, просто он менее выражен относительно их производительности на 60 FPS, т.к. у них выработаны профессиональные навыки, позволяющие им эффективно интерполировать недостающую информацию :)
Вот тут проводили эксперимент (видео спонсировано Nvidia, но до этого было такое же видео чуть меньше по масштабах от этого же канала, которое не было спонсировано, а также я доверяю честности LTT в этом вопросе): https://www.youtube.com/watch?v=OX31kZbAXsA
Но, если что, чудес действительно не бывает, новичок на 240 Hz не сможет победить профи на 60)) Вспоминается встреча с Fatal1ty, где фанаты могли попробовать его победить (в Quake 3) с различными ограничениями. Мне запомнилось, как Fatal1ty играл на крошечном экране (уменьшенная картинка по центру монитора) :) Его это не сильно останавливало.
Ну, это уже другой вопрос) Если собрать реализацию под iOS / Android можно – значит, реализация открытая. Почему не делают под другие платформы – нужно разбираться, но доступность кода и описание протокола это не отменяет.
Под macOS, кстати, тоже нет.
Ну, у нас вот self hosted GitLab у компании был (кажется, на AWS). Заметили, что git дико тормозит. Оказалось, что бот Антропика (по крайней мере, так мне сказали) уже неделю в цикле выкачивает весь контент единственного публичного репозитория. Или бинарники из этого репозитория, уже точно не помню. Там контента всего несколько сотен мегабайт. Он качал его по кругу в течение недели, с разных IP-адресов. Настолько интенсивно, что работать стало невозможно (минимальная загрузка процессора 30%). Решили проблему закрытием репозитория.
Может бот невероятно тупой, может ботов невероятно много, может Антропик подумал, что зачем тратиться на петабайты места, когда можно просто дёргать данные со всего интернета оттуда, где они лежат? Возможно сочетание этих факторов или ещё что-нибудь.
Протокол: https://core.telegram.org/mtproto
Реализация (iOS): https://github.com/TelegramMessenger/Telegram-iOS/tree/eac655f5721b6f3828e0f365516b6e7bafbc53d7/submodules/TelegramCore/Sources/SecretChats
Разве это не то?
Спасибо за статью и решение) если Вам будет интересно, подобные вещи на macOS плюс-минус легко сделать на AppleScript. Кстати, некоторые приложения даже предоставляют своего рода API, который доступен в AppleScript. Но даже если нет – там можно открывать приложения, окна в приложениях и обращаться к контролам внутри приложений. В этом случае самое сложное – выяснить, как добраться до нужного контрола. Кстати, вроде бы, можно "записать" действия, но уже точно не помню.
AppleScript – забавный язык) код пишется практически просто как предложения английского языка. Но можно делегировать LLM, конечно)
Ещё можно Shortcuts посмотреть) но на неё у меня меньше надежды.
Что бы мы делали без Вас ¯\_(ツ)_/¯
Утверждение было: "Код закрыт у всех". А до этого выше дополнительный контекст про "хотя бы клиента". Ответ: "У Telegram открыт код клиента". Я вижу, что у Вас много вопросов, и хороших, но это не ко мне)
Это Wesha, он опять всех победил, не обращайте внимания.
А прочитать вееееееткуууууу?
У Telegram открыт код клиента.
DEL, промахнулся, мои извинения)
Уважаемый автор, если Вы серьёзно, то я Вам очень рекомендую хотя бы Стэнфордский курс Cryptography I для начала на coursera прослушать. Боюсь, пока что Ваша статья выглядит как антиреклама Ваших консультационных услуг.
Спасибо за статью.
Я бы только, особенно учитывая, что статья для начинающих, упомянул, что для платформеннозависимого кода лучше использовать не фабрику, а что-нибудь полходящее из if-директив. Полагаю, или #if os, или if #available. Но не знаю точно, как будет выглядить запись для Windows, не пробовал собирать Swift под Windows.
Ну и вместо NSCopying лучше, полагаю, сразу использовать Copyable. К тому же, зачем синглтону определять протокол для копирования, если его можно просто не объявлять? Даже если его объявят позже в extension-е, то всё равно не смогут создать другой экземпляр, т.к. доступа к конструктору нет.
А, ну и у синглтона лучше всё-таки let shared, а не var shared, полагаю :) Конечно, ничего другого присвоить не смогут (хотя я вот не помню: у нас класс не финальный, получится ли создать наследника и присвоить его? Может и получится), но просто зачем? К то у же, в режиме Swift 6 Xcode будет орать про shared state :)
Ну так потому что разбиение по слогам спо-и-лер звучит криво. Бо-и-лер тоже. Джо-ин пишется через "и", как раз потому, что джойн – это кривой слог, а джо-ин – нормально. По-инт туда же. И бит-ко-ин. Потому что "койн" – это не слог, а ерунда какая-то.
Значит это кривая практическая транскрипция, и нам нужна новая. Полагаю, её создали те же люди, которые легитимизировали "докУмент" и "йогУрт"? (вместо того, чтобы избавиться от брелоков, ха-ха, засудите меня!).
Вы ещё скажите, что разницы нет. Разница как между "воины" и "войны". И биткоин произносится не как "войны". Если Вы не слышите разницу, то, ну, штош.
БиткоИны. Не "биткойны".
Спасибо.
Боюсь, если он есть, он мне неизвестен) Если узнаете – дайте, пожалуйста, знать. Мою жизнь это тоже сильно улучшило бы :)
Так понятнее?
Uporoty не высказывал собственное мнение насчёт использования оригинального XRay вместо того, что предлагается в статье. Uporoty высказал своё мнение насчёт той статьи, на которую Вы сослались. Абсолютно обоснованно. Ваша претензия неуместна.
Естественно)
Немного поспорю, что разница между 60 и 120 на глаз очень даже есть) 120 и 240 – не было возможности сравнить) В целом, чем дальше, тем меньше прирост эффекта.
Видео отличное, спасибо! Кратко, по делу, и абсолютно никаких возражений нет :)
На самом деле, эффект прямо противоположный, что неожиданно) Точнее, зависимость противоположная. Чем хуже играет человек, тем больший прирост результата он получает от большей частоты кадров. Профессиональные игроки тоже получает колоссальный эффект, просто он менее выражен относительно их производительности на 60 FPS, т.к. у них выработаны профессиональные навыки, позволяющие им эффективно интерполировать недостающую информацию :)
Вот тут проводили эксперимент (видео спонсировано Nvidia, но до этого было такое же видео чуть меньше по масштабах от этого же канала, которое не было спонсировано, а также я доверяю честности LTT в этом вопросе): https://www.youtube.com/watch?v=OX31kZbAXsA
Но, если что, чудес действительно не бывает, новичок на 240 Hz не сможет победить профи на 60)) Вспоминается встреча с Fatal1ty, где фанаты могли попробовать его победить (в Quake 3) с различными ограничениями. Мне запомнилось, как Fatal1ty играл на крошечном экране (уменьшенная картинка по центру монитора) :) Его это не сильно останавливало.