У автора цитаты (Larry McVoy = luckydude@HN = владелец BitKeeper) дальше было ещё два абзаца:
It says a lot that we have a bk fast-export and we can incrementally run that and get idempotent results. As in go from BK to Git on an ongoing basis, have two people do it in parallel and they both get bit for bit identical results. If you try and go the other way, Git -> BK, if you do it in parallel you get different results because Git doesn't store enough information, so BK has to make up the missing bits.
Git has no file create|delete|rename history, it just guesses. That's my biggest regret, I wish Linus had copied that part.
Вообще, на HN это место в статье тоже вызвало вопросы ("Why is this crappy? What would be better?"), но Ларри явился в комменты и ещё прошёлся по Git'у.
Там есть история правок, источники и их архивация ботами (на archive.org и .is), зачем такой пример в разговоре про потерю информации? Так же странно говорить об одном полном видео - его просто не может быть, начать надо с двухсот девяти ютубовских роликов группы 2 мая.
Демагог. Посмотри ещё на глупых учоных - не хотят от неактуальной инфы отказываться. Инфа из интернета самоустраниться пытается, а они ссылку на архив ставят, гады.
Утверждение про частоту примером не доказать, нужно исследование, вряд ли такое есть.
В целом о проблеме доступности: думаю, кому статья актуальна, те и так знают, что меньше месяца назад кэш гугла как сервис закрыли, или что около 2000 сайтов целиком исключено из archive.org. Или имеют свои какие-то свои примеры на тему работы с источниками.
Из кэша гугла можно было вытащить недавно удалённую или изменённую информацию, всё ещё попадающую в выдачу (остались кэши бинга и яндекса).
они скорее встанут в очередь, чем каждое успеет загрузиться на 10% или сколько нужно для генерации первого тира.
Надо 10-15%, чтобы браузер начал отрисовывать jpeg (он ждёт DC-коэффициенты всех каналов; можно отрисовывать ч/б раньше, но в браузерах так не принято),
В идеале нужна параллельная загрузка 10-15% всех картинок, Cloudflare в 2019 году пишет[1][2], что HTTP/2 что-то такое позволяет (с оговоркой про хром и поддержку серверами...).
Что придет ей на смену? Многие говорят, это будет что-то, связанное с искусственным интеллектом, но никто не может сказать наверняка. Что мы можем сказать точно: скорее всего, новый этап будет связан с рядом случайных событий и группой талантливых хакеров.
Нынешний успех Git'а связан с гитхабом, с авторитетом Линуса. Почему ситуацию должны изменить технические причины? Думаю, Git с нами до конца, он постепенно растворится в централизованных хостингах - будет всё менее важно, что у них под капотом - Git, что-то Git-совместимое или уже несовместимое, потому что хостинг будет всё дальше обрастать функцональностью и VCS будет лишь рядовой функцией среди прочих.
Жизненный пример, в википедии кто-то умудрился написать: "GitLab includes a distributed version control based on Git, including features such as access control, bug tracking...". Что включает в себя VCS, что децентрализовано, используется ли сам Git? Мы ответы знаем, но они не так уж и важны, это единая платформа. Буква D в DVCS теряет своё значение, гипотетические VCS будущего могут снова стать централизованными, It's Evolving, Just Backwards.
Принципиально новое можно внедрять в хостинг или прямо в Git, за деньги его получится развивать в нужном такой-то компании направлении (будет Git Foundation и Platinum Membership).
Идея круть, но реализация местами "чисто для себя". Багтрекеру (можно посмотреть на него в репозитории самого Fossil'а) далеко до гитхаба, гитлаба, багзиллы, первых версий багзиллы... и вот мы уже в 90-х, там и встроенный форум до эпохи форумов не дотягивает. Экспорта/импорта в другие багтрекеры (гитхаб/гитлаб) нет, пулл-реквестов нет.
их тяжело читать и разбирать, получается writeonly подход.
О да, регулярки - такая штука, где можно забыть про "Чистый код" и с чистой совестью нафигачить огромный нечитаемый однострочник. Но не столько из-за недостатков регулярок, сколько из-за того, что это не осуждается, все так делают.
В диалектах без extended-режима (?x) (например, в JS его нет) регулярку можно собирать по частям - из переменных с говорящими именами.
А если режим есть, то становятся доступны комментарии, форматирование пробелами и переносами строк.
(?x) # some comment
\d+ # some comment
\ # match single space
\d+ # some comment
Если рассматривать это как реальную задачу ("написать сервис"), а не упражнение ("как математически просчитать"), то выглядит страшно, очень страшно. Я бы упростил до:
Растровая картинка с линейным градиентом по двум точкам - это картинка 2x1 пикселя, увеличенная с билинейной фильтрацией (до нужного размера - 1280x853). Ну, нам надо две полосы, можно взять картинку 2x2.
Цвет этих 4 пикселей? Использовать усреднённые цвета исходной картинки по углам. Уменьшить исходник где-нибудь до 5x5[1][2] и взять угловые пиксели.
А если извлечь не угловые пиксели, а верхнюю/нижнюю строки целиком, то будет линейный градиент по 5 точкам.
Чтобы градиент не распадался на полосы, лучше работать в 10+ битах и дизерить при понижении разрядности до 8 бит.
В чём это делать? Взять какую-нибудь высокоуровневую библиотеку для работы с картинками, чтобы из коробки всё было доступно: ресайз с фильтрами на выбор, несколько видов дизеринга плюс интерфейс почеловечнее, чем у imagemagick. Imagemagick можно использовать как Arch Linux не трогать, но пользоваться его документацией с хорошей теорией.
[1] снова можно выбрать билинейную фильтрацию, теперь ради скорости
[2] лучше выглядит, если использовать размер, обратно пропорциональный ширине полос (5x5 для широких полос, 10x10 для узких, условно говоря)
У вас завально-дифференциальный дуализм получается. В первом абзаце завал на НЧ, во втором - производная. Разберитесь с ним сами, а то ещё меня запутаете.
Да, магнитные звукосниматели чувствительны к колебательной скорости (скоростные / constant velocity pickup), т.е. производной от смещения (того, которое x = A*sin(wt)). Но рекордер (cutter), относительно которого мы меряем линейность, разве не так же устроен?
И если она нелинейная, то тогда что означают графики АЧХ звукоснимателей с горизонтальной линией?
Допустим, мы запутались, относительно чего ищем линейность плоскую АЧХ* и скажем "это графики после фонокорректора (с его RIAA reproducing curve), он исправил нелинейность", но нет - он же отменяет обратную кривую, применённую при записи (RIAA recording curve).
* кажется, "линейность" как термин может здесь наделать проблем из-за неоднозначности.
Это хорошо, но достаточно странно, чтобы искать причину не в H.264 и H.265, а в выбранных реализациях H.264 и H.265 (если это не свежие x264 и x265) или в их дефолтных настройках.
H.265 и AV1 - разные кодеки, они работают по-разному ...
Но смысл черты... Три часа назад... Ещё как даром!
разница в размерах иногда и 10 раз превышает.
Я не знаю, где именно надо ошибиться, чтобы получить такую разницу, но ошибка здесь как минимум в приписывании этой разницы стандартам. H.264 и H.265 как технологии не дают такой разницы. Когда мир получил H.265, он не получил улучшений "на порядки". Он получил процентов свои, ну, минус 30%* (как между PNG и JXL). Все дальнейшие рассуждения сыпятся из-за этого.
* со слов "можно увидеть, что H.265", если хабру не нравится ссылка на текст.
PS: AVX-512 - не с первых Ryzen, а только с Ryzen 7000 (Zen 4).
Но он на самом деле один (а avc1 - это его FourCC).
H.264 (AVC) -> H.265 (HEVC) / AV1 (других названий не имеет).
при тех же самых параметрах кодирования
Только и качество будет разным (шкала crf не совпадает). Grey83 прав, там нет такой разницы, а есть что-то вроде "от 20% до 2 раз". Сколько именно - не так интересно, потому что H.264 не используют для 4K, H.265 отсутствует в вебе (то самое лицензирование)...
Если бы мне пришло такое в голову, я бы искал вдохновения в сервис-мануале на SL-1200MK2 (сделана на трёх специализированных микросхемах, а в мануале есть блок-схема на них), но мне бы такое в голову не пришло.
Вытекший зелёный казался слишком тёмным, а красный - слишком светлым? Цветовое пространство - ещё один фактор. Выше был YUV с коэффициентами из BT.709 (HD), а ниже - из BT.601 (JPEG, WebP, SD-видео).
Под grayscale тоже имелась в виду luma (в предыдущий раз по BT.709).
Вообще размытие происходит из-за понижения разрешения цветности (в 2 раза по обеим сторонам, "4:2:0").
А красный выглядит наиболее размыто из-за каких-то особенностей протекания цветности и восприятия того, что получилось. Там магия слишком много факторов.
Берём объект (текст) с заливкой одного цвета и фон оттенка серого. Переводим в YUV 4:2:0 и получаем, что цветность как бы вытекает за границы объекта (точнее, они смешиваются, нулевая цветность фона тоже втекает в объект).
А дальше... Надо учесть, что зелёный (0,255,0) ярче (светлее) красного (255,0,0), а тот ярче синего (0,0,255). Учесть, что смешение идёт в YUV. Что слишком тёмный или слишком яркий фон при подмешивании цветности объекта изменит ещё и яркость в сторону серого. Что действия производятся без отмены гаммы (не в линейном пространстве), это важный фактор.
Но почему всё-таки красный?.. На тёмном фоне зелёный (0,255,0) будет выглядеть не самым размытым, потому что он самый яркий, то есть самый контрастный. Наверное. А что касается синего на тёмном фоне и объектов на светлом фоне
***На этом комментарий обрывается, потому что больше ему сказать было нечего***
У автора цитаты (Larry McVoy = luckydude@HN = владелец BitKeeper) дальше было ещё два абзаца:
Вообще, на HN это место в статье тоже вызвало вопросы ("Why is this crappy? What would be better?"), но Ларри явился в комменты и ещё прошёлся по Git'у.
Я здесь к нему присоединюсь (не считаю замедление поводом создавать локальный архив важных видео).
Там есть история правок, источники и их архивация ботами (на archive.org и .is), зачем такой пример в разговоре про потерю информации? Так же странно говорить об одном полном видео - его просто не может быть, начать надо с двухсот девяти ютубовских роликов группы 2 мая.
Демагог. Посмотри ещё на глупых учоных - не хотят от неактуальной инфы отказываться. Инфа из интернета самоустраниться пытается, а они ссылку на архив ставят, гады.
Если примеры нужны, то они не нужны.
Утверждение про частоту примером не доказать, нужно исследование, вряд ли такое есть.
В целом о проблеме доступности: думаю, кому статья актуальна, те и так знают, что меньше месяца назад кэш гугла как сервис закрыли, или что около 2000 сайтов целиком исключено из archive.org. Или имеют свои какие-то свои примеры на тему работы с источниками.
Из кэша гугла можно было вытащить недавно удалённую или изменённую информацию, всё ещё попадающую в выдачу (остались кэши бинга и яндекса).
Надо 10-15%, чтобы браузер начал отрисовывать jpeg (он ждёт DC-коэффициенты всех каналов; можно отрисовывать ч/б раньше, но в браузерах так не принято),
В идеале нужна параллельная загрузка 10-15% всех картинок, Cloudflare в 2019 году пишет[1][2], что HTTP/2 что-то такое позволяет (с оговоркой про хром и поддержку серверами...).
Ещё можно запросить только 10-15% (stackoverflow о range requests и прочих костылях), а потом... загружать заново целиком? Получается слишком костыльное и тяжёлое решение.
Нынешний успех Git'а связан с гитхабом, с авторитетом Линуса. Почему ситуацию должны изменить технические причины? Думаю, Git с нами до конца, он постепенно растворится в централизованных хостингах - будет всё менее важно, что у них под капотом - Git, что-то Git-совместимое или уже несовместимое, потому что хостинг будет всё дальше обрастать функцональностью и VCS будет лишь рядовой функцией среди прочих.
Жизненный пример, в википедии кто-то умудрился написать: "GitLab includes a distributed version control based on Git, including features such as access control, bug tracking...". Что включает в себя VCS, что децентрализовано, используется ли сам Git? Мы ответы знаем, но они не так уж и важны, это единая платформа. Буква D в DVCS теряет своё значение, гипотетические VCS будущего могут снова стать централизованными, It's Evolving, Just Backwards.
Принципиально новое можно внедрять в хостинг или прямо в Git, за деньги его получится развивать в нужном такой-то компании направлении (будет Git Foundation и Platinum Membership).
Идея круть, но реализация местами "чисто для себя". Багтрекеру (можно посмотреть на него в репозитории самого Fossil'а) далеко до гитхаба, гитлаба, багзиллы, первых версий багзиллы... и вот мы уже в 90-х, там и встроенный форум до эпохи форумов не дотягивает. Экспорта/импорта в другие багтрекеры (гитхаб/гитлаб) нет, пулл-реквестов нет.
О да, регулярки - такая штука, где можно забыть про "Чистый код" и с чистой совестью нафигачить огромный нечитаемый однострочник. Но не столько из-за недостатков регулярок, сколько из-за того, что это не осуждается, все так делают.
В диалектах без extended-режима
(?x)(например, в JS его нет) регулярку можно собирать по частям - из переменных с говорящими именами.А если режим есть, то становятся доступны комментарии, форматирование пробелами и переносами строк.
Если рассматривать это как реальную задачу ("написать сервис"), а не упражнение ("как математически просчитать"), то выглядит страшно, очень страшно. Я бы упростил до:
Растровая картинка с линейным градиентом по двум точкам - это картинка 2x1 пикселя, увеличенная с билинейной фильтрацией (до нужного размера - 1280x853). Ну, нам надо две полосы, можно взять картинку 2x2.
Цвет этих 4 пикселей? Использовать усреднённые цвета исходной картинки по углам. Уменьшить исходник где-нибудь до 5x5[1][2] и взять угловые пиксели.
А если извлечь не угловые пиксели, а верхнюю/нижнюю строки целиком, то будет линейный градиент по 5 точкам.
Чтобы градиент не распадался на полосы, лучше работать в 10+ битах и дизерить при понижении разрядности до 8 бит.
В чём это делать? Взять какую-нибудь высокоуровневую библиотеку для работы с картинками, чтобы из коробки всё было доступно: ресайз с фильтрами на выбор, несколько видов дизеринга плюс интерфейс почеловечнее, чем у imagemagick. Imagemagick можно
использовать как Arch Linuxне трогать, но пользоваться его документацией с хорошей теорией.[1] снова можно выбрать билинейную фильтрацию, теперь ради скорости
[2] лучше выглядит, если использовать размер, обратно пропорциональный ширине полос (5x5 для широких полос, 10x10 для узких, условно говоря)
Магнитные звукосниматели:
Завалов на НЧ нет
+6 дБ на октаву на всём диапазоне есть
мысленная (?) точка отсчёта: пластинка с постоянными амплитудами смещения
Характеристика записи:
не "применяется при записи", а описывает тракт от станка до...
до, внезапно, выхода магнитного звукоснимателя. Логично (это буквально обратная кривая), но ломает мозг.
Хотя с "точностью до производной" где-то я могу ошибаться...
У вас завально-дифференциальный дуализм получается. В первом абзаце завал на НЧ, во втором - производная. Разберитесь с ним сами, а то ещё меня запутаете.
Да, магнитные звукосниматели чувствительны к колебательной скорости (скоростные / constant velocity pickup), т.е. производной от смещения (того, которое x = A*sin(wt)). Но рекордер (cutter), относительно которого мы меряем линейность, разве не так же устроен?
И если она нелинейная, то тогда что означают графики АЧХ звукоснимателей с горизонтальной линией?
Допустим, мы запутались, относительно чего ищем
линейностьплоскую АЧХ* и скажем "это графики после фонокорректора (с его RIAA reproducing curve), он исправил нелинейность", но нет - он же отменяет обратную кривую, применённую при записи (RIAA recording curve).* кажется, "линейность" как термин может здесь наделать проблем из-за неоднозначности.
Это хорошо, но достаточно странно, чтобы искать причину не в H.264 и H.265, а в выбранных реализациях H.264 и H.265 (если это не свежие x264 и x265) или в их дефолтных настройках.
Но смысл черты... Три часа назад... Ещё как даром!
Я не знаю, где именно надо ошибиться, чтобы получить такую разницу, но ошибка здесь как минимум в приписывании этой разницы стандартам. H.264 и H.265 как технологии не дают такой разницы. Когда мир получил H.265, он не получил улучшений "на порядки". Он получил процентов свои, ну, минус 30%* (как между PNG и JXL). Все дальнейшие рассуждения сыпятся из-за этого.
* со слов "можно увидеть, что H.265", если хабру не нравится ссылка на текст.
PS: AVX-512 - не с первых Ryzen, а только с Ryzen 7000 (Zen 4).
Но он на самом деле один (а avc1 - это его FourCC).
H.264 (AVC) -> H.265 (HEVC) / AV1 (других названий не имеет).
Только и качество будет разным (шкала crf не совпадает). Grey83 прав, там нет такой разницы, а есть что-то вроде "от 20% до 2 раз". Сколько именно - не так интересно, потому что H.264 не используют для 4K, H.265 отсутствует в вебе (то самое лицензирование)...
Но ведь линейная. Ему, конечно, надо работать на нагрузку с определённой ёмкостью и сопротивлением, но это не то и это про резонанс на ВЧ.
Если бы мне пришло такое в голову, я бы искал вдохновения в сервис-мануале на SL-1200MK2 (сделана на трёх специализированных микросхемах, а в мануале есть блок-схема на них), но мне бы такое в голову не пришло.
Ещё одна
Вытекший зелёный казался слишком тёмным, а красный - слишком светлым? Цветовое пространство - ещё один фактор. Выше был YUV с коэффициентами из BT.709 (HD), а ниже - из BT.601 (JPEG, WebP, SD-видео).
Под grayscale тоже имелась в виду luma (в предыдущий раз по BT.709).
Вообще размытие происходит из-за понижения разрешения цветности (в 2 раза по обеим сторонам, "4:2:0").
А красный выглядит наиболее размыто из-за каких-то особенностей протекания цветности и восприятия того, что получилось. Там
магияслишком много факторов.Берём объект (текст) с заливкой одного цвета и фон оттенка серого. Переводим в YUV 4:2:0 и получаем, что цветность как бы вытекает за границы объекта (точнее, они смешиваются, нулевая цветность фона тоже втекает в объект).
А дальше... Надо учесть, что зелёный (0,255,0) ярче (светлее) красного (255,0,0), а тот ярче синего (0,0,255). Учесть, что смешение идёт в YUV. Что слишком тёмный или слишком яркий фон при подмешивании цветности объекта изменит ещё и яркость в сторону серого. Что действия производятся без отмены гаммы (не в линейном пространстве), это важный фактор.
Но почему всё-таки красный?.. На тёмном фоне зелёный (0,255,0) будет выглядеть не самым размытым, потому что он самый яркий, то есть самый контрастный. Наверное. А что касается синего на тёмном фоне и объектов на светлом фоне
***На этом комментарий обрывается, потому что больше ему сказать было нечего***
Картинка