Я как-то обдумывал идею умной новостной ленты, возможно что-то тут будет полезно.
Нужен блок разметки, который на каждую новость вешает теги, категории и другую метаинформацию (плюс под ваш сценарий персоны, страны, регионы, ...). Блок привязки который ищет по маркерам связанные новости и добавляет ссылки между ними в общий граф в базе знаний. Несколько источников пишут про одну и ту же новость немного по разному (хотя кто-то просто перепечатывает), поэтому нужен блок который схлопывает данные из нескольких источников в один общий полноценный отчет (который проходит разные проверки, чистку от воды, субъективных оценок, политической предвзятости и т.д.). У одной и той же новости могут со времнем появляться дополнения, так что нужно что-то вроде цепочки (первоначальный слив/слухи - первое упоминание - подтверждение - развитие - разрешение/результат - пост эффект). Плюс по источникам со временем могут выявляться определенные тенденции: кто первый сливает, у кого более проверенная информация на данную тему. Постепенно по разным тематикам будет нарастать рейтинг источника (по скорости, актуальности, значимости, точности). Рейтинг динамический, поэтому лучше зашивать текущие значения прямо в метаинформацию по новости (а при повторном анализе учитывать исторический и актуальный рейтинг). Ваши специализированные аналитики будут прикреплять свою метаинформацию (оценки) к каждой новости в базе знаний. Со временем сбывшиеся/неверные прогнозы можно дополнительно помечать в этой базе, типа пост-анализ/пост-мортем предсказаний с саммари (почему верно/неверно предсказано, какие данные надо было учесть, обратный поиск пропущенных сигналов по графу и т.д). Также можно делать пост-анализ для процессинга сигналов, при разделении сигнал/шум какие-то новости первоначально могут в моменте выглядеть неважными, незначительными, несвязанными, но ретроспективно являются ранними сигналами, но мне кажется тут лучше добавить отдельный блок который обучается находить именно такие крупицы информации заранее.
На текущем этапе Россия готова закончить СВО (не войну) если Украина отдаст часть территории, но Европа готова финансировать боевые действия еще пару лет, так что единственное неизвестное - это будет ли Трамп продавливать сдачу или плюнет застряв в Иране. Хотите я тоже сделаю "предсказание" на ближайший срок? В апреле-мае Китай начнет свое СВО в Тайване, с вероятностью 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.
Способ инициализации | Защита от создания невалидные объекты | Вариативность при создании объекта | Через поля | - | - | Через методы | - | + | Через конструкторы | + | + |
Стоит уточнить что в прошлом исследовании модуляция была 10 кГц, а не 1 кГц. В первом же комментарии написано, что звук проверили и он совпадает с тем что было описано в исследовании. Правда это видео доступно уже 5 лет и если бы кто-то из больных Альцгеймером уже опробовал его на себе, то об этом стало бы известно. Судя по комментариям, там максимум плацебо эффект. Ждем ссылку на видео с новым суперзвуком :)
Насколько я понимаю из 1000 задач, там от силы наберется по 3 полезных задачи на каждую категорию, а остальные это просто повторение того же самого материала с перламутровыми пуговицами.
Если вы составите свой топ 30, то возможно это будет полезнее чем абстрактные "Топ 100 залайканных задач" и "Top Interview 150". И объяснить базу по категории можно на примере Easy, а при разборе Medium и Hard уже сфокусироваться на разнице, без повторения основ.
Что будет дальше? Стена из самосборных кубиков, которая в реальном времени обновляет изображение ;) Можно еще сделать гигантский куб где каждая сторона состоит из такой стены (Las Vegas Sphere Cube)
Ребята, не стоит вскрывать эту тему. Вы молодые, технари, вам все легко. Это не то. Это не End of Life и даже не просто списали железо в архив. Сюда лучше не лезть. Серьёзно, любой, кто начнёт разбирать это глубже, потом будет жалеть. Лучше закройте тему и забудьте, что тут писалось. Я понимаю, что этим сообщением только подогрею интерес, но сразу предупреждаю пытливых - стоп. Тут нет кнопки «вернуть как было». Остальных просто не найдут.
Так и есть. Для сравнения в Корее и Турции перерабатывают одинаково, при этом у Турции в 1.6 раз больше население, а у Кореи в 1.6 раз больше ВВП.
Мне кажется ребята из РАН вначале введут 6 дневную рабочую неделю, потом график под нее 996 (+80% производительности за те же деньги), потом сделают выходной субботу и возродят добровольные субботники для уборки улиц, сбора урожая, подъема целины, стройки БАМа, ...
2K, 4K, 8K, ... это не какой-то стандарт, а общее название разных форматов, даже при попытке сделать DCI стандарт использовались разные разрешения.
Чтобы избежать такой путаницы стоило использовать подход как в камерах и считать мегапиксели, тогда Full HD = 2 MP, 4K = 8 MP, 8K = 33 MP, 16K = 133 MP, и т.д. Но я не знаю что тут победило, попытка "упростить" нумерацию или нежелание отвечать на вопрос: почему мой Xiaomi 17 Ultra снимает с разрешением 200 MP (16384х12288), а 16К телевизора на котором я мог бы это посмотреть еще не выпустили.
С этими К они зря связались. Формально 1920×1080 должен называться 2К, но при этом 4К который 3840×2160 в четыре раза больше него (а не в 2), а 8К который 7680×4320 больше в 16 раз, дальше еще хуже 15360×8640 правильнее уже называть 15К, аналогично 30720×17280 это 31К. Шринкляция как она есть. А еще маркетологи с радостью продадут вам весь диапазон вариантов от 8192×1024 до 8192×8192 под одним шильдиком 8K.
Использование терминов без понимания, зеркальная проекция собственных эмоций, нарциссическая защита, аффективная перегрузка и низкая толерантность к несогласию - это все признаки классической попытки удержать ощущение превосходства при угрозе когнитивному статусу.
Продолжайте себя закапывать, я уже запасся попкорном 🤣
Я как-то обдумывал идею умной новостной ленты, возможно что-то тут будет полезно.
Нужен блок разметки, который на каждую новость вешает теги, категории и другую метаинформацию (плюс под ваш сценарий персоны, страны, регионы, ...). Блок привязки который ищет по маркерам связанные новости и добавляет ссылки между ними в общий граф в базе знаний. Несколько источников пишут про одну и ту же новость немного по разному (хотя кто-то просто перепечатывает), поэтому нужен блок который схлопывает данные из нескольких источников в один общий полноценный отчет (который проходит разные проверки, чистку от воды, субъективных оценок, политической предвзятости и т.д.). У одной и той же новости могут со времнем появляться дополнения, так что нужно что-то вроде цепочки (первоначальный слив/слухи - первое упоминание - подтверждение - развитие - разрешение/результат - пост эффект). Плюс по источникам со временем могут выявляться определенные тенденции: кто первый сливает, у кого более проверенная информация на данную тему. Постепенно по разным тематикам будет нарастать рейтинг источника (по скорости, актуальности, значимости, точности). Рейтинг динамический, поэтому лучше зашивать текущие значения прямо в метаинформацию по новости (а при повторном анализе учитывать исторический и актуальный рейтинг). Ваши специализированные аналитики будут прикреплять свою метаинформацию (оценки) к каждой новости в базе знаний. Со временем сбывшиеся/неверные прогнозы можно дополнительно помечать в этой базе, типа пост-анализ/пост-мортем предсказаний с саммари (почему верно/неверно предсказано, какие данные надо было учесть, обратный поиск пропущенных сигналов по графу и т.д). Также можно делать пост-анализ для процессинга сигналов, при разделении сигнал/шум какие-то новости первоначально могут в моменте выглядеть неважными, незначительными, несвязанными, но ретроспективно являются ранними сигналами, но мне кажется тут лучше добавить отдельный блок который обучается находить именно такие крупицы информации заранее.
На текущем этапе Россия готова закончить СВО (не войну) если Украина отдаст часть территории, но Европа готова финансировать боевые действия еще пару лет, так что единственное неизвестное - это будет ли Трамп продавливать сдачу или плюнет застряв в Иране. Хотите я тоже сделаю "предсказание" на ближайший срок? В апреле-мае Китай начнет свое СВО в Тайване, с вероятностью 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.
Можно всю статью свести к одной табличке
Способ инициализации | Защита от создания невалидные объекты | Вариативность при создании объекта |
Через поля | - | - |
Через методы | - | + |
Через конструкторы | + | + |
Стоит уточнить что в прошлом исследовании модуляция была 10 кГц, а не 1 кГц. В первом же комментарии написано, что звук проверили и он совпадает с тем что было описано в исследовании. Правда это видео доступно уже 5 лет и если бы кто-то из больных Альцгеймером уже опробовал его на себе, то об этом стало бы известно. Судя по комментариям, там максимум плацебо эффект. Ждем ссылку на видео с новым
суперзвуком :)Правильнее было назвать "жидкое мыло"
Насколько я понимаю из 1000 задач, там от силы наберется по 3 полезных задачи на каждую категорию, а остальные это просто повторение того же самого материала с перламутровыми пуговицами.
Если вы составите свой топ 30, то возможно это будет полезнее чем абстрактные "Топ 100 залайканных задач" и "Top Interview 150". И объяснить базу по категории можно на примере Easy, а при разборе Medium и Hard уже сфокусироваться на разнице, без повторения основ.
В итоге все получили ровно то что хотели, просто никто не просчитал последствия принятого решения.
Что будет дальше? Стена из самосборных кубиков, которая в реальном времени обновляет изображение ;) Можно еще сделать гигантский куб где каждая сторона состоит из такой стены (Las Vegas
SphereCube)Ребята, не стоит вскрывать эту тему. Вы молодые, технари, вам все легко. Это не то. Это не End of Life и даже не просто списали железо в архив. Сюда лучше не лезть. Серьёзно, любой, кто начнёт разбирать это глубже, потом будет жалеть. Лучше закройте тему и забудьте, что тут писалось. Я понимаю, что этим сообщением только подогрею интерес, но сразу предупреждаю пытливых - стоп. Тут нет кнопки «вернуть как было». Остальных просто не найдут.
Я бы посмотрел этот пост в формате видео :)
Так и есть. Для сравнения в Корее и Турции перерабатывают одинаково, при этом у Турции в 1.6 раз больше население, а у Кореи в 1.6 раз больше ВВП.
Мне кажется ребята из РАН вначале введут 6 дневную рабочую неделю, потом график под нее 996 (+80% производительности за те же деньги), потом сделают выходной субботу и возродят добровольные субботники для уборки улиц, сбора урожая, подъема целины, стройки БАМа, ...
2K, 4K, 8K, ... это не какой-то стандарт, а общее название разных форматов, даже при попытке сделать DCI стандарт использовались разные разрешения.
Чтобы избежать такой путаницы стоило использовать подход как в камерах и считать мегапиксели, тогда Full HD = 2 MP, 4K = 8 MP, 8K = 33 MP, 16K = 133 MP, и т.д. Но я не знаю что тут победило, попытка "упростить" нумерацию или нежелание отвечать на вопрос: почему мой Xiaomi 17 Ultra снимает с разрешением 200 MP (16384х12288), а 16К телевизора на котором я мог бы это посмотреть еще не выпустили.
С этими К они зря связались. Формально 1920×1080 должен называться 2К, но при этом 4К который 3840×2160 в четыре раза больше него (а не в 2), а 8К который 7680×4320 больше в 16 раз, дальше еще хуже 15360×8640 правильнее уже называть 15К, аналогично 30720×17280 это 31К. Шринкляция как она есть. А еще маркетологи с радостью продадут вам весь диапазон вариантов от 8192×1024 до 8192×8192 под одним шильдиком 8K.
Использование терминов без понимания, зеркальная проекция собственных эмоций, нарциссическая защита, аффективная перегрузка и низкая толерантность к несогласию - это все признаки классической попытки удержать ощущение превосходства при угрозе когнитивному статусу.
Продолжайте себя закапывать, я уже запасся попкорном 🤣