- комментарий 0:
From: ярик сысоев
Date: 2026-05-19 14:31:10Z
А где само фото?..
Я открыл страницу, увидел jxl, решил, что это отличный повод обновить хромиум. как обновил и открыл заново - фото исчезло.
Тем не менее, видимо, обнова касалась только хрома, т.к. хромиум jxl так и не рендерит на тестовом сайте.
Почему вы, к слову, не дублируете фото в каком-то более доступном формате? Про CSS, наверное, спрашивать вообще бессмысленно.
А ещё заметил, что из тела страницы пропали ссылки next/prev.
- комментарий 1:
From: Sergey Matveev
Date: 2026-05-19 16:04:45Z
*** ярик сысоев [2026-05-19 17:31]:
>Я открыл страницу, увидел jxl, решил, что это отличный повод обновить хромиум. как обновил и открыл заново - фото исчезло.
Опа, мой косяк. И довольно долгий. Как-то я перемещал директории на ФС,
чтобы под анонимным SFTP можно было скачивать сайты
(bf0ceec48f161368404d4ce40a278195777e8149) и не обновил конфиги для
движка блога, где указывался бы новый путь до директории с изображениями.
Если запрос попадал на домашний сервер, то всё ok, а если на VPS (чисто
по DNS разброс), то он не знал о существовании изображений. Сейчас
поправил. Вроде всегда помнил про два хоста, всегда проверял всё ли там
синхронизировано, но не уследил.
>Почему вы, к слову, не дублируете фото в каком-то более доступном формате?
Потому что JPEG XL настолько технически крут, как я вижу, в том числе и
относительной простотой (относительно HEIC и AVIF), что он единственный
кто может идти на полноценную, стоящую того, замену всем форматам: JPEG,
PNG, JPEG2000. Нет никакого смысла использовать MP3 например. Вот и с
появлением JXL нет никакого смысла использовать что-либо другое (не беру
всякие OpenEXR и подобные форматы для специфических задач). Также я
например использую Zstandard сжатие, потому что, если речь не про
embedded, нет смысла не использовать формат который и быстрее и лучше
сжимает (чем gzip), и дьявольски быстро разжимает. То что не все
поддерживают что-то кроме MP3 -- это их проблема. Аналогично и про
изображения.
А что является "доступным" форматом? Если взять Apple экосистему, то у
них принципиально (как-будто) только патентованные и закрытые форматы
всюду и везде. Хотя я был удивлён что спустя 10 (15?) лет они добавили
WebP и даже JXL (насколько где-то слышал). Если взять Windows, то там
тоже в мультимедиа у них сплошь и рядом всё своё, закрытое, не
свободное. Из коробки никаких Vorbis, FLAC, Opus же до сих пор небось
нет. А MP3 не было в Ubuntu, так как формат требовал отчислений и не
являлся из-за этого свободным. Единственный формат для звука который бы
везде открылся, был бы банальный WAV PCM. Но как-то это чересчур
избыточно, мягко говоря, передавать по общественным сетям? С
изображениями немного получше: JPEG и PNG вроде везде поддерживаются.
Если какой-то формат уделывал бы JPEG/PNG например на 10-20%, то тут
большой вопрос стоит ли овчинка выделки. Но когда JXL легко может более
(b0b1c55e7e310cb75e94807bcaef7f3a175f29e0) чем в два раза лучше сжать
PNG, то это уже *качественно* иной уровень, как по мне. Opus например
более чем в два раза меньшим bitrate может выдать такое же качество как
в MP3 -- это тоже качественно иной уровень, стоящий перехода на него.
Почему в Chrome* нет JXL, который даже в macOS добавили? Вопросы к ним.
Политика, неподелённые деньги, деление рынка -- думаю что всё с этими
вещами связано. Особенно, учитывая, что именно в Google много наработок
было сделано которые стали основной JXL. Например из-за CA/B-форума,
нужно разделять мир X.509+TLS работающий с web-обозревателями и
X.509+TLS для всего остального. Поэтому плевать на то, что там решается
в CA/B. Аналогично и с форматами. Когда стандартизовывался HTML5, то
почему они (тут я уже про Firefox) не согласились поддерживать Theora
кодек, на тот момент единственный достаточно хорошо сжимающий и
свободный? Может что и путаю, что всё равно все эти производители
броузеров впилили и DRM и несвободные кодеки, потому что всё везде
завязано на деньгах, и крайне редко на технических решениях/оценках.
Плевать я хотел на всех них из-за этого. Меня же, как и многих
окружающих, не волнует что там поддерживает macOS или Windows? В
последнем даже .tar не поддерживался. Это закрытые экосистемы,
угнетающие пользователей, пилящие бабло, но да, распространённые. Вот
всё аналогично и касательно web-обозревателей. Из-за того, что кто-то
там не поделил деньги, я должен терпеть то, что изображения более чем в
два раза большего размера надо слать по каналам связи?
>Почему вы, к слову, не дублируете фото в каком-то более доступном формате?
То есть, тратить CPU, HDD, своё время на поддержку систем, где архаичное
дерьмо? И так должны поступать куча других сайтов? Может было бы правильнее
чтобы люди использовали достижения математики, алгоритмов и технологий
продвинувшиеся на десятилетия вперёд? Я понимаю что старый/архаичный не
значит плохой -- там может быть существенно меньше кода, больше
надёжности, всего такого. Но не в случае с *качественно* иного уровня
сжатием данных, при этом с вполне, судя по всему (в противовес
AVIF/HEIC), адекватным размером спецификации.
>Про CSS, наверное, спрашивать вообще бессмысленно.
Верно. Этой технологии вообще не должно было бы быть. Тем более в том
виде, котором она стала сейчас, вообще даже Тьюринг-полной. Это дело
конечного читателя документа решать как *ему* удобнее воспринимать
информацию (шрифты, цвета и прочее). Хотя размещение в табличном виде
(в моём блоге) тоже можно отнести к тому, что я за него решил, но я тут
это воспринимаю как выбор структуры отображения :-)
Хотя когда-то у меня был мой фирменный CSS на всех сайтах :-)
>А ещё заметил, что из тела страницы пропали ссылки next/prev.
Когда-то они перекочевали из HTML тела в <link> элементы заголовка,
которые для подобных целей и предназначаются. Стандартизовано в HTTP/1.1
RFC и HTML стандартах. Lynx, Links, W3M -- ссылки прекрасно показывают:
Lynx:
Блог Stargrave на русском (100-150) (S1 von 3)
#[1]Нить статей [2]Нить комментариев [3]О блоге [4]наверх [5]пред [6]след
Links:
Блог Stargrave на русском (100-150) (p1 of 5)
Link: [1]vcs-git: Git репозиторий
Link: [2]vcs-git: Git репозиторий
Link: [3]home: О блоге
Link: [4]top: наверх
Link: [5]prev: пред
Link: [6]next: след
W3M:
Link information
made [Rev] mailto:webmaster@stargrave.org
Git репозиторий [Rel] git://git.stargrave.org/stargrave-blog.git
Git репозиторий [Rel] https://git.stargrave.org/stargrave-blog.git
Нить статей [Rel] http://blog.stargrave.org/russian/feed.atom
Нить комментариев [Rel] http://blog.stargrave.org/russian/comments.atom
О блоге [Rel] /
наверх [Rel] /russian/
пред [Rel] /russian/?offset=50
след [Rel] /russian/?offset=150
Firefox это всё тоже умел показывать, когда я его ещё использовал.
Не удивлюсь если этот функционал выпилили. В example WebKit обозревателе
уже нет. Нет сомнений, что через несколько лет наверняка ни одной
обычной HTTP+HTML страницы уже не будут показывать. Хотя с HTTP уже
проблемы, только HTTPS разрешён по умолчанию, насколько слышал (на
поклон к США за разрешением посещать твою страницу).
- комментарий 2:
From: Sergey Matveev
Date: 2026-05-19 16:10:52Z
Кстати, до сих пор у меня WebP используется для preview всяких
фотографий на домашней странице. Я бы сказал: так исторически сложилось.
Позлорадствовал: пускай видят, что теряют на допотопном софте :-)
А вообще это удивляет: как обновлять web-обозреватель каждые полгода,
чтобы супер новомодные сайты работали бы -- это люди делают на раз два.
Добавить очередной DRM -- это создатели web тоже на ура. Но как поддержать
новый кодек/формат, так это десятилетями возможно придётся ждать.
- комментарий 3:
From: Yarik Sysoev
Date: 2026-05-19 19:00:00Z
>Lynx, Links, W3M -- ссылки прекрасно показывают
да, в lynx в первую очередь и пошёл перепроверять, там всё нормально :)
>Стандартизовано в HTTP/1.1 RFC и HTML стандартах.
А в телнете стандартизирована опция для включения шифрования (и она даже
в GNUсном есть, но с нюансом). Но, увы, стандарт не определяет
реальность. Ну или по крайней мере не ту реальность, где я существую.
Про фото:
Я вот сейчас добрался до домашнего компа, о чём может свидетельствовать
автоматический перенос строк, который есть в thunderbird, но которого
нет в fairemail, с которого обычно пишу. И из всех программ, которые в
теории могли бы открыть изображения это: gimp, obs и kdenlive. gwenview
и eog не смогли (та кто ж в этот раз опенсорсу в штаны насрал?). brave
тоже не смог, но, в принципе, ожидаемо.
> Но как поддержать новый кодек/формат, так это десятилетями возможно придётся ждать.
При чём, как видно, не одни проприетарщики этим страдают.
- комментарий 4:
From: Sergey Matveev
Date: 2026-05-19 19:35:26Z
*** Yarik Sysoev [2026-05-19 21:59]:
>А в телнете стандартизирована опция для включения шифрования (и она даже в
>GNUсном есть, но с нюансом). Но, увы, стандарт не определяет реальность. Ну
>или по крайней мере не ту реальность, где я существую.
Тоже верно, не всё из стандартов реализуется. Яркий пример это X.509 и
использующие его стандарты типа CMS: типа вообще наверное в мире нет
никого кто бы полностью его реализовывал и поддерживал.
Как минимум в Firefox, произошла деградация с <link>, насколько читал.
Про Chromium не знаю. Я также слышал, что HTTP по умолчанию не
открывается в них: это означает, что мне надо идти на поклон в США
(Let's Encrypt) для получения одобрения показа моего сайта у людей? В
Firefox я помню что выпиливали быстрое переключение отключения/включения
cookie. Да и уйму чего ещё, типа слежения за пользователем. Зачем мне
после всего зловредительства вообще смотреть на эти программы? Потому
что популярны? Тогда мне надо начинать с приобретения смартфона, ругани
на РКН, установки VPN и Windows. Спасибо, но нет. Я на полном серьёзе не
буду вообще суваться в ИТ мир, если бы что либо из этого понадобилось.
>Я вот сейчас добрался до домашнего компа, о чём может свидетельствовать
>автоматический перенос строк, который есть в thunderbird, но которого нет в
>fairemail, с которого обычно пишу. И из всех программ, которые в теории
>могли бы открыть изображения это: gimp, obs и kdenlive. gwenview и eog не
>смогли (та кто ж в этот раз опенсорсу в штаны насрал?). brave тоже не смог,
>но, в принципе, ожидаемо.
Список пошиле: https://jpegxl.info/resources/supported-software.html
Причём, раз JXL поддерживается в imlib2, то значит все кто его
используют, могут показать. А это как-раз всякие sxiv, feh (которые чаще
всего используются suckless людьми) просмотрщики. ImageMagick тот же
поддерживает.
Более того: есть же штатная утилита декодирования из самого libjxl.
Всегда можно просто ею посмотреть, зачем обязательно в каком-то комбайне
это должно быть? AVIF я вообще только через утилиту декодирования из
библиотеки "видел".
У меня же мой HTTP прокси просто видит, что если на входе (по
Content-Type) у меня JXL, то он буквально прям вызывает djxl утилиту,
конвертирует на лету в PNG/JPG и шлёт мне в броузер. Поэтому у меня
Links2 (-g) показывает и JXL и AVIF и WebP (хотя он вроде там штатно
может поддерживаться). Lynx вообще просто файл сохраняет и натравливает
утилиту, которой может быть любой просмотрщик.
Видите до чего мы дожили в Unix-like системах, ну а точнее GNU/Linux?
Всё что вы назвали: само собой к Unix-way отношения не имеет (возможно,
кроме GIMP). И там добавление нового формата, хотя бы без анимации --
настолько сложное дело, что как и у проприетарщиков, как вы и заметили,
всё плачевно. Но в Unix-way friendly софте всё настолько без проблем,
пускай даже через внешнюю утилиту декодировать, что вот я никаких
неудобств с JXL не испытываю уже годами. Берём же современный модный
"Linux" и... его user experience со вмести недостатками очень близок к
Windows/macOS. Потому не только я и говорим: что "Linux" стал полнейшей
дрянью, почти ничего не имеющей общего с Unix-way и идеями свободного
ПО. И как по мне, начало окончательного конца для экосистемы началось с
systemd.
У меня на полном серьёзе уже годами нет никаких PNG/JPG/J2K: либо
сконвертировано в JXL, либо транскодировано из JPG в него (ужимает не
настолько сильно, но всё же lossless).
Тут вообще ничего нового с JXL нет. Я застал времена когда был Vorbis,
когда появился Opus -- конечно же всякие монстры типа броузеров или
навороченных мультимедиа проигрывателей ничего этого не поддерживали
многие годы. Unix-way люди просто использовали утилиты и наслаждались
современными кодеками, а не выходцами из начала 1990-х.
Сейчас я удивлён стремительной популярности AV1, который вроде как
*даже* Apple добавил себе. Уж не знаю насколько страшен этот кодек
внутри, но SVT-AV1 демонстрирует просто потрясающее качество при
отличной скорости кодирования. Никогда в жизни ни с одним кодеком не
было такой скорости кодирования и результата. За всё это время не
удосужился никто написать свободную реализацию с ассемблером VP8 или
VP9? Или так, или он плохо ложится на amd64 SIMD? Не разбираюсь тут. Но
SVT-AV1 просто поразил меня.
>При чём, как видно, не одни проприетарщики этим страдают.
Да, тут страдают создатели дурно спроектированного сложного софта.
Точнее его пользователи. У проприетарщиков просто кроме самой
технической работы, ещё есть заботы о патентах, о рынках, о политике, о
всём таком.
- комментарий 5:
From: Sergey Matveev
Date: 2026-05-19 19:42:24Z
У меня кстати есть коллега, у которого в системе то ли VP9, то ли даже
VP8 кодека нет из поддерживаемых (не говоря про AV1). Это что, означает
что надо применять Theora или AVC 20-летней давности? Хотя в BitTorrent
трэкерах я видел, что до сих пор продолжают выпускать фильмы в .avi и
MPEG4. Пожалейте сети, электростанции, накопители :-)