А можно расшифровать, что происходит по этой ссылке? Там предлагается по 10 элементов промотать список из 21 702 страниц, либо скачать один из заготовленных дампов. Никаких сумм не видно. По-моему, не жизнеспособный способ посчитать суточный объём транзакций.
Вопрос был, я так понимаю, в том, чтобы сравнить суточный объём транзакций в BTC и суточный объём транзакций в стандартных, подконтрольных правительствам, финансовых инструментах. У вас есть чуть более готовые к обработке прикидки по этим вопросам?
Возможно потому, что вы закрываете не приложение Firefox, а его последнее окно. В маке приложение остаётся открытым, даже когда у него нету окон. Соответственно, чтобы открытые окна/вкладки сохранились, надо выходить через cmd+q или "quit" в контекстном меню.
А с полноэкранным режимом сам не понимаю, он есть, но почему-то на маке он не прячет вкладки и адресную строку, как на винде.
Да, всё верно, награды я опустил, чтобы не перегружать сообщение.
Идея с нулями появилась скорее всего для наглядности, т.к. интуитивно вывод sha256 люди представляют как строку hex-значений, а не как офигенно длинное число. А что нули должны быть в начале, а не в конце, это уже я перепутал.
Думаю, программистам будет понятнее описание, как на самом деле работает PoW в BTC, чем эта запутанная аналогия с лотерейными билетами:
Берутся данные о транзакциях между разными кошельками, требующих подтверждения (из них будет состоять так называемый "блок" транзакций)
К ним конкатенируется хэш предыдущего блока
К ним в конце конкатенируется выбранное майнером число N
От всего этого берётся хэш SHA256
Если результат вычисления хэша оканчивается на заданное количество нулей — значит майнер "выиграл" и произвёл валидный блок.
Если не получилось, нужно взять другое N и попробовать ещё раз (те самые в среднем 10 миллиардов раз).
Благодаря этому, произвести валидный блок очень "дорого" по электричеству, а проверить валидность цепочки блоков легко. Достаточно проверить что хэш блока содержит заданное количество нулей, проверить что блок содержит валидный хэш прошлого блока и дальше можно провести такие же проверки с прошлым, позапрошлым и т.д. блоками.
Если личным примером отвечать, я стараюсь из своих путешествий снимать видео на дрон, делать подсъёмку на телефон (просто потому что он мелкий и с собой) или экшн камеру, потом монтировать из этого какой-то красивый ролик под музыку. Себе на память, друзьям показать.
Я не могу это назвать хоть сколько-нибудь профессиональным, но тем не менее, когда на кадре поползла вверх автоматическая экспозиция, этот кадр для меня испорчен, он будет бросаться в глаза и смотреться некрасиво в монтаже.
Света и декораций нет, но переснять в этом случае зачастую невозможно, потому что снимаются конкретные события, это всё делается в пути и на бегу.
Скорее всего, наработки производителей в этой области появились раньше, чем соответствующие фичи Camera2 API. А потом они просто развивают и поддерживают существующий код — это просто дешевле, чем переписывать с нуля на Camera2 свои апы. А т.к. их камеры работают на своих API, Camera2 у них всегда будет в полураздолбанном состоянии чисто "чтобы было".
Тут реально только ждать пока Гугл потребует обязательную полную реализацию.
Я на очень простом примере могу рассказать. Если мы снимаем пьянку с друзьями, то важно, чтобы телефон постоянно подстраивал фокус, экспозицию, баланс белого и всё остальное, чтобы максимум действий и лиц в кадре были видны. Это требование любителей к видеосъёмке, под него заточены все телефоны и их стандартные приложения.
Алгоритм съёмки фильмов/роликов/блогов и т.д. другой. Там мы ставим кадр, готовим свет, актёров, декорации, настраиваем камеру. Потом мы даём "мотор" и снимаем дубль.
Дубль стоит денег: актёры работают, декорации рушатся, трюки делаются и т.д. И если телефон в процессе съёмки дёрнет по своему усмотрению экспозицию, фокус, ББ, включит HDR или как угодно ещё резко изменит картинку, мы получаем испорченный дубль.
Будь при этом картинка хоть 8к120фпс с божественными цветами и супер динамическим диапазоном, это будет просто очень красивый испорченный дубль, который невозможно использовать на монтаже.
Поэтому, для такой съёмки возможность предотвратить внезапное изменение настроек важнее, чем аппаратные характеристики модуля. Это базовое требование, без которого профессиональная съёмка невозможна.
Да первопричина вполне понятна. Android допиливает Google, он делает туда какие-то общие для всех одинаковые фичи.
Производители вынуждены добавлять какие-то свои фишечки, чтобы получить конкурентное преимущество — телефон, в котором всё точно так же как во всех остальных никто не будет покупать.
Когда ты делаешь эти фишечки, у тебя абсолютно нулевая мотивация делать к ним открытый API: это надо тратить время, тестировать, релизить, потом годами поддерживать, а 99% разработчиков не будут никак этим пользоваться.
Разработчики используют Android SDK и Android Studio со стандартными наборами библиотек, работающих на всех девайсах, они не думают "о а тут можно сделать настройку 60FPS для девайсов Huawei, если я подключу и реализую отдельно поддержку Huawei Camera Library". Есть такие маньяки как автор статьи, которые готовы костылить апу под все отдельные девайсы, но таких единицы.
Получается как:
Производители пилят свои фичи в закрытую (т.к. см. выше)
В итоге есть 10 разных реализаций одной и той же фичи
Гугл видит что фича кажись с нами надолго, делает стандартную реализацию фичи
Если это не помогает перейти на стандартную реализацию (как в случае с Camera2 и 60FPS), гугл добавляет требование поддержки этой реализации в правила сертификации андроид устройств.
Получается, если гугл добавит "необходимо полностью поддерживать все методы Camera2 API" в требования к сертификации, то девайсы, которые этого не делают, не смогут поставляться с гугл сервисами на борту. Т.е. хэппиэнд вроде как тут будет, но вот только этот цикл очень длинный и может занимать 3-5 лет запросто. А за эти 3 года появятся новые маст-хэв фичи и весь цикл по новой.
У Apple такой проблемы нет, разработка оси привязана к разработке железа под неё. Андроиду надо как-то глобально придумывать решение этой проблемы. Если бы у разработчиков был некий консорциум, как у веба, чтобы по их совместному решению реализация этих фич добавлялась именно в стандартное API андроида, было бы лучше.
А как именно вы проверили, что он мощнее? Про M1 Max пока что из инфы только тот факт, что у него больше 150 "единиц относительной производительности" с графика Apple.
Ну ждать тестов тут было никак нельзя, кликбейт же убежит.
Хех, в статье есть мысль про то, что процессоры надо сравнивать на "лучших тестах для реального мира". А в реальном мире что-то производительность javascript, увы, уже важнее, чем всё что угодно чем там ещё занимается процессор.
Мне кажется, проблема не связана с пушами, просто техподдержка распарсила ключевые слова "пришёл перевод" и ответила стандартной фразой "у вас отключены уведомления", не вдаваясь дальше, о чём там вы говорили.
>>Да, так получилось, что файлы я открываю из соответствующих программ (xcode, photoshop, etc) — а в Finder, как я уже написал, я их просто просматриваю «пробелом». Или переименовываю.
А есть какие-то удобные способы это делать в макос? Я так понимаю, в перечисленных программах свои кастомные диалоги открытия файлов, там кто во что горазд.
А где есть стандартный диалог, я бы не сказал, что пользоваться им удобнее, чем finder, очень даже наоборот. Или я что-то не знаю, есть какие-то трюки?
Про Windows могу рассказать один трюк, который меня сильно выручает. Часто файл открывают после каких-то других с ним действий: скачали - надо расшарить, отредактировали - надо конвертировать и т.д. Так вот, в Windows проводнике можно нажать ctrl+c на файле и в любом диалоге открытия файла нажать ctrl+v, туда сразу вставится путь до этого файла. Вот по этой теме у меня прям ломка, когда за макбуком сижу.
Точно видео. Вкодировать во все PS5-поддерживающие игры (большинство из которых это просто ps4 игры) поддержку воспроизводимых реплеев, в том числе в онлайне — слишком жёсткая задачка.
Хм, много раз слышал, что в сторонних прошивках регулируется автозапуск приложения, даже видел это в оболочках мелких производителей. Если запретить автозапуск и "смахнуть" приложение, оно не будет работать в фоне.
То, которое надо чтобы работало, чаще всего достаточно добавить в исключения энергосбережения. Если приложение вообще умеет работать в фоне и рассчитано на это. Ну и с Android 12 не знаю что случится, не пробовал.
А можно расшифровать, что происходит по этой ссылке? Там предлагается по 10 элементов промотать список из 21 702 страниц, либо скачать один из заготовленных дампов. Никаких сумм не видно. По-моему, не жизнеспособный способ посчитать суточный объём транзакций.
Вопрос был, я так понимаю, в том, чтобы сравнить суточный объём транзакций в BTC и суточный объём транзакций в стандартных, подконтрольных правительствам, финансовых инструментах. У вас есть чуть более готовые к обработке прикидки по этим вопросам?
Эх, одни из моих любимых статей википедии
Незаконное число
Незаконное простое число
Возможно потому, что вы закрываете не приложение Firefox, а его последнее окно. В маке приложение остаётся открытым, даже когда у него нету окон. Соответственно, чтобы открытые окна/вкладки сохранились, надо выходить через cmd+q или "quit" в контекстном меню.
А с полноэкранным режимом сам не понимаю, он есть, но почему-то на маке он не прячет вкладки и адресную строку, как на винде.
Да, всё верно, награды я опустил, чтобы не перегружать сообщение.
Идея с нулями появилась скорее всего для наглядности, т.к. интуитивно вывод sha256 люди представляют как строку hex-значений, а не как офигенно длинное число. А что нули должны быть в начале, а не в конце, это уже я перепутал.
Думаю, программистам будет понятнее описание, как на самом деле работает PoW в BTC, чем эта запутанная аналогия с лотерейными билетами:
Берутся данные о транзакциях между разными кошельками, требующих подтверждения (из них будет состоять так называемый "блок" транзакций)
К ним конкатенируется хэш предыдущего блока
К ним в конце конкатенируется выбранное майнером число N
От всего этого берётся хэш SHA256
Если результат вычисления хэша оканчивается на заданное количество нулей — значит майнер "выиграл" и произвёл валидный блок.
Если не получилось, нужно взять другое N и попробовать ещё раз (те самые в среднем 10 миллиардов раз).
Благодаря этому, произвести валидный блок очень "дорого" по электричеству, а проверить валидность цепочки блоков легко. Достаточно проверить что хэш блока содержит заданное количество нулей, проверить что блок содержит валидный хэш прошлого блока и дальше можно провести такие же проверки с прошлым, позапрошлым и т.д. блоками.
Провод USB-C — Lightning, серьёзно? А может по ИК-порту передавать?
Почему инновации WhatsApp такие стыдные, передача чатов по проводу в 2021 году.
Если личным примером отвечать, я стараюсь из своих путешествий снимать видео на дрон, делать подсъёмку на телефон (просто потому что он мелкий и с собой) или экшн камеру, потом монтировать из этого какой-то красивый ролик под музыку. Себе на память, друзьям показать.
Я не могу это назвать хоть сколько-нибудь профессиональным, но тем не менее, когда на кадре поползла вверх автоматическая экспозиция, этот кадр для меня испорчен, он будет бросаться в глаза и смотреться некрасиво в монтаже.
Света и декораций нет, но переснять в этом случае зачастую невозможно, потому что снимаются конкретные события, это всё делается в пути и на бегу.
Скорее всего, наработки производителей в этой области появились раньше, чем соответствующие фичи Camera2 API. А потом они просто развивают и поддерживают существующий код — это просто дешевле, чем переписывать с нуля на Camera2 свои апы. А т.к. их камеры работают на своих API, Camera2 у них всегда будет в полураздолбанном состоянии чисто "чтобы было".
Тут реально только ждать пока Гугл потребует обязательную полную реализацию.
Я на очень простом примере могу рассказать. Если мы снимаем пьянку с друзьями, то важно, чтобы телефон постоянно подстраивал фокус, экспозицию, баланс белого и всё остальное, чтобы максимум действий и лиц в кадре были видны. Это требование любителей к видеосъёмке, под него заточены все телефоны и их стандартные приложения.
Алгоритм съёмки фильмов/роликов/блогов и т.д. другой. Там мы ставим кадр, готовим свет, актёров, декорации, настраиваем камеру. Потом мы даём "мотор" и снимаем дубль.
Дубль стоит денег: актёры работают, декорации рушатся, трюки делаются и т.д. И если телефон в процессе съёмки дёрнет по своему усмотрению экспозицию, фокус, ББ, включит HDR или как угодно ещё резко изменит картинку, мы получаем испорченный дубль.
Будь при этом картинка хоть 8к120фпс с божественными цветами и супер динамическим диапазоном, это будет просто очень красивый испорченный дубль, который невозможно использовать на монтаже.
Поэтому, для такой съёмки возможность предотвратить внезапное изменение настроек важнее, чем аппаратные характеристики модуля. Это базовое требование, без которого профессиональная съёмка невозможна.
Да первопричина вполне понятна. Android допиливает Google, он делает туда какие-то общие для всех одинаковые фичи.
Производители вынуждены добавлять какие-то свои фишечки, чтобы получить конкурентное преимущество — телефон, в котором всё точно так же как во всех остальных никто не будет покупать.
Когда ты делаешь эти фишечки, у тебя абсолютно нулевая мотивация делать к ним открытый API: это надо тратить время, тестировать, релизить, потом годами поддерживать, а 99% разработчиков не будут никак этим пользоваться.
Разработчики используют Android SDK и Android Studio со стандартными наборами библиотек, работающих на всех девайсах, они не думают "о а тут можно сделать настройку 60FPS для девайсов Huawei, если я подключу и реализую отдельно поддержку Huawei Camera Library". Есть такие маньяки как автор статьи, которые готовы костылить апу под все отдельные девайсы, но таких единицы.
Получается как:
Производители пилят свои фичи в закрытую (т.к. см. выше)
В итоге есть 10 разных реализаций одной и той же фичи
Гугл видит что фича кажись с нами надолго, делает стандартную реализацию фичи
Если это не помогает перейти на стандартную реализацию (как в случае с Camera2 и 60FPS), гугл добавляет требование поддержки этой реализации в правила сертификации андроид устройств.
Получается, если гугл добавит "необходимо полностью поддерживать все методы Camera2 API" в требования к сертификации, то девайсы, которые этого не делают, не смогут поставляться с гугл сервисами на борту. Т.е. хэппиэнд вроде как тут будет, но вот только этот цикл очень длинный и может занимать 3-5 лет запросто. А за эти 3 года появятся новые маст-хэв фичи и весь цикл по новой.
У Apple такой проблемы нет, разработка оси привязана к разработке железа под неё. Андроиду надо как-то глобально придумывать решение этой проблемы. Если бы у разработчиков был некий консорциум, как у веба, чтобы по их совместному решению реализация этих фич добавлялась именно в стандартное API андроида, было бы лучше.
Ну с блоком камер я согласен. Как в mi 11 ultra: по крайней мере телефон нормально на столе будет лежать, а не шататься.
А как именно вы проверили, что он мощнее? Про M1 Max пока что из инфы только тот факт, что у него больше 150 "единиц относительной производительности" с графика Apple.
Ну ждать тестов тут было никак нельзя, кликбейт же убежит.
Ещё можно сделать из PLA и эксплуатировать и в большинстве случаев ничего ему не будет :)
Хитрый ход, но и разработчики не лыком шиты. Они добавят на бэкенд баги, которые будут ломать именно старые версии приложения.
Хех, в статье есть мысль про то, что процессоры надо сравнивать на "лучших тестах для реального мира". А в реальном мире что-то производительность javascript, увы, уже важнее, чем всё что угодно чем там ещё занимается процессор.
Мне кажется, проблема не связана с пушами, просто техподдержка распарсила ключевые слова "пришёл перевод" и ответила стандартной фразой "у вас отключены уведомления", не вдаваясь дальше, о чём там вы говорили.
>>Да, так получилось, что файлы я открываю из соответствующих программ (xcode, photoshop, etc) — а в Finder, как я уже написал, я их просто просматриваю «пробелом». Или переименовываю.
А есть какие-то удобные способы это делать в макос? Я так понимаю, в перечисленных программах свои кастомные диалоги открытия файлов, там кто во что горазд.
А где есть стандартный диалог, я бы не сказал, что пользоваться им удобнее, чем finder, очень даже наоборот. Или я что-то не знаю, есть какие-то трюки?
Про Windows могу рассказать один трюк, который меня сильно выручает. Часто файл открывают после каких-то других с ним действий: скачали - надо расшарить, отредактировали - надо конвертировать и т.д. Так вот, в Windows проводнике можно нажать ctrl+c на файле и в любом диалоге открытия файла нажать ctrl+v, туда сразу вставится путь до этого файла. Вот по этой теме у меня прям ломка, когда за макбуком сижу.
Точно видео. Вкодировать во все PS5-поддерживающие игры (большинство из которых это просто ps4 игры) поддержку воспроизводимых реплеев, в том числе в онлайне — слишком жёсткая задачка.
Забавно, что перекодировщик хабра из 31кб оригинальной картинки сгенерировал 144кб "уменьшенную версию" :)
Я сначала скачал её и, естественно, ничего не сработало. Если что, на ПК надо нажать на картинку для зума и только потом её скачать.
Хм, много раз слышал, что в сторонних прошивках регулируется автозапуск приложения, даже видел это в оболочках мелких производителей. Если запретить автозапуск и "смахнуть" приложение, оно не будет работать в фоне.
То, которое надо чтобы работало, чаще всего достаточно добавить в исключения энергосбережения. Если приложение вообще умеет работать в фоне и рассчитано на это. Ну и с Android 12 не знаю что случится, не пробовал.