Mithgol the Webmaster

[Media] Список проблем предпросмотра Markdown, которыя я заранѣе предвижу и оттого досадую о н [...]

Thu, 30 Apr 2026 06:39:46 +0300

Список проблем предпросмотра Markdown, которыя я заранѣе предвижу и оттого досадую о них, не исчерпывается перечисленными в предшествующем сообщении, а может быть продолжен:

➎ С досадою предвижу, что возможности, достижимыя в файлах Markdown, будут отставать от возможностей страниц сайта Telegraph по той причине, что в страницы сайта Telegraph можно было встраивать (между абзацами текста) сообщения из Телеграма и из Твиттера (нынѣ 𝕏), тогда как сам язык Markdown не предполагает ничего даже отдалённо подобного.

➏ С досадою предвижу, что возможности, достижимыя в файлах Markdown, будут отставать от возможностей страниц сайта Telegraph ещё и по той причине, что страницы сайта Telegraph были видными и для незалогиненных пользователей Телеграма (и даже для тѣхъ читателей страниц, которые никогда не регистрировалися в Телеграме), тогда как файлы Markdown (как и всякие другие файлы, прикрѣплённые к сообщениям в Телеграме именно «как файл», «как документ», а не в качестве иллюстрации) остаются совершенно недоступными для незалогиненных — остаются строго по эту сторону «огороженного сада» (walled garden) Телеграма.

➐ С досадою предвижу, что внутри «огороженного сада» (walled garden) у Телеграма появятся и другие изгороди — то есть, напримѣръ, что в файле Markdown, прикрѣплённомъ къ нѣкоторому сообщению, нельзя будет использовать в качестве иллюстраций другие файлы (но ужé не гипертекстовые, как Markdown, а графические файлы), прикрѣплённые даже к тому же сáмому сообщению, не говоря уж о прикрѣплённых к другим сообщениям на том же канале (и тѣмъ болѣе на других каналах). Но даже если возможность использовать прикрѣплённые к тому же сообщению файлы всё же появилась бы, то и тогда практическая польза ея сильно пострадала бы от невозможности прибавить ещё один или два файла к ужé отправленному альбому, даже к ещё не успѣвшему упереться в десятифайловое ограничение — это как раз тот недостаток, которому я посвятил второй пункт в списке желаемых новинок в сообщении о необходимости «Альбомов 2.0» в Телеграме. Всё это неизбѣжно закончится необходимостью наперёд разыскать удобный внѣшній хостинг иллюстраций (и затѣмъ пострадать от его закрытия), если только не будет предусмотрена какая-нибудь возможность для встраивания иллюстраций непосредственно внутрь файла Markdown — ну, напримѣръ, RFC 2397. (Конечно, не просто «предусмотрена»: чтобы быть реально полезною, эта возможность должна стать работоспособною в просмотрщике — а я в этом сомнѣваюсь и оттого заранѣе досадую.)

➑ Кстати об иллюстрациях, лежащих на внѣшнихъ хостингахъ: я с досадою предвижу, что просмотрщик файлов Markdown не будет брать иллюстрации непосредственно съ внѣшняго хостинга, а будет пытаться кэшировать их на сёрверах Телеграма (и для быстроты показа их, и для экономии траффика), и руководиться нѣкоторымъ таймаутомъ (засчитывая внѣшнему хостингу неотклик, если тот не выдал файл достаточно быстро), и кэшировать факт неотклика, и тѣмъ повредит иллюстрациям из небыстрых хранилищ (напримѣръ, изъ P2P-распредѣлённой файловой системы IPFS).

➒ Схожесть просмотрщика с Instant View как бы не означала заодно и необходимость ограничиваться только тѣми форматами графических файлов, которые Instant View поддерживает — напримѣръ, обходиться без AVIF и даже без WebP.

➓ Максимальный объём такого файла, который ещё можно прикрѣпить к сообщению в Телеграме, равен 2000 мегабайтов (4000 мегабайтов для покупщиков услуги Telegram Premium или для получивших её в подарок). Но здравый смысл подсказывает, что если файл Markdown такого объёма прикрѣпить к сообщению в Телеграме, то просмотрщик даже и пытаться не будет просматривать его. Это понятно. Но не понятно, каким окажется то (наложенное на объём файла) ограничение, при превышении которого просмотр Markdown просто-напросто не запустится: не слишком ли низким окажется ограничение? — я бы не очень безпокоился об этом, кабы рѣчь не шла о той же команде разработчиков и хозяев Телеграма, которая прежде ужé обнажила своё лицо, ограничив объём страниц сайта Telegraph всего-навсего 64 килобайтами (причём даже и это их ограничение досадно глючит).

Bugs and Suggestions
Telegraph's counter of characters needs an improvement
Sometimes the message “Content is too big” appears in Firefox 94.0.1 (and in a dozen of older versions of Firefox) when an attempt to save changes on a page in Telegraph should really be successful (because a query to the method getPage explained at https://telegra.ph/api#getPage yields the result which is significantly smaller than the limit promised at https://telegra.ph/api#createPage or https://telegra.ph/api#editPage which is 64KB). Two such cases are shown in the attached video file: ➊ I cannot add another picture on the page https://telegra.ph/Yuragi-sou-no-Yuuna-san-06-14 because the message “Content is too big” appears; however, the query “wget --output-document=NUL https://api.telegra.ph/getPage/Yuragi-sou-no-Yuuna-san-06-14?return_content=true” yields only 41981 bytes, and thus the JSON of the page's content should remain under 64KB even when another img tag is added. (This problem will force me to relocate the last part of the page to a new page in Telegraph, and thus this page won't be able to serve…

[Video] Настал роковой послѣдній день!В этот послѣдній день апрѣля разработчики Телеграма либо [...]

Thu, 30 Apr 2026 04:05:47 +0300

Настал роковой послѣдній день!

В этот послѣдній день апрѣля разработчики Телеграма либо выпустят очередную версию Телеграма, либо оставят апрѣль вообще без новинок Телеграма, потому что в настоящее время послѣдній список новинок Телеграма датируется 31 марта.

Среди извѣстныхъ намъ новинок грядущей версии Телеграма (которая в любом случае выйдет скоро, даже если и не сегодня) наиболѣе масштабною можно считать, я полагаю, поддержку просмотра текстовых файлов (а точнѣе — гипертекстовых) в формате Markdown, о появлении которой я прочёл упоминание на канале @betainfo ещё 27 апрѣля — там говорилось, что просмотр таких файлов будет сильно напоминать Instant View (ужé существующий в Телеграме просмотр гипертекстовых страниц Всемірной Паутины).

Я одновременно и рад этому, и огорчён.

Я рад этому оттого, что вижу возможность предпросмотра файлов Markdown в качестве ещё одной возможности для выкладывания в Телеграме достаточно длинных текстов — таких, которые превосходят по своей длине возможности сообщений в самóм Телеграме (не больше 4096 сѵмволовъ в одном сообщении). Прежде для этого приходилось оформлять такие тексты в форме альбомов файлов (в которых файлы работают какъ нѣкій «клей» между кусками текста, не превышающими 4096 сѵмволовъ, примѣромъ чего может служить мой текст про кратцы) или же тащить их на сайт Telegraph (братский по отношению к Телеграму), который стал куда менѣе удобным сперва оттого, что Дуров запретил загружать туда иллюстрации (и принудил подыскивать удобные внѣшніе хостинги иллюстраций, раз за разом прекращающіе работать или утрачивающіе одно из трёх своих удобств), а затѣмъ и оттого, что сам сайт начал открываться с трудом, причём не только в силу блокировок, налагаемых властями РФ — вряд ли эти блокировки способны повлиять на способность сайта Telegraph открываться через Opera VPN или через TOR.

Я огорчён ввиду того, что пессимистически предвижу такую массу проблем, которая способна помѣшать (и навѣрняка помѣшает) предпросмотру файлов Markdown в Телеграме реализовать свой потенциал:

➊ До сих пор Telegram использовал (напримѣръ, в API ботов) свой собственный диалект языка Markdown (слегка претенциозно названный «MarkdownV2»), который отличается от наиболѣе распространённаго диалекта (от CommonMark) по самым существенным вопросам — таким, как «жирным или курсивным дѣлать слово, с двух сторон выдѣленное звёздочками?» или как «жирным или подчёркнутым дѣлать слово, с двух сторон выдѣленное знаками подчёркивания?». Тот же диалект («MarkdownV2») авторы нѣкоторыхъ клиентских приложений Телеграма сдѣлали доступным для размѣтки сообщений пользователей. С высокою вѣроятностью новый просмотрщик будет использовать диалект, гораздо болѣе похожій на CommonMark — я этому порадуюсь (потому что с ним лучше знакомы широкие массы будущих пользователей, включая меня), но в умах поклонников MarkdownV2 возникнет путаница, и я заранѣе не рад их непріязни к новинке.

➋ Диалект MarkdownV2 (в отличие от CommonMark) содержал средства размѣтки зачёркиваний и спойлеров. Я почти совершенно увѣренъ, что новый предпросмотрщик файлов Markdown позволит использовать размѣтку зачёркиваний: такою же, как в MarkdownV2, она появляется и в языке Rentry, и в языке GitHub Flavored Markdown (он же GFM), и оттого в его надмножестве — в языке GitLab Flavored Markdown (он же GFLM). А вот насчёт спойлеров пока ещё нѣтъ увѣренности, и это досадно.

➌ Файл, использованный вон той демонстрациею, убеждает меня в том, что новый предпросмотрщик файлов Markdown позволит использовать размѣтку таблиц (причём подобную не Rentry, а GFM), а файл, использованный вон той демонстрациею — что позволит использовать и GFLM-размѣтку математических формул, записанных языком LaTeX. Но так как сам я не желаю ставить beta-версии клиента, то досадно не знать до послѣдней минуты ничё о том, какие другие возможности GFM и GFLM будут поддерживаться. Сам я пожелал бы прежде всего видеопроигрыватели и сноски.

➍ Схожесть просмотрщика с Instant View как бы не означала необходимость соблюдать и ограничения Instant View — напримѣръ, не превышать пять мегабайтов на иллюстрацию.

Даже для тѣхъ, кто сомнѣвается в принятии ислама этим королём, почти несомнѣннымъ остаётся фак [...]

Thu, 30 Apr 2026 01:42:08 +0300

Даже для тѣхъ, кто сомнѣвается в принятии ислама этим королём, почти несомнѣннымъ остаётся факт его обрѣзанности.

Понятно, что здѣсь возможно возражение: но вѣдь обрѣзанъ не исламским священнослужителем, а іудейскимъ! — ах, господа, ну разве история хотя бы послѣднихъ трёх с половиною десятилѣтій въ Россіи ещё не достаточно убедительно говорит нам, что даже если между собою обрѣзанные враждуют (и даже нерѣдко смертельно), то супротив необрѣзанныхъ почти всегда могут договориться и дѣйствовать как долгосрочные союзники?

[Media] Практическая польза от использования готовых словарей при сжатии текстовых данных, упо [...]

Tue, 28 Apr 2026 03:33:44 +0300

Практическая польза от использования готовых словарей при сжатии текстовых данных, упомянутого в предшествующем сообщении, различна для двух возможных сценариев использования.

Во-первых, когда какой-нибудь вспомогательный файл сайта (стиль CSS или код JS) отредактирован, тогда новая версия его обыкновенно бывает гораздо больше по объёму, нежели величина одного только набора внесённых правок — того списка затронутых строк (прибавленных, измѣнённыхъ, стёртых), который пользователи систем контроля версий обычно называют словом «дифф» или «патч». Слѣдовательно, если у большинства постоянных посѣтителей такого сайта в кэше у браузера осталась предшествующая версия файла, то можно использовать её в качестве готового словаря и тѣмъ достигнуть мощной силы сжатия — передаваемый «сжатый файл» в этом случае фактически представляет собою всего только «дифф» (он же «патч»), да ещё дополнительно доужатый кодировщиком. По-видимому, всё то же сáмое можно сказать и об RSS-потоках (и об их аналогах Atom), в которых чаще всего новая новость (напримѣръ, блогозапись) и вытесняемая ею старая новость совокупно бывают во много раз меньше общего объёма потока.

Во-вторых, когда рѣчь идётъ ужé не о вспомогательных файлах, а об основных HTML-страницах, то в них часто есть повторяющиеся куски:

• в шапке у каждой страницы часто одни и те же ссылки на стили, на скрипты, на значок (favicon) и проч.,

• в подвале у каждой страницы часто одни и те же дисклеймеры да копирайты,

• какой-нибудь подзаголовок всегда окаймляется одним и тѣмъ же кодом (мѣняется только сам текст заголовка),

• какой-нибудь тип иллюстраций всегда окаймляется одним и тѣмъ же кодом (мѣняется только имя файла и текст подписи),

• какой-нибудь навигационный блок повторяется на каждой странице почти таким же, как и на других — разве что в нём подсвѣчивается текущая страница или подраздѣлъ,

• какой-нибудь код обратной связи повторяется на каждой странице почти таким же, как и на других,

• для экономии обращений на сёрвер многие сайты оформляют мелкие значки как спрайты — их код очень похож и отсылает к одному и тому же графическому файлу, отличаясь только координатами или идентификатором желаемого спрайта.

Но если в первом сценарии перемѣнная часть («дифф», он же «патч») была кратно меньше постоянной, то во втором постоянная часть (общие куски страниц, во всей совокупности их) обычно меньше остального (перемѣннаго) тѣла страницы. Слѣдовательно, во втором сценарии рост силы сжатия от использования готового словаря — это рост «на проценты», а не «в разы».

Ещё одно послѣдствіе — необходимость ѿдѣльно подготавливать именно словарь как таковой (файл, содержащий одни только общие части страниц). Как правило, нельзя брать примѣръ съ предшествующаго сценария и использовать в роли готового словаря существующий файл (напримѣръ, давно не измѣнявшуюся страницу сайта): ожидаемая экономия траффика (от сжатия остальных страниц) может оказаться меньше, чѣмъ расходы на скачивание страницы-словаря — напримѣръ, когда постоянныя куски страниц (которые одни полезны в качестве словаря) в среднем в N раз меньше объёма страниц, а типичный посѣтитель сайта в среднем заходит меньше, чѣмъ на N страниц (то есть большинство приходит на двѣ или три страницы, которыя-то и нужны им, а затѣмъ быстро уходит навсегда). Очень рѣдко страница-словарь способна «доставаться бесплатно» за счёт того, что оказывается не просто давно не мѣнявшеюся, но и часто посѣщаемою (а оттого ужé лежит в кэше у большинства посѣтителей, не требует расхода траффика перед употреблением в качестве словаря).

А вот как раз с генераторами готовых словарей ещё не успѣли нормально наладить дѣло за полгода работы стандарта:

➊ Если на сборище файлов, по которым создаётся словарь общих частей, указывать в форме «*.html», а не в форме пути к подкаталогу, то zstd выдаёт такое сообщение об ошибке, по которому нельзя понять причину ея.

➋ Brotli вообще не предлагает готовую сборку генератора словарей (а планы такие были).

➌ Онлайновый генератор «Compression Dictionary Transport Dynamic Dictionary Tester» не грохнется ли, если сдѣлается популярным?

GitHub
How do we create custom dictionaries? · Issue #697 · google/brotli
As per Jyrki's request, I'm filing this issue: How do we create custom dictionaries? I haven't found any user docs on it. For example, with Zstd we would do something like: zstd --train...

[Media] Ужé в самые ранние годы существования WWW — и прежде всего благодаря тому, что как раз [...]

Tue, 28 Apr 2026 22:08:11 +0300

Ужé в самые ранние годы существования WWW — и прежде всего благодаря тому, что как раз в эти годы каналы связи были в Интернете часто чудовищно низкоскоростными (по нынѣшнимъ мѣркамъ — невыносимо низкоскоростными) — путь от замысла до реализации довольно быстро прошла идея о том, что весь текстовый траффик (и HTML-страницы, и CSS-стили, и джаваскрипты) быстрѣе перегонять по Сѣти не «как есть», а заархивированными со сжатием въ нѣсколько разъ, зазипованными в формат gzip, который Википедия называет появившимся под конец октября 1992 года.

С той поры прошло больше трёх десятилѣтій. Обзавелась ли эта же идея какими-нибудь техническими усовершенствованиями? — а как же! — обзавелась, ясное дѣло.

Во-первых, можно ткнуть пальцем в попытки совершенствования gzip-архиваторов, среди которых наибольшаго внимания заслуживают pigz (многопоточная реализация gzip, всё болѣе полезная для современных дорогостоящих процессоров, которые теперича могут содержать без мáлого сотню двухпоточных ядер) и Zopfli (средство, достигающее на нѣсколько процентов большаго сжатия за счёт многодесятикратнаго роста усилий, который для современных высокоскоростных процессоров ужé не приводит к такому невыносимому росту времени работы, каким он был бы в девяностые годы).

Во-вторых, можно ткнуть пальцем в попытки создания болѣе новых форматов сжатия траффика, опережающих формат gzip по силе сжатия за счёт примѣненія новых алгоритмов и приёмов. Среди таких форматов наибольшаго внимания заслуживают формат Brotli (в Google созданный) и формат Zstandard (в Facebook꙳ созданный).

Формат Zstandard добрался до поддержки новыми версиями каждого из популярных браузеров в феврале нынѣшняго (2026) года, послѣдними о его поддержке объявили разработчики браузера Safari.

Формат Brotli добрался до поддержки новыми версиями каждого из популярных браузеров значительно ранѣе — в сентябре 2017 года, причём послѣдними из поддержавших его сайт caniuse называет опять же разработчиков браузера Safari.

Экономия, лежащая в основе сжатия текстовых данных, обычно полагается на способность кодировщика обнаруживать в тексте повторяющиеся фрагменты и заносить их в автоматически создающийся словарь, а в сжимаемом тексте замѣнять такие фрагменты болѣе краткими ссылками на словарь. Но разработчики Brotli пошли ещё дальше, включив в состав кодировщика небольшой готовый словарь, содержащий наиболѣе частыя (по ихъ мнѣнію) конструкции языков WWW (то есть HTML, CSS, JS) и словá языков так называемаго реальнаго міра, появление которых в кодируемом тексте поэтому ужé не требует помѣщенія ихъ в файл-результат (даже однократного), достаточно только ссылки на словарь в кодировщике.

Однако же пристальное разглядывание отсортированного содержимого словаря Brotli способно обнаружить там без мáлого 6½ тыщщ слов и словосочетаний латиницею (строки с номерами 897—7351), но только штук 300 слов кириллицею (строки с номерами 7392—7694), что попахивает, как минимум, недопредставленностью (а как максимум — неоколониализмом).

Правда, упрёк этот может быть обращён единственно к содержимому конкретного готового словаря (встроенного в кодировщик и в декодировщик Brotli), сама же практика подготовки и затѣмъ употребления готовых словарей как дополнительнаго средства, позволяющаго наращивать силу сжатия текстовых файлов, является безусловно плодотворною практикою — слѣдовательно, есть смысл порадоваться тому, что практика эта дошла ужé и до стандартизации (RFC 9842), и до реализации во браузере Chrome 130 (выпуск этой версии состоялся в середине октября 2025 года), и затѣмъ во всѣхъ его производных (Edge 130, Opera 115, etc.). Одобрили эту затею и разработчики браузера Firefox, и затѣмъ разработчики браузера Safari.

В феврале нынѣшняго (2026) года Tim Perry посвятил подробному разсмотрѣнію достоинств употребления готовых словарей замѣтку «Dictionary Compression is finally here, and it's ridiculously good», с которою я рекомендую ознакомиться всѣмъ желающим дальнѣйшихъ подробностей.

________

꙳ Владеющая Facebook компания Meta внесена в перечень террористов и экстремистов (в настоящее время — под номером 13).

Httptoolkit
Dictionary Compression is finally here, and it's ridiculously good
Dictionary compression could completely change how applications send data over the web. It's recently gained broad support, and offers absurd real-world...

[Media]

Sun, 26 Apr 2026 20:44:14 +0300

И ты будешь Звѣздою Обѣтной,Возвѣщающей близость зариВо чьё имя ордою несмѣтнойУправляютъ стра [...]

Sun, 26 Apr 2026 14:48:10 +0300

И ты будешь Звѣздою Обѣтной,
Возвѣщающей близость зари

Во чьё имя ордою несмѣтной
Управляютъ страной упыри.

Современныя нейросѣти избавляют сочинителей таких произведений и от необходимости самостоятель [...]

Sun, 26 Apr 2026 05:10:09 +0300

Современныя нейросѣти избавляют сочинителей таких произведений и от необходимости самостоятельно подбирать музыку под словá, ими сочинённыя, и от необходимости подыскивать пѣвцовъ. Достаточно сочинить один только текст пѣсни и правильно скормить его нейросѣти, а затѣмъ внимательно послушать — и поправить всѣ обнаруженныя ошибки.

Однако въ пѣснѣ «Эх VPNы Верные» я не вижу такой работы над ошибками:

➊ В заглавии опосля «эх» стоило бы поставить запятую.

➋ Если это «имперская версія», то тогда в заглавии стоило бы записывать «вѣрныя» вмѣсто «верные», считая слово «VPN» женскаго рода ввиду того, что «network» означает «сѣть».

➌ Стоило бы поискать и найти рифму болѣе точную, нежели между словами «зеркала» и «нас», «строю́» и «моему», «студент» и «редут», «войскá» и «страна».

➍ Стоило бы поправить ошибочныя ударения, поставленныя нейросѣтью въ не извѣстныхъ для нея словах: она явно поёт «сувéренный» и «óстрог», а надо-то не так.

Замѣтимъ, что общение с близкими оказалось затруднено блокировками аудиопереговоров («звонков» [...]

Tue, 21 Apr 2026 00:45:30 +0300

Замѣтимъ, что общение с близкими оказалось затруднено блокировками аудиопереговоров («звонков») и видеопереговоров в Телеграме с августа 2025 года. Но и скачивание нормальных человѣческихъ телесериалов также будет затруднено — ужé въ нынѣшнемъ (2026) году — наложениями ограничений на потребление зарубежнаго траффика в Интернете.

Далѣе в том же источнике:

востребованность антиутопий резко выросла, доказывает аналитика книжного сервиса КИОН Строки: в 2025 году россияне проводили за чтением и прослушиванием книг этого жанра в 3,7 раза больше времени, чем в 2024

[Media] Если борьба против компьютерной грамотности в области обхода правительственных блокиро [...]

Sat, 18 Apr 2026 21:58:09 +0300

Если борьба против компьютерной грамотности в области обхода правительственных блокировок в Интернете перерастёт в борьбу против грамотности как таковой (в духе режима красных кхмеров) в так называемом реальномъ мірѣ, то тогда и на мѣсто пропагандистских плакатов «Сегодня ставишь VPN, а завтра НАТО сдашься в плен!» съ неизбѣжностью придут плакаты «Сегодня ты открыл букварь — а завтра в плен сдаёшься, тварь» или аналогичные по смыслу и по духу.

Можно ли к этой антиутопической экстраполяции прибавить, что тогда и эффективность таких плакатов окажется близкою к стопроцентной за счёт того, что воздѣйствовать они будут только на цѣлевую аудиторию грамотных людей, которые-то и будут единственными во всей стране способными прочесть такой плакат? — нѣтъ, никоим образом нельзя, потому что такое прибавление было бы некорректною оцѣнкою настоящей цѣлевой аудитории: сегодняшний пропагандистский плакат ориентирован был, уж конечно, не на одну только совокупность компьютерно грамотных людей (до которых доносит нехитрую мысль «не ставь VPN: это шаг к предательству»), но и на много болѣе широкую совокупность компьютерно малограмотных людей, до которых доносит ненавистническую мысль «каждый компьютерщик — потенциальный предатель в пользу NATO».

Telegram
Питер Live
Университеты России начали бороться с VPN Смотреть больше новостей👉 Мы в MAX