Чтобы понять насколько мало места нужно людям для проживания:
текущее население Земли 8 000 000 000 человек
выделим на каждого человека 10х10 м для жилья, 10х10 м для работы, 10х10 м общественного пространства, итого при высоте потолков ~3 м на все потребуется куб 10х10х10 м (на семью из 3 человек это 300 м2 только жилья)
соберем все кубики вместе и получим куб 20х20х20 км, на плоскости он помещается в пределах МКАД (от Олимпийской деревни, до станции Люблино, до парка Лосиный остров и Северного речного порта)
Для сравнения Фобос (26.8 × 22.4 × 18.4 км) и Деймос (15 × 12.2 × 10.4 км)
портал невозможно открыть и обслуживать полностью автоматикой
нельзя открывать между произвольными точками
Выглядит как искуственные ограничения, чтобы не сломать сеттинг. Допустим для открытия портала нужны люди, но зачем они нужны после? Помещаем небольшой портал в замкнутую капсулу и запускаем его в любую точку (очень много капсул в очень много точек) любым двигателем. Через портал могут переходить люди для ремонта (туда и обратно), через портал можно передавать топливо на корабль, если корабль сломался - закрываем и уничтожаем. То есть буквально нужна только летающая дверь, когда она прибывает на точку через нее можно зайти и открыть портал побольше, передать все необходимые ресурсы (без риска потерять их по пути) и т.д. Это я не чтобы придраться, просто портал создает больше вопросов, а статья шикарная :)
Образование новых нейронов происходит как во взрослом, так и в очень пожилом возрасте, например в гиппокампе появляется примерно 700 новых нейронов в сутки. Процесс ослабевает при старении, но не прекращается полностью. Проверяли до 99 лет (потом видимо счетчик сбросился).
Тут немного другая история: ChromeBook'и давно заняли эту нишу, потом Apple ее расширил выкатив свой Neo, теперь Nvidia наступает со своим Spark, для x86 остается все меньше места.
Вообще никаких минусов: - Aspartame: классификация как "возможно канцерогенный", ассоциации с раком и метаболизмом (диабет, ожирение) - Acesulfame K: увеличение воспаления, связь с ожирением, диабетом 2 типа и сердечно-сосудистыми заболеваниями - Sodium cyclamate: нарушения липидного профиля и функции почек/печени, долгосрочная токсичность и канцерогенность - Sucralose: метаболические нарушения, воспаления, дисбиоз микробиома и повреждения печени
Я как-то обдумывал идею умной новостной ленты, возможно что-то тут будет полезно.
Нужен блок разметки, который на каждую новость вешает теги, категории и другую метаинформацию (плюс под ваш сценарий персоны, страны, регионы, ...). Блок привязки который ищет по маркерам связанные новости и добавляет ссылки между ними в общий граф в базе знаний. Несколько источников пишут про одну и ту же новость немного по разному (хотя кто-то просто перепечатывает), поэтому нужен блок который схлопывает данные из нескольких источников в один общий полноценный отчет (который проходит разные проверки, чистку от воды, субъективных оценок, политической предвзятости и т.д.). У одной и той же новости могут со времнем появляться дополнения, так что нужно что-то вроде цепочки (первоначальный слив/слухи - первое упоминание - подтверждение - развитие - разрешение/результат - пост эффект). Плюс по источникам со временем могут выявляться определенные тенденции: кто первый сливает, у кого более проверенная информация на данную тему. Постепенно по разным тематикам будет нарастать рейтинг источника (по скорости, актуальности, значимости, точности). Рейтинг динамический, поэтому лучше зашивать текущие значения прямо в метаинформацию по новости (а при повторном анализе учитывать исторический и актуальный рейтинг). Ваши специализированные аналитики будут прикреплять свою метаинформацию (оценки) к каждой новости в базе знаний. Со временем сбывшиеся/неверные прогнозы можно дополнительно помечать в этой базе, типа пост-анализ/пост-мортем предсказаний с саммари (почему верно/неверно предсказано, какие данные надо было учесть, обратный поиск пропущенных сигналов по графу и т.д). Также можно делать пост-анализ для процессинга сигналов, при разделении сигнал/шум какие-то новости первоначально могут в моменте выглядеть неважными, незначительными, несвязанными, но ретроспективно являются ранними сигналами, но мне кажется тут лучше добавить отдельный блок который обучается находить именно такие крупицы информации заранее.
На текущем этапе Россия готова закончить СВО (не войну) если Украина отдаст часть территории, но Европа готова финансировать боевые действия еще пару лет, так что единственное неизвестное - это будет ли Трамп продавливать сдачу или плюнет застряв в Иране. Хотите я тоже сделаю "предсказание" на ближайший срок? В апреле-мае Китай начнет свое СВО в Тайване, с вероятностью 45-55% :)
Исторический прогон тут бесполезен, в процессе обучения модели видели все эти данные в том или ином виде. Мне кажется в вашей схеме нужен LLM Council, когда у вас не 1 аналитик на 1 тему, а несколько одинаковых аналитиков на разных моделях обсуждающие между собой 1 новость, по моим опытам, так они хорошо дополняют и исправляют друг друга. Ну и в отчете обязательно должны быть ссылки на источники, тогда меньше галлюцинаций (в рамках одной и той же модели это не работает, модель "верит" своим бредовым ссылка не проверяя их). Тогда ваш скептик может больше уделить внимание анализу финальных оценок, а не перепроверке методологии и данных.
Вам же сказали, по теории заговора американцы не летели на Луну на Апполонах, а использовали для этого собственные летающие тарелки, но их оттуда прогнали местные наблюдатели за Землей, которые разрешили взять с собой только лунный грунт.
Публичный API, не требует отключения SIP. Привязывает ключ в Secure Enclave к конкретному App ID (Team ID + Bundle ID) и выдаёт сертификатную цепочку, подписанную Apple
let service = DCAppAttestService.shared
let keyId = try await service.generateKey()
let attestation = try await service.attestKey(keyId, clientDataHash: SHA256(challenge))
2. Notarization Ticket как доказательство хеша бинарника
Тикет можно извлечь из bundle и отправить удалённой стороне, она верифицирует подпись Apple и извлекает хеш. Публичный ключ Apple для проверки тикетов встроен в macOS и задокументирован. Notarization Ticket нужно уметь парсить (формат Apple Binary Property List внутри .dmg-style структуры). Формат не документирован официально, но хорошо изучен если поискать.
3. SecCode API для получения cdHash запущенного процесса
var code: SecCode?
SecCodeCopySelf([], &code) // code текущего процесса
var info: CFDictionary?
SecCodeCopySigningInformation(code as! SecStaticCode,
SecCSFlags(rawValue: kSecCSSigningInformation),
&info)
let cdHash = (info as! [String: Any])[kSecCodeInfoCdHash as String]
// cdHash — SHA-1 или SHA-256 кодовой подписи, тот же, что в notarization ticket
Это системный вызов, а не self-report приложения - ядро macOS возвращает данные из code signature structure, и подделать их без отключения SIP нельзя
Давайте я просто наброшу на вентилятор. Автор смешивает в одну кучу commit и merge (pull) request, а это не одно и то же. Попытка сделать атомарные коммиты разбивается о реальность, когда простые изменения можно сделать поэтапно, а большие нет. Но в простых от них и нет особой пользы, а в итоге проблема с большими изменениями так и не решена. Описание для request'а это уже по сути задача сборки change log'а или release notes, да полезно, но описание в 3 абзаца не помогает понять где именно эти изменения были произведены и не добавляет им атомарности. Для любителей раCCовой частоты Git истории со squash коммитами при мерже специально заготовлен отдельный котел.
В итоге это все происходит от изначального несовершенства инструментария, когда мы заставляем человека руками менеджить состояние кода и выстраивать чепочку истории, вместо того чтобы сохранять список всех изменений (как для undo/redo лога) с автоматической сборкой каждой промежуточной версии (итеративно, с пометкой о ее работоспособности). Сейчас же память дешевая (ха-ха) давно пора уже перейти на continuous version control.
А какой смысл вообще считать энергоэффективность и плотность транзисторов? Это же не сборка сервера в датацентре, вы в любом случае будете платить и за электричество и за охлаждение после покупки, какими бы неэффективными они не были. Пользователю интересно только latency и throughput процессора, которые в итоге выливаются в один показатель "за какое время процессор может решить мои задачи". Не абстрактный список задач Васи Пупкина, а вполне конкретный список задач пользователя. При этом у пользователя может быть формальная отсечка "нерешаемости задач" (чаще всего это значит не невозможно решить, а слишком долго/медленно), которая и должна определять факт покупки, а дальше это просто торг с собой насколько много он готов заплатить за ускорение решения задач. При анализе это выливается в график, где на одной оси TCO (да это сложно), а на другой общее время выполнения (время каждой задачи х частота задач за интервал), по которому потом строится Pareto Frontier.
Чтобы понять насколько мало места нужно людям для проживания:
текущее население Земли 8 000 000 000 человек
выделим на каждого человека 10х10 м для жилья, 10х10 м для работы, 10х10 м общественного пространства, итого при высоте потолков ~3 м на все потребуется куб 10х10х10 м (на семью из 3 человек это 300 м2 только жилья)
соберем все кубики вместе и получим куб 20х20х20 км, на плоскости он помещается в пределах МКАД (от Олимпийской деревни, до станции Люблино, до парка Лосиный остров и Северного речного порта)
Для сравнения Фобос (26.8 × 22.4 × 18.4 км) и Деймос (15 × 12.2 × 10.4 км)
Выглядит как искуственные ограничения, чтобы не сломать сеттинг. Допустим для открытия портала нужны люди, но зачем они нужны после? Помещаем небольшой портал в замкнутую капсулу и запускаем его в любую точку (очень много капсул в очень много точек) любым двигателем. Через портал могут переходить люди для ремонта (туда и обратно), через портал можно передавать топливо на корабль, если корабль сломался - закрываем и уничтожаем. То есть буквально нужна только летающая дверь, когда она прибывает на точку через нее можно зайти и открыть портал побольше, передать все необходимые ресурсы (без риска потерять их по пути) и т.д. Это я не чтобы придраться, просто портал создает больше вопросов, а статья шикарная :)
Образование новых нейронов происходит как во взрослом, так и в очень пожилом возрасте, например в гиппокампе появляется примерно 700 новых нейронов в сутки. Процесс ослабевает при старении, но не прекращается полностью. Проверяли до 99 лет (потом видимо счетчик сбросился).
Вот исследование 2026 года https://www.nature.com/articles/s41586-026-10169-4
Вот тут зафиксировано увеличение теломер
https://x.com/bryan_johnson/status/1912969682300411956
Ага, вот настоящее видео
Тут немного другая история: ChromeBook'и давно заняли эту нишу, потом Apple ее расширил выкатив свой Neo, теперь Nvidia наступает со своим Spark, для x86 остается все меньше места.
Сложно закопать себя глубже, но вы стараетесь.
Круто! То есть у вас программист работает 4 часа в день за ту же зарплату и идет домой
Итого:
выкинули дизайнера, картинки же клепать много ума не надо
нагрузили менеджера непрофильной работой, но так как он "свой" отдали ему пол-зарплаты дизайнера
главное что программист теперь делает в 2 раза больше работы и получает за это ... в 2 раза больше работы
все остально кладем к себе в карман
Все что стоит знать про эффективных менеджеров
Канешна! Это как рефлекс, вижу слив, качаю пока не закрыли :)
Для начала там проблемы с контроллером, который им лень оптимизировать, на youtube ребята разгоняли до приемлиемой частоты.
Ну и https://daylightcomputer.com/product говорит "ну да, ну да, пошел я нахер"
И все остальное в духе AI slop: "сам придумал"
Никогда так не делайте!
Вообще никаких минусов:
- Aspartame: классификация как "возможно канцерогенный", ассоциации с раком и метаболизмом (диабет, ожирение)
- Acesulfame K: увеличение воспаления, связь с ожирением, диабетом 2 типа и сердечно-сосудистыми заболеваниями
- Sodium cyclamate: нарушения липидного профиля и функции почек/печени, долгосрочная токсичность и канцерогенность
- Sucralose: метаболические нарушения, воспаления, дисбиоз микробиома и повреждения печени
Я как-то обдумывал идею умной новостной ленты, возможно что-то тут будет полезно.
Нужен блок разметки, который на каждую новость вешает теги, категории и другую метаинформацию (плюс под ваш сценарий персоны, страны, регионы, ...). Блок привязки который ищет по маркерам связанные новости и добавляет ссылки между ними в общий граф в базе знаний. Несколько источников пишут про одну и ту же новость немного по разному (хотя кто-то просто перепечатывает), поэтому нужен блок который схлопывает данные из нескольких источников в один общий полноценный отчет (который проходит разные проверки, чистку от воды, субъективных оценок, политической предвзятости и т.д.). У одной и той же новости могут со времнем появляться дополнения, так что нужно что-то вроде цепочки (первоначальный слив/слухи - первое упоминание - подтверждение - развитие - разрешение/результат - пост эффект). Плюс по источникам со временем могут выявляться определенные тенденции: кто первый сливает, у кого более проверенная информация на данную тему. Постепенно по разным тематикам будет нарастать рейтинг источника (по скорости, актуальности, значимости, точности). Рейтинг динамический, поэтому лучше зашивать текущие значения прямо в метаинформацию по новости (а при повторном анализе учитывать исторический и актуальный рейтинг). Ваши специализированные аналитики будут прикреплять свою метаинформацию (оценки) к каждой новости в базе знаний. Со временем сбывшиеся/неверные прогнозы можно дополнительно помечать в этой базе, типа пост-анализ/пост-мортем предсказаний с саммари (почему верно/неверно предсказано, какие данные надо было учесть, обратный поиск пропущенных сигналов по графу и т.д). Также можно делать пост-анализ для процессинга сигналов, при разделении сигнал/шум какие-то новости первоначально могут в моменте выглядеть неважными, незначительными, несвязанными, но ретроспективно являются ранними сигналами, но мне кажется тут лучше добавить отдельный блок который обучается находить именно такие крупицы информации заранее.
На текущем этапе Россия готова закончить СВО (не войну) если Украина отдаст часть территории, но Европа готова финансировать боевые действия еще пару лет, так что единственное неизвестное - это будет ли Трамп продавливать сдачу или плюнет застряв в Иране. Хотите я тоже сделаю "предсказание" на ближайший срок? В апреле-мае Китай начнет свое СВО в Тайване, с вероятностью 45-55% :)
Исторический прогон тут бесполезен, в процессе обучения модели видели все эти данные в том или ином виде. Мне кажется в вашей схеме нужен LLM Council, когда у вас не 1 аналитик на 1 тему, а несколько одинаковых аналитиков на разных моделях обсуждающие между собой 1 новость, по моим опытам, так они хорошо дополняют и исправляют друг друга. Ну и в отчете обязательно должны быть ссылки на источники, тогда меньше галлюцинаций (в рамках одной и той же модели это не работает, модель "верит" своим бредовым ссылка не проверяя их). Тогда ваш скептик может больше уделить внимание анализу финальных оценок, а не перепроверке методологии и данных.
Вам же сказали, по теории заговора американцы не летели на Луну на Апполонах, а использовали для этого собственные летающие тарелки, но их оттуда прогнали местные наблюдатели за Землей, которые разрешили взять с собой только лунный грунт.
App Attest + Notarization Ticket + SecCode API
1. DCAppAttestService (macOS 14+)
Публичный API, не требует отключения SIP. Привязывает ключ в Secure Enclave к конкретному App ID (Team ID + Bundle ID) и выдаёт сертификатную цепочку, подписанную Apple
2. Notarization Ticket как доказательство хеша бинарника
При нотаризации Apple выдаёт тикет, который:
криптографически подписан Apple,
содержит cdHash нотаризованного бинарника,
стаплируется в bundle (
xcrun stapler staple).Тикет можно извлечь из bundle и отправить удалённой стороне, она верифицирует подпись Apple и извлекает хеш. Публичный ключ Apple для проверки тикетов встроен в macOS и задокументирован. Notarization Ticket нужно уметь парсить (формат Apple Binary Property List внутри
.dmg-style структуры). Формат не документирован официально, но хорошо изучен если поискать.3. SecCode API для получения cdHash запущенного процесса
Это системный вызов, а не self-report приложения - ядро macOS возвращает данные из code signature structure, и подделать их без отключения SIP нельзя
Вся цепочка выглядит как-то так
Давайте я просто наброшу на вентилятор. Автор смешивает в одну кучу commit и merge (pull) request, а это не одно и то же. Попытка сделать атомарные коммиты разбивается о реальность, когда простые изменения можно сделать поэтапно, а большие нет. Но в простых от них и нет особой пользы, а в итоге проблема с большими изменениями так и не решена. Описание для request'а это уже по сути задача сборки change log'а или release notes, да полезно, но описание в 3 абзаца не помогает понять где именно эти изменения были произведены и не добавляет им атомарности. Для любителей
раCCовойчастоты Git истории со squash коммитами при мерже специально заготовлен отдельный котел.В итоге это все происходит от изначального несовершенства инструментария, когда мы заставляем человека руками менеджить состояние кода и выстраивать чепочку истории, вместо того чтобы сохранять список всех изменений (как для undo/redo лога) с автоматической сборкой каждой промежуточной версии (итеративно, с пометкой о ее работоспособности). Сейчас же память дешевая (
ха-ха) давно пора уже перейти на continuous version control.А какой смысл вообще считать энергоэффективность и плотность транзисторов? Это же не сборка сервера в датацентре, вы в любом случае будете платить и за электричество и за охлаждение после покупки, какими бы неэффективными они не были. Пользователю интересно только latency и throughput процессора, которые в итоге выливаются в один показатель "за какое время процессор может решить мои задачи". Не абстрактный список задач Васи Пупкина, а вполне конкретный список задач пользователя. При этом у пользователя может быть формальная отсечка "нерешаемости задач" (чаще всего это значит не невозможно решить, а слишком долго/медленно), которая и должна определять факт покупки, а дальше это просто торг с собой насколько много он готов заплатить за ускорение решения задач. При анализе это выливается в график, где на одной оси TCO (да это сложно), а на другой общее время выполнения (время каждой задачи х частота задач за интервал), по которому потом строится Pareto Frontier.