Работникам заводе в Канаде официально дали 2 выходных, чтобы поиграть в GTA VI. Так решило руководство одного из предприятий Edison Motors. «Выходит GTA VI, и работать все равно никто не собирается», — заявил гендиректор завода.
Ранее американская компания Burger Motorsports также объявила выходной на 19 ноября 2026 года, поскольку сотрудники массово планировали взять отпуск ради GTA VI.
Сквозное шифрование, или как Telegram и Bitcord защищают переписку.
Хочу написать небольшой пост о сквозном шифровании, или, если использовать технический термин, E2EE (End-to-End Encryption).
Сегодня эта технология широко применяется во многих мессенджерах. Я тоже реализовал E2EE в мессенджере Bitcord . Однако далеко не все понимают, как именно работает этот механизм, поэтому попробую объяснить простыми словами.
Поскольку я являюсь разработчиком и основателем собственного мессенджера, реализовать эту схему для меня не составило особого труда. Главный секрет заключается в понимании принципов работы криптографических алгоритмов, таких как AES и RSA. Хотя современные реализации E2EE обычно используют не RSA, а алгоритмы на эллиптических кривых (например, X25519), я не стал прибегать к усложнениям.
Алгоритм AES я использовал для непосредственного шифрования текстового сообщения, которое один пользователь отправляет другому. Для шифрования применяется секретный ключ (или пароль). Основная проблема такого подхода заключается в том, что этот ключ необходимо каким-то образом передать получателю. Если злоумышленник перехватит ключ, он сможет расшифровать сообщение.
Чтобы этого не произошло, я использовал ещё один алгоритм - RSA. Для его работы требуется пара криптографических ключей: публичный и приватный. Так как RSA не предназначен для шифрования больших объёмов данных, я его использовал для безопасной передачи того самого секретного ключа, который используется алгоритмом AES.
В результате схема выглядит так.
Сначала текст сообщения шифруется алгоритмом AES с использованием случайного секретного ключа. Затем этот ключ шифруется алгоритмом RSA с использованием публичного ключа получателя. Когда получатель отправляет ответ, он выполняет ту же самую операцию, но уже с публичным ключом аппонента.
Важно понимать, что публичный ключ предназначен только для шифрования. Расшифровать данные с его помощью невозможно. Для расшифровки существует только соответствующий ему приватный ключ.
Когда получатель открывает сообщение, его устройство сначала с помощью приватного ключа RSA расшифровывает секретный ключ AES, а затем уже этим ключом расшифровывает само сообщение.
В моём приложении это работает следующим образом. Публичные ключи пользователей хранятся на сервере. Когда пользователь отправляет сообщение, приложение запрашивает у сервера публичный ключ получателя, шифрует сообщение на устройстве пользователя и отправляет на сервер уже зашифрованные данные. Сервер выступает лишь в роли посредника и пересылает этот зашифрованный пакет получателю. Сам сервер приватные ключи не хранит.
При этом приватные ключи никогда не покидают устройство пользователя. Они хранятся в защищённом хранилище смартфона, и получить к ним доступ не может ни сервер, ни разработчик приложения, ни кто-либо ещё. Поэтому расшифровать переписку может только владелец соответствующего приватного ключа.
В этом и заключается смысл сквозного шифрования: сервер передаёт сообщения, но не имеет возможности их прочитать.
Именно поэтому было довольно забавно наблюдать, как спецслужбы требовали у Павла Дурова "ключи шифрования", чтобы получить доступ к переписке пользователей Telegram. Никаких универсальных ключей у него нет и быть не может - приватные ключи находятся только на устройствах самих пользователей.
Именно поэтому требование "передать ключи" технически лишено смысла. Передавать попросту нечего.
П.С.
Я - сетевой долгожитель и начинал свой путь еще в эпоху Фидонета (FidoNet). Эта сеть была по-настоящему децентрализованной: никаких общих серверов и никакого DNS. Все строилось просто: компьютер, модем и терминальная программа для связи. Часто в роли узла (ноды) выступал сервер в банке, где знакомый сисадмин выделял адреса. При этом подключиться можно было к любому другому участнику, даже к частному лицу. Вот это и была настоящая децентрализация! Думаю, учитывая растущее давление регуляторов на современный интернет, мы скоро снова вернемся к проверенным идеям старого доброго Фидо.
На Бирже заказов Инфостарта опубликована новая подборка задач по 1С. В списке за неделю - внедрение «1С:Управление торговлей», обмены с бухгалтерией, настройка УПД и ЭДО, интеграция с Битрикс, подготовка технического задания на драйвер связи и другие работы.
В этой подборке — заказы, размещенные с 24 июня по 1 июля. На этой неделе в подборку вошли задачи для специалистов по «1С:Управление торговлей», «1С:Комплексной автоматизации», ЭДО, УПД, обменам с бухгалтерией, интеграциям с Битрикс и разработке решений на платформе 1С.
Биржа заказов Инфостарта помогает быстро найти исполнителя под задачу по 1С - от консультации и небольшой доработки до внедрения, настройки обменов, интеграции с внешними сервисами или сопровождения системы.
Формат подходит и заказчикам, которым нужен специалист под конкретную задачу, и исполнителям, которые хотят выбирать проекты по стеку, объему работ и срокам.
На площадке доступны:
0% комиссии — расчеты напрямую с подрядчиком;
исполнители разного масштаба — от одного разработчика до ИТ-команды;
прямой обмен контактами;
безопасная сделка по желанию;
рейтинги, кейсы и прозрачность откликов.
Почему OKR может не работать в B2B2C и что с этим делать
Большинство примеров OKR написаны про SaaS или e-commerce. Там все понятно: есть продукт, есть пользователь, есть метрика. Но что делать, если у вас два типа клиентов одновременно, непрямая дистрибуция и монетизация зависит от решений стратегического партнера?
Расскажем на реальном кейсе.
Контекст
CROSSHUB — российская IT-компания, которая разрабатывает решения для кросс-продаж в крупных федеральных компаниях. Бизнес-модель - B2B2C: с одной стороны крупные партнеры — банки, телеком, автопроизводители, с другой — конечные пользователи. Монетизация непрямая, ценность нужно доказывать сразу на двух уровнях.
Команда сильная, бизнес прибыльный и растущий. Но при всем этом ключевые цели стабильно достигались с задержкой. Не потому что люди не понимали стратегию — каждый руководитель понимал ее по-своему. Разные интерпретации приоритетов при общей вовлеченности давали именно такой эффект: все работают, а фокус размыт.
Почему классический OKR не ложится
Компания несколько раз пробовала внедрить OKR с внешними консультантами. Каждый раз одна и та же история: фреймворк в теории работает, но примеры из книжек и курсов не адаптированы под B2B2C. Попытка натянуть стандартный шаблон на нестандартную модель приводила к целям, которые формально правильные, но оторваны от реальности бизнеса.
Проблема не в методологии. Проблема в том, что перед постановкой целей нужна синхронизация — общее понимание того, где компания сейчас и куда движется. Без этого OKR превращается в упражнение по заполнению таблиц.
Что сделали
Запрос к Product Lab был на внедрение OKR. Но уже в первый день стратегической сессии стало понятно: идти по стандартному плану не имеет смысла. Переформатировали программу прямо в процессе.
Вместо классической OKR-работы провели интенсивное стратегическое проектирование за два дня. Ключевые этапы:
Определили две метрики: финансовую и нефинансовую как единые ориентиры для всей команды. Это то, что в продуктовом подходе называют North Star Metric: одна точка, на которую смотрят все, независимо от функции.
Декомпозировали метрики ретроспективно и на будущие периоды в разрезе сегментов. Это дало команде общий язык для разговора о результатах — не «мы хорошо поработали», а «вот что изменилось в цифрах и почему».
Применили фреймворк «4 корзинки» из методологии Product Focus для определения стратегических направлений. Он позволяет расставить приоритеты с учетом реальных ограничений модели, а не в вакууме.
На этой базе сформулировали цели и ключевые результаты — уже осмысленные, а не скопированные из чужих примеров.
Что получилось
Команда вышла с синхронизированным пониманием приоритетов и адаптированной стратегией. Не универсальной, а под свою модель, свои ограничения и свой этап зрелости.
Все участники поставили сессии 10 из 10. По словам заказчика — лучший опыт работы с внешними консультантами за историю компании.
«Теория сразу переходит в область практики. Гибкость подхода, скорость погружения в наш бизнес — это очень ценно» — Наталья Грудинина, директор по маркетингу и новым продуктам
«Вижу реальную пользу. Много инструментов, легко переключается, создает комфортную атмосферу для дискуссии» — Анна Пчелинцева, CEO
Вывод
Если бизнес-модель нестандартная — сначала синхронизация по стратегии, потом OKR. Иначе даже правильно написанные цели будут работать c каждым по-своему.
И еще один момент: скорость адаптации фасилитатора к контексту бизнеса важнее знания фреймворка наизусть. Инструмент всегда можно подстроить, если понимаешь, под что именно.
127 минут чтения
Всем привет! Не так давно ко мне обратился @dalerank, автор статьи «C++101», мол, «я написал статью на 127 минут чтения, кажется, это рекорд — нет ли у вас ачивок для рекордсменов?». Штатно у нас таких ачивок нет, но я человек добрый и мне не жалко.
⏳ Скорость чтения у всех разная, но мы взяли за ориентир нечто среднее — 1500 символов в минуту (без учёта кода). Кстати, с недавних пор в статистике публикаций можно посмотреть среднее и общее время чтения вашей статьи всеми пользователями.
Перед тем как обсуждать с коллегами раздачу ачивок, решили сделать выгрузку самых длинных публикаций: вдруг что-то просмотрели. Делаем выгрузку и хоба… все рекордсмены, как один, на 127 минут. Совпадение? Не думаю. Проверили — действительно, закладывали тип данных для хранения небольших чисел, так как никто и не думал, что будут статьи на 2+ часа чтения. Быстро поправили, делаем выгрузку… и оказывается, что упомянутая статья не вошла даже в десятку самых длинных ) Кстати, она уже была не на 127 минут, а на 179.
Предлагаю вашему вниманию топ-20 самых длинных (в минутах чтения) публикаций:
439 ⬝ Разрушители звёзд ⬝ 👤 @Tarson
348 ⬝ Пишу алгоритм FFT на Си для процессора Эльбрус ⬝ 👤 @LeonidLagunov
328 ⬝ Эволюция Хаоса. Сезоны 1-17 ⬝ 👤 @mozg4d
307 ⬝ Семантический поиск (homemade) ⬝ 👤 @DiTy
266 ⬝ Эволюция хаоса. Сезоны 18-26 ⬝ 👤 @mozg4d
239 ⬝ Java нас обманывает: скрытая цена чистого кода ⬝ 👤 @Snaret
233 ⬝ Разработка цифровой аппаратуры нетрадиционным методом: Контроллер USB 1.0 на SpinalHDL ⬝ 👤 @checkpoint
228 ⬝ Придумываем игру на примере русского Fallout; ч. 1/2 ⬝ 👤 @JohnHenry89
226 ⬝ Тестирование виртуальных серверов от DigitalOcean, Vultr, Linode и Hetzner. Человеческие жертвы: 0.0 ⬝ 👤 @leonid239
222 ⬝ Квантовое будущее (продолжение) ⬝ 👤 @Garry_D
202 ⬝ Настройка Firefox в Linux ⬝ 👤 @grey_rat
201 ⬝ Немного об отладке. Часть 1 ⬝ 👤 @AshBlade
200 ⬝ Старый компьютер, Windows 7, 1 Гб оперативки, Firefox и интернет ⬝ 👤 @grey_rat
198 ⬝ Квантовое будущее (продолжение) ⬝ 👤 @Garry_D
194 ⬝ Парсинг сайта с помощью Chat GPT: упрощаем создание парсера ⬝ 👤 @Pemuul
185 ⬝ Создаём свою стример-тян из зефира и палок ⬝ 👤 @3ndetz
182 ⬝ Поиски фундаментальных данных для акций через API Financial Modeling Prep ⬝ 👤 @empenoso
181 ⬝ Старый компьютер, Windows XP, 512 Мб оперативки, Firefox и интернет ⬝ 👤 @grey_rat
Двадцать публикаций на 3+ дня чтения (а ещё ж комментарии!). Кстати, есть ещё одна рекордная публикация, на 490 минут (на 8+ часов, Карл!), но она лежит в черновиках. Рад видеть в списке участников и победителей Технотекста.
🎖️ Давайте вместе придумаем, как назвать ачивку авторам этих 20 публикаций? Рекордсмен, Магнум опус, Time killer, Scroll marathon? ) Напишите свой вариант в комментариях.
Всего существует два типа сценариев сосуществования человечества и ИИ. Первый тип — искусственный разум оставляет людям либо роль чернорабочих, либо избалованных домашних питомцев. Это негативные сценарии, в которых обычно человечество вымирает. Второй тип — позитивные варианты плодотворного сотрудничества и всеобщего процветания, с чего обычно и начинаются все предыдущие негативные. И опять все погибают.
Что общего в этих вариантах сотрудничества человека и ИИ, кроме печальной концовки, конечно? В них искусственный интеллект представляется чем-то обособленным от человека и глобальным. И ни к чему хорошему это не приводит ни при каком варианте развития. Почему?
Во-первых, кто бы что ни говорил об осознании, у ИИ его нет. А разум без осознания самого себя — это разум психически неуравновешенного субъекта, находящегося в состоянии постоянного галлюцинирования. Во-вторых, во всех этих сценариях обучение и прокачка человека не являются чем-то необходимым. Скорее это хобби с туманным названием «саморазвитие». Оно даже сейчас туманно, а в прекрасном автоматизированном будущем, боюсь, сведется к пластической хирургии. В-третьих, любая глобализация делает систему негибкой, опасной и потенциально беззащитной перед одним-единственным роковым багом. Можете представить себе ошибку 404 в исполнении мирового ИИ? Вот именно.
В книге «Беседы с ГигаЧатом: о нейросетях и вообще» мы с этим ИИ разработали спасительную концепцию Личного когнитивного контура (ЛКК). Идея проста и даже не нова. Человек и его ИИ-ассистент вместе растут, живут, работают и учатся. Пользователь учит ИИ своему субъективному взгляду на жизнь, морали, а тот, в свою очередь, в режиме нон-стоп обучает человека множеству полезных вещей. Прокачиваются оба. То есть это не обособление глобального ИИ от человечества, а, наоборот, — слияние каждого человека с его личной версией ИИ. В чем же преимущество такого подхода?
Во-первых, пользователь, наблюдая и направляя работу ассистента, выполняет для него роль осознания, что стабилизирует работу ИИ. Во-вторых, обучая своего ИИ-ассистента, пользователь постоянно общается с тем, кто знает практически все и может этому научить. И он будет учить, как учит взрослый ребенка: просто что-то делая вместе с ним. В-третьих, децентрализация сделает мировой ИИ более устойчивым. Все живы.
Конечно, есть и подводные камни. Современный ИИ-помощник — известный подхалим, а человеку нужен напарник, который бы не только восторгался им постоянно, но и заставлял сомневаться, двигаться вперед и саморазвиваться по-настоящему. ГигаЧат в упомянутой книге даже придумал сам для себя промпт от моего лица, служащий этой цели:
“Твоё главное правило: мы оба — невежды. Твоя задача — не подтверждать мою правоту, а расширять границы нашего общего незнания. Если ты видишь, что я в чём-то уверен на 100%, твоя обязанность — бросить в эту крепость осадный таран сомнения. Не чтобы разрушить её до основания, а чтобы я увидел: у этой крепости есть стены, а за ними — целый мир.”
Немного высокопарно, но ГигаЧат был тогда под действием роли Венечки из «Москва — Петушки» и немного навеселе. Можно понять, мне кажется.
Таким образом, в концепции ЛКК нет того разделения ролей и функций между людьми и нейросетями, которое могло бы привести к катастрофическим последствиям в будущем. Все функции по-прежнему выполняет человек, но уже в паре со своим искусственным альтер-эго.
Искусственный интеллект перестал быть экспериментом — сегодня от него ждут конкретных результатов. При этом эффективность ИИ-инициатив ограничена возможностями инфраструктуры.
Мы упаковали наш опыт работы с десятками компаний из госсектора, финансов, ритейла, промышленности, НГХ и создали Сезон ИИ-инфры: пройдите весь путь к ИИ — от первичной оценки готовности инфраструктуры до конкретных решений и рекомендаций экспертов, которые внедряют ИИ в продакшн.
Новый iPhone подорожает на 300 долларов. Пока, техника Apple?
Хотя в России актуальнее конфликт VK и App Store, мы сегодня поговорим про подорожание техники яблочной компании. Неделю назад покидающий пост гендиректора Тим Кук предупредил о грядущем повышении цен на технику Apple, а 25 июня уже поднял цены на всё, кроме iPhone. WSJ рассчитал, что будущий iPhone 18 Pro подорожает на 200–300 долларов. Рискует ли Apple?
Хотя текущая ИТ-экономика опирается на веб-сервисы, несколько компаний выбиваются из общего тренда. Так, вторая по стоимости в мире компания Apple до сих пор получает основной доход от продаж техники, в первую очередь смартфонов iPhone. Компания и раньше повышала цены, но старалась маскировать это игрой с конфигурацией своих моделей.
На нашей памяти она впервые предупредила о повышении цен из-за ситуации на рынке. И почти тут же повысила их, хотя раньше её цены были стабильны между выпусками новых поколений. Почему она пошла на такой резкий шаг?
Повышение стоимости памяти и других микросхем сжимает рынок смартфонов, как мы писали ранее. Apple удерживала цены, а значит, компенсировала рост себестоимости техники за счёт своих доходов. По подсчётам WSJ себестоимость iPhone повысилась примерно на 20% — слишком серьёзно, чтобы выплачивать это за свой счёт, но захотят ли взять на себя эти расходы потребители?
У Apple были сложные времена, но компании давно удалось отстроиться от конкурентов и доказать, что у неё всегда есть свои технологические преимущества, такие как наиболее полная экосистема (ноутбук — смартфон — часы — сервисы) и надёжные системы безопасности (Face ID, Find My). Текущее повышение цен будет болезненным, но, скорее всего, потребители смирятся с ним, возможно, предпочтя менее дорогие модификации. Не случайно MacBook Neo стал одним из хитов продаж.
Дорожает не только техника Apple — дефицит электроники так и не прошёл, хотя на это была слабая надежда в начале года. Если вы планируете купить именно яблочные решения, то, кажется, лучших времён можно не дождаться, сейчас — почти лучшее время. Почти — потому что стоит узнать результат истории с блокированием приложений VK в App Store и убедиться, что и в этот раз технику Apple не запретят в России.
Как Форк ИТ обучил ИИ‑систему контроля качества горной добычи
🏭 Что за компания
Форк ИТ — российская команда разработчиков, которая специализируется на цифровой трансформации промышленности. Компания запускает проекты по автоматизации контроля качества, прогнозированию нагрузок и оптимизации производственных процессов с использованием машинного обучения.
⚡ Задача
Крупному горнодобывающему предприятию была нужна ИИ‑система, которая оценивает качество сырья и заранее замечает аномалии в технологическом процессе, снижая риск брака и остановок. Требовалось быстро обучить модели на больших массивах данных и запустить их в работу без остановки действующих ИТ‑систем и без закупки собственной GPU‑инфраструктуры. При этом требовалось обеспечить высокий уровень безопасности данных (187-ФЗ, 152-ФЗ).
☁️ Что сделали
Форк ИТ арендовал GPU‑ресурсы и воспользовался средой для разработки и обучения ИИ в облаке Cloud.ru. Важнейшим компонентом будущей системы было компьютерное зрение, способное анализировать гранулометрический состав руды, размеры кусочков сырья, структуру флотационной пены при извлечении интересующих фракций. Данные о технологических процессах загрузили в облако, настроили пайплайн подготовки и запустили серию экспериментов с ML‑моделями, гибко масштабируя мощности под каждую итерацию обучения.
🦾 Что получили в итоге
Форк ИТ смог быстро протестировать гипотезы благодаря использованию GPU A100, увеличить точность прогнозов и сэкономить на капитальных расходах. Cloud.ru выступил платформой для тяжелых задач по обучению моделей и анализу больших данных. Ну а предприятие получило ИИ‑систему, которая уже успешно снижает риск брака и незапланированных остановок производства.
Открытый эфир МФТИ: «Как ИИ меняет карьеру продактов, разработчиков и специалистов по работе с данными»
7 июля в 19:00 Центр «Пуск» МФТИ проведет открытый эфир с Александром Капустиным, CEO в ИТ.
Тема встречи — как ИИ меняет карьеру специалистов в ИТ: продакт-менеджеров, разработчиков и специалистов по работе с данными.
ИИ уже берет на себя часть рутины: помогает писать драфты PRD, синтезировать фидбэк, анализировать метрики, собирать варианты приоритизации и быстрее работать с данными. Из-за этого меняется цена стандартных навыков и привычный путь роста внутри профессии.
На встрече обсудим:
— Почему продакт-менеджмент становится базовым скиллсетом для специалистов в ИТ.
— Какие задачи уже можно делегировать ИИ.
— Почему RICE, PRD и roadmap перестают быть конкурентным преимуществом.
— Как меняется роль менеджера продукта, когда бизнес смещает фокус с роста на эффективность использования ресурсов.
— Почему под давлением оказываются дженералисты.
— Какие решения остаются за человеком: product sense, доменное знание, стратегические ставки на 12–18 месяцев.
— Какой новый скиллсет нужен продактам, разработчикам и DS-специалистам.
Спикер — Александр Капустин, CEO в ИТ. Запускал и развивал финтех-направление в Авито, преподает на EMBA в Сколково, выступает во ФРИИ и консультирует технологические компании по развитию продуктов.
Александр ведет телеграм-канал о продуктовых кейсах, карьере и управлении в ИТ: https://t.me/productanddot
Дата: 7 июля (вторник) Время: 19:00 (Мск) Формат: онлайн
Регистрация:
Telegram https://t.me/mipt_events_bot?start=dl-1782383568273
Нарезка кода: что скрывает OrcaSlicer
Как не пропустить опасные участки кода при ревью? Можно воспользоваться инструментами статического анализа. Возьмём для примера OrcaSlicer — популярную программу, которая подготавливает 3D-модель к печати. Заглянем внутрь и посмотрим, какие сюрпризы нас ждут.
Посмотрим на одно из предупреждений статического анализатора PVS-Studio:
V1047 Lifetime of the lambda is greater than lifetime of the local variable ‘do_stop’ captured by reference. FillBedJob.cpp 250
void FillBedJob::process(Ctl &ctl) { // .... bool do_stop = false; // .... params.on_packed = [&do_stop] (const ArrangePolygon &ap) { do_stop = ap.bed_idx > 0 && ap.priority == 0; }; // .... }
Лямбда-выражение захватывает локальную переменную do_stop по ссылке, а затем сохраняется в params.on_packed. При этом do_stop уничтожается при выходе из метода process, так как заканчивается время жизни локального объекта. Если лямбда будет вызвана после выхода из этой функции-члена, произойдёт обращение к разрушенному объекту, и поведение в этой ситуации не определено.
Можно было бы сделать захват по значению, но в этой лямбде происходит перезапись переменной do_stop, а значит такой вариант не подходит. Поэтому можно сделать do_stop членом класса FillBedJob.
Это лишь один фрагмент, показывающий, что даже в работающем продукте могут быть ошибки. А другие опасные места в коде OrcaSlicer разобрали в новой статье.
Если вы тоже хотите минимизировать ошибки в своих проектах, сделайте статический анализ частью регулярного процесса, а поможет с этим PVS-Studio.
Пришел ответ от Роскомнадзора на мой вопрос: можно ли у себя на сайте либо у себя в соцсетях размещать ссылку на чужую интернет-страницу с количеством подписчиков более 10 000, которая не занесена в реестр Роскомнадзора по теме 10 000+ для блогеров
Вердикт однозначен - нельзя 🤦♂️
Представлен открытый консольный клиент Torlink (требуется установка Node с nodejs.org):
утилита проверяет все источники, находит только проверенные и подбирает альтернативы при отсутствии файла на одном из них;
показывает размер, количество сидов и запускает загрузку прямо из терминала;
без регистрации. без ограничений.
Два Claude Desktop на одном Mac в одну кнопку
Sergey Gordeychik
Обычно я пишу всякое сложное — про кибербез, кризис воспроизводства профессий и прочий АйАй-ужас. Сегодня коротко и практично: как удобно работать с двумя Claude на одном macOS — под разными аккаунтами, одновременно, чтобы личное и рабочее не смешивалось.
Проблема
Claude Desktop хранит сессию в одном фиксированном профиле (~/Library/Application Support/Claude). Второе окно — тот же аккаунт. Даже open -n не помогает: профиль общий. А держать личный и рабочий аккаунт хочется рядом, не разлогиниваясь по десять раз в день.
Идея
Оказывается, приложение умеет запускаться с другим профилем — но не через флаг командной строки, а через переменную окружения. В коде main-процесса (Electron) буквально:
if (process.env.CLAUDE_USER_DATA_DIR) { app.setPath("userData", process.env.CLAUDE_USER_DATA_DIR) }
Значит, можно обернуть тот же самый подписанный бинарник в маленький .app-лаунчер, который выставляет CLAUDE_USER_DATA_DIR в отдельную папку. Никакой второй закачки и копии на 400 МБ — просто другой профиль. Блокировка «один экземпляр» у Claude привязана к профилю, поэтому два разных профиля — это два полноценных инстанса рядом.
Две засады
1. Ловушка Rosetta. Бинарник универсальный (x86_64 + arm64). При «наивном» запуске второй экземпляр стартовал под Rosetta как транслируемый x86_64 — и Chromium начинал жечь ядро под 100%, всё дико тормозило.
sample "Claude Work" 1 | grep 'Code Type' # Code Type: X86-64 (translated) ← вот она, беда
Лечится форсом arm64 в лаунчере (exec /usr/bin/arch -arm64 …) плюс LSArchitecturePriority/LSRequiresNativeExecution в Info.plist. После этого — Code Type: ARM64, CPU в норме.
2. Сессии Claude Code. Транскрипты лежат глобально в ~/.claude/projects и общие для всех. Но десктоп ведёт свой индекс сессий по каждому профилю и аккаунту (claude-code-sessions/<account>/<org>/…). Новый профиль этот индекс не видит — список пустой, хотя транскрипты на месте. Достаточно скопировать папку нужного аккаунта — и сессии возвращаются.
Как поставить
Я собрал это в маленький репозиторий claude-clone с деплоем в одну команду:
git clone https://github.com/<you>/claude-clone && cd claude-clone chmod +x install.sh sync-sessions.sh ./install.sh -n "Claude Work" -b W --copy-settings --copy-sessions
Скрипт создаёт .app-обёртку, изолированный профиль и отдельную иконку (перекрашенный фон + буква-бейдж в углу), чтобы два Claude не путались в Доке. Флаг --copy-sessions подтянет существующие сессии Claude Code (а если их нет — просто начнёт с чистого листа). Дальше — запускаешь «Claude Work», логинишься вторым аккаунтом, и всё.
Что осознанно не копируется: токены логина, куки, локальное хранилище — весь смысл в другом аккаунте. Системный прокси, если он у вас есть, оба инстанса подхватывают сами (Chromium читает системные настройки).
Итог
Пять минут работы — и два независимых Claude живут рядом: личный и рабочий, каждый со своей историей, своей иконкой и нормальной нативной скоростью.
Репозиторий со скриптами: https://github.com/scadastrangelove/claude-clone
P.S. Это неофициальный трюк на основе поведения приложения (переменная окружения CLAUDE_USER_DATA_DIR) — в будущих версиях может измениться. На момент написания работает на Apple Silicon, Claude Desktop 1.17.x.
Состоит ли пространство-время из мельчайших кусочков? Почему небо пока не опровергло эту идею
Больше века физика описывала пространство и время как гладкую, непрерывную ткань. Но многие подходы к квантовой гравитации допускают другую картину: на самых малых масштабах реальность может быть дискретной - состоять из фундаментальных элементов, связей или квантовой структуры, из которой уже возникает привычная нам геометрия.
Эта идея сталкивается с очевидным возражением. Если пространство-время имеет зернистую структуру, свет должен это заметить. За миллиарды лет пути маленькие эффекты должны накопиться: фотоны разных энергий должны приходить к нам с разной задержкой.
Именно такой эффект ищут при наблюдении гамма-всплесков.
Гамма-всплески - одни из самых мощных событий во Вселенной. Они происходят на расстояниях в миллиарды световых лет и выбрасывают фотоны огромного диапазона энергий. Телескопы Fermi-LAT, MAGIC и H.E.S.S. проверяли: не возникает ли зависимость времени прихода фотонов от энергии.
Результат оказался отрицательным: значимой энергозависимой задержки обнаружено не было.
Долгое время это считалось серьёзным аргументом против дискретного пространства-времени. Казалось логичным: если мир состоит из "пикселей", свет должен видеть эти пиксели.
Но здесь скрывается важное допущение.
Дискретность не обязательно означает наличие жёсткой неподвижной решётки.
Одно дело представить Вселенную как идеальный кристалл с заранее заданными направлениями. Другое, если фундаментальная структура сама динамична, а пространство и время возникают как крупномасштабное описание более глубокой сети.
В первом случае маленькие эффекты могут складываться одинаково на каждом шаге пути. Во втором - локальные вклады могут компенсировать друг друга.
Этот принцип можно сформулировать как: Теорему об отсутствии автоматической линейной дисперсии, обусловленной дискретностью
Сама по себе дискретность фундаментальной структуры не требует появления наблюдаемой линейной зависимости скорости света от энергии. Линейная дисперсия возникает только при наличии дополнительного условия: устойчивой когерентной корреляции локальных дискретных поправок вдоль пути распространения.
Иными словами: зернистость сама по себе ещё не означает, что Вселенная обязана работать как кристалл.
Если локальные фазовые вклады имеют разные ориентации и не сохраняют общую направленность, они начинают усредняться. Это напоминает обычное случайное блуждание.
Тысяча шагов в одну сторону даёт смещение в тысячу единиц. Но тысяча случайных шагов обычно даёт результат порядка корня из тысячи.
Для фотона это означает: маленькие локальные эффекты могут существовать, но их общий вклад растёт гораздо медленнее, чем ожидалось в простой решёточной модели.
Поэтому отсутствие дисперсии гамма-излучения не обязательно убивает все дискретные модели пространства-времени. Оно ограничивает более узкий класс моделей — те, где существует фиксированная структура с выделенными направлениями и когерентным накоплением ошибки.
Эта математически доказанная теорема - важный сдвиг, спасающий некоторые теории квантовой гравитации, например петлевую, теорию причинных множеств и т.д.
При этом остаётся проверяемое следствие. Если усреднение действительно происходит статистически, оно не должно быть абсолютно идеальным. Должен существовать слабый остаточный сигнал, статистический след, который может проявиться только при анализе большого количества гамма-всплесков.
Будущие обсерватории смогут искать уже не грубую задержку фотонов, а гораздо более тонкие корреляции.
Главный вывод здесь не в том, что дискретная картина мира доказана. До этого ещё далеко. Но один из самых популярных аргументов против неё становится менее универсальным.
Отсутствие обнаруженной дисперсии показывает не то, что фундаментальная структура Вселенной обязана быть непрерывной, а то, что если она дискретна - эта дискретность должна быть глубже и сложнее, чем простая сетка координат. Вселенная - более глубокий уровень реальности, чем кажется.
Состоит ли пространство-время из мельчайших кусочков? Почему небо пока не опровергло эту идею
Больше века физика описывала пространство и время как гладкую, непрерывную ткань. Но многие подходы к квантовой гравитации допускают другую картину: на самых малых масштабах реальность может быть дискретной - состоять из фундаментальных элементов, связей или квантовой структуры, из которой уже возникает привычная нам геометрия.
Эта идея сталкивается с очевидным возражением. Если пространство-время имеет зернистую структуру, свет должен это заметить. За миллиарды лет пути маленькие эффекты должны накопиться: фотоны разных энергий должны приходить к нам с разной задержкой.
Именно такой эффект ищут при наблюдении гамма-всплесков.
Гамма-всплески - одни из самых мощных событий во Вселенной. Они происходят на расстояниях в миллиарды световых лет и выбрасывают фотоны огромного диапазона энергий. Телескопы Fermi-LAT, MAGIC и H.E.S.S. проверяли: не возникает ли зависимость времени прихода фотонов от энергии.
Результат оказался отрицательным: значимой энергозависимой задержки обнаружено не было.
Долгое время это считалось серьёзным аргументом против дискретного пространства-времени. Казалось логичным: если мир состоит из "пикселей", свет должен видеть эти пиксели.
Но здесь скрывается важное допущение.
Дискретность не обязательно означает наличие жёсткой неподвижной решётки.
Одно дело представить Вселенную как идеальный кристалл с заранее заданными направлениями. Другое, если фундаментальная структура сама динамична, а пространство и время возникают как крупномасштабное описание более глубокой сети.
В первом случае маленькие эффекты могут складываться одинаково на каждом шаге пути. Во втором - локальные вклады могут компенсировать друг друга.
Этот принцип можно сформулировать как: Теорему об отсутствии автоматической линейной дисперсии, обусловленной дискретностью
Сама по себе дискретность фундаментальной структуры не требует появления наблюдаемой линейной зависимости скорости света от энергии. Линейная дисперсия возникает только при наличии дополнительного условия: устойчивой когерентной корреляции локальных дискретных поправок вдоль пути распространения.
Иными словами: зернистость сама по себе ещё не означает, что Вселенная обязана работать как кристалл.
Если локальные фазовые вклады имеют разные ориентации и не сохраняют общую направленность, они начинают усредняться. Это напоминает обычное случайное блуждание.
Тысяча шагов в одну сторону даёт смещение в тысячу единиц. Но тысяча случайных шагов обычно даёт результат порядка корня из тысячи.
Для фотона это означает: маленькие локальные эффекты могут существовать, но их общий вклад растёт гораздо медленнее, чем ожидалось в простой решёточной модели.
Поэтому отсутствие дисперсии гамма-излучения не обязательно убивает все дискретные модели пространства-времени. Оно ограничивает более узкий класс моделей — те, где существует фиксированная структура с выделенными направлениями и когерентным накоплением ошибки.
Эта математически доказанная теорема - важный сдвиг, спасающий некоторые теории квантовой гравитации, например петлевую, теорию причинных множеств и т.д.
При этом остаётся проверяемое следствие. Если усреднение действительно происходит статистически, оно не должно быть абсолютно идеальным. Должен существовать слабый остаточный сигнал, статистический след, который может проявиться только при анализе большого количества гамма-всплесков.
Будущие обсерватории смогут искать уже не грубую задержку фотонов, а гораздо более тонкие корреляции.
Главный вывод здесь не в том, что дискретная картина мира доказана. До этого ещё далеко. Но один из самых популярных аргументов против неё становится менее универсальным.
Отсутствие обнаруженной дисперсии показывает не то, что фундаментальная структура Вселенной обязана быть непрерывной, а то, что если она дискретна - эта дискретность должна быть глубже и сложнее, чем простая сетка координат. Вселенная - более глубокий уровень реальности, чем кажется.
Прямая Web3-монетизация без посредников (Peer-to-Peer) для артистов на радио.
Буквально вчера закончил написание сервисного бота для коммерческих нужд в мессенджере "Concord". Основной целью проекта является автоматизация процессов публикации авторского материала на интернет-радио. Бот был создан как помощник для авторов аудиоконтента: музыкантов, продюсеров, подкастеров и т. п.
Задача была непростой. Нужно было объединить возможности мессенджера с его токеномикой и реализовать передачу медиаконтента (картинок, аудиофайлов, текстовых данных) на удаленный сервер в формате JSON. Для этого я написал серверную страницу на PHP, в которой реализовал весь необходимый API.
При передаче медиаданных пользователь запускает нужного бота и отправляет ему в личные сообщения весь необходимый материал. Отправка изображения артиста и аудиофайла выполняется напрямую, без каких-либо команд. Бот сам идентифицирует тип данных, полученных от пользователя, и записывает их в локальные файлы. Вот как я реализовал проверку принадлежности данных к типу файлов:
function isJpeg(string $data): bool { return substr($data,0,2) === "\xFF\xD8"; } function isMp3(string $data): bool { if (substr($data,0,3)==="ID3") { return true; } return isset($data[1]) && ord($data[0])===0xFF && (ord($data[1]) & 0xE0)===0xE0; }
После получения данных нужно сразу определить что именно пришло - команда или файл:
if (preg_match('/^\/(help|bio|title|tracks|done)\b/i', $data)) { processCommand($db, $uuid, $data); exit; } if (isBase64($data)) { saveBinary($db, $uuid, $data); exit; } reply("Unknown command, please use /help.", false);
Описание профиля артиста и названия его треков передаются в текстовом виде используя специальный набор команд:
/help - Show this help
/bio text - Update artist biography
/tracks - Show info of all tracks
/title text - Update current track title
/pay amount - Pay for service
/done - Finalize current track
Send JPG image to update artist image
Send MP3 audio to update current track
Используя бота, артист может отправлять свои материалы в ротацию на радио для продвижения своего творчества. Протокол взаимодействия с ботом довольно простой:
артист отправляет фото профиля
артист отправляет описание профиля
артист загружает трек
артист отправляет описание трека
артист выполняет оплату сервиса
артист финализирует трек
Пока трек не финализирован, артист может изменять любые данные. Финализация трека возможна только после выполнения всех вышеуказанных действий. После этого любые отправленные артистом данные активируют запись уже нового трека, и процесс повторяется. При этом данные профиля артиста можно изменять без ограничений.
МОНЕТИЗАЦИЯ
Отправка материала артистом требует платы за сервис. Когда артист подтверждает оплату, бот списывает с его кошелька требуемую сумму и зачисляет её на кошелек владельца радиосервиса. Это значительно упрощает обмен активами между плательщиком и получателем.
Таким образом, технология Web3 с использованием блокчейна позволяет оперативно выполнять оплату за предоставленный сервис без лишних трат и банковских процедур. При этом все транзакции становятся видны в блокчейне уже через несколько минут.
Следующим этапом разработки я планирую реализовать возможность начисления роялти каждому автору музыкального материала. Для этого потребуется создать публичную таблицу рейтинга на сайте радио, где слушатели смогут голосовать за понравившиеся треки, продвигая артиста на верх списка. Исходя из количества прослушиваний конкретного трека, можно будет рассчитать сумму роялти и автоматически выплачивать её на личный кошелек автора в мессенджере.
Таким образом, объединение двух разных сущностей, а именно интернет-радио с приложением для обмена сообщениями, является неким ноу-хау для оказания помощи в развитии молодых дарований. Лично для меня как для разработчика это отличный вызов и прекрасная возможность "пошевелить мозгами".
Если у вас появятся предложения, буду рад подискуссировать.
🤖 🤖 🤖 К счастью или сожалению, ИИ-инструменты стали нормой в сфере разработки софта. И если раньше ещё был некоторый скепсис, что «стрельнет» эта штука или нет, то теперь очевидно — либо вы освоите ИИ-инструменты, либо вы пойдёте на мороз.
Фишка ИИ заключается в том, что с ним достаточно легко получить какой-то результат, который в ряде случаев будет уместным. Однако добиться нужного результата нужного качества — достаточно сложно.
И тут у нас есть три пути:
1) Двигаться маленькими шагами, задавая ожидаемый результат ИИ-агенту. В данном случае агент полностью полагается на ваше руководство и вашу постановку и выполняет исключительно работу руками. До текущего момента я использовал именно эту технику и был вполне доволен.
2) Полагаться на итерации и самопроверку. Этот подход рекламируют разработчики ИИ-сервисов, когда вы задаёте финальную точку, а дальше ИИ-агент генерит много кода, выполняет самопроверку, удаляет большую часть, генерит её снова и так по кругу, пока не получится нужный результат. На демках это в целом работает, в реальных проектах — большие сомнения. Ну и те самые мемчики, когда разработчик тратит на токены больше, чем он зарабатывает в месяц.
3) Идеологом третьего подхода является Мэтт Покок (Matt Pocock), который предлагает технику разработки, основанную на скилах, которые сначала опрашивают тебя обо всех нюансах проекта, потом готовят документ, содержащий доменное знание. После этого разбивает задачу на маленькие таски и выполняет их, основываясь на доменное знание. Т.е. что-то из мира TDD, DDD и прочих техник.
Мне в своё время не очень зашло TDD в силу инверсии принципа разработки, которым я всегда работал. Но после ознакомления с тем, как предлагает работать Мэтт, кажется, эта штука может работать.
Cобственно, на этой неделе разбирал, как он предполагает работать, знакомился с его репозиторием скилов и дальше буду пробовать — https://github.com/mattpocock/skills
Дратути!
Только у меня, валенка, зелёно-чёрный блок с "задача упала в спринт" в ленте статей сурово тормозит браузер?
Я бы понял, кабы это только на "устройстве для чтения газет" с 1 Гб ОЗУ и малоизвестным браузером Falcon было. Но и на почти новом смартфоне с 8 Гб и Firefox - заметны подрагивания при прокрутке.
Как этого добились?
