(no subject)

May. 8th, 2026 10:53 pm
ufm: (Default)
[personal profile] ufm
УКАЗ ПРЕЗИДЕНТА УКРАЇНИ №374/2026

Про проведення параду в м.Москві

Враховуючи численні прохання, з гуманітарною метою, окресленою в перемовинах з Американською стороною 8 травня 2026 року, постановляю:

1. Дозволити 9 травня 2026 року провести парад в м. Москві (Російська Федерація).

На час параду (з 10 години ранку за Київським часом 9 травня 2026 року) територіальний квадрат Красної площі виключити з плану застосування українського озброєння.

Квадрат Красної площі:
55.754413 37.617733
55.755205 37.619181
55.753351 37.622854
55.752504 37.621538

2. Цей Указ набирає чинності з дня його підписання.

Президент України В.ЗЕЛЕНСЬКИЙ
8 травня 2026 року

https://www.president.gov.ua/documents/3742026-59389
vak: (Украина)
[personal profile] vak
Но только в указанном квадрате.

А Трамп решил, что он Путин, и объявил перемирие на три дня между Россией и Украиной. Всем пофигу, конечно, но сам факт смешной.

SDDL

May. 8th, 2026 11:48 am
vak: (Знайка)
[personal profile] vak
Новый язычок появляется для описания структуры файлов. Применяется для всяких сжатий данных. Вот пример.
record CatalogHeader() {
STAR0: Int32LE, # Subtract from star number to get sequence number
STAR1: Int32LE, # First star number in file
STARN: Int32LE, # Number of stars; <0 → coordinates J2000
STNUM: Int32LE, # ID scheme / name flag
MPROP: Int32LE, # Motion info: 0=none, 1=proper, 2=radial
NMAG: Int32LE, # Number of magnitudes (0–10)
NBENT: Int32LE # Bytes per star entry
}

record StarEntry(STNUM, MPROP, NMAG) {
when STNUM > 0 { XNO: Float32LE }, # Catalog number
SRA0: Float64LE, # Right Ascension
SDEC0: Float64LE, # Declination
ISP: Bytes(2), # Spectral type
when abs(NMAG) > 0 { MAG: Int16LE[abs(NMAG)] }, # Magnitudes
when MPROP >= 1 {
XRPM: Float32LE, # R.A. proper motion
XDPM: Float32LE # Dec. proper motion
},
when MPROP == 2 { SVEL: Float64LE }, # Radial velocity
when STNUM < 0 { NAME: Bytes(-STNUM) } # Object name
}

# File structure
header: CatalogHeader

# Parse the header to get the number of stars and entry parameters
STNUM = header.STNUM
MPROP = header.MPROP
NMAG = header.NMAG
NBENT = header.NBENT
record_count = abs(header.STARN)

expect sizeof(StarEntry(STNUM, MPROP, NMAG)) == NBENT

stars: StarEntry(STNUM, MPROP, NMAG)[record_count]
Описание здесь: openzl.org/sddl/getting-started/

(no subject)

May. 8th, 2026 03:41 pm
ufm: (Default)
[personal profile] ufm
Новое выражение услышал недавно. "Туапсец".

(no subject)

May. 8th, 2026 10:22 am
ufm: (Default)
[personal profile] ufm
Repost

Уязвимости Dirty Frag, изменяющие страничный кэш для получения root в любых дистрибутивах Linux

В ядре Linux выявлены две уязвимости (https://github.com/V4bel/dirtyfrag), по своей сути аналогичные несколько дней назад раскрытой уязвимости Copy Fail (https://www.opennet.ru/opennews/art.shtml?num=65325), но проявляющиеся в других подсистемах - xfrm-ESP и RxRPC. Серии уязвимостей присвоено кодовое имя Dirty Frag (https://dirtyfrag.io/) (также встречается упоминание Copy Fail 2). Уязвимости позволяют непривилегированному пользователю получить права root, перезаписав данные процесса в страничном кэше. Доступен эксплоит (https://github.com/V4bel/dirtyfrag/blob/master/exp.c), работающий во всех актуальных дистрибутивах Linux. Информация об уязвимости раскрыта до публикации исправлений, но есть обходной метод блокирования проблемы.

Dirty Frag охватывает две разные уязвимости: первая в модуле xfrm-ESP (https://docs.kernel.org/networking/xfrm/index.html), используемом для ускорения операций шифрования в IPsec с использованием протокола ESP (Encapsulating Security Payload), а вторая в драйвере RxRPC (https://docs.kernel.org/networking/rxrpc.html), реализующем семейство сокетов AF_RXRPC и одноимённый RPC-протокол, работающий поверх UDP. Каждая из уязвимостей по-отдельности позволяет добиться получения прав root. Уязвимость в xfrm-ESP проявляется в ядре Linux с января 2017 года (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cac2661c53f3), а уязвимость в RxRPC - с июня 2023 года (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2dc334f1a63a). Обе проблемы вызваны оптимизациями, допускающими прямую запись в страничный кэш.

Для эксплуатации уязвимости в xfrm-ESP у пользователя должны быть права на создание пространств имён, а для эксплуатации уязвимости в
RxRPC должна быть возможность загрузки модуля ядра rxrpc.ko. Например, в Ubuntu в правилах AppArmor непривилегированному пользователю запрещено создание пространств имён, но по умолчанию загружается модуль rxrpc.ko. В каких-то дистрибутивах отсутствует модуль rxrpc.ko, а но не блокируется создание пространств имён. Выявивший проблему исследователь подготовил комбинированный эксплоит, способный атаковать систему через обе уязвимости, что позволяет эксплуатировать проблему во всех крупных дистрибутивах. Работа эксплоита подтверждена в Ubuntu 24.04.4 с ядром 6.17.0-23, RHEL 10.1 с ядром 6.12.0-124.49.1, openSUSE Tumbleweed с ядром 7.0.2-1, CentOS Stream 10 c ядром 6.12.0-224, AlmaLinux 10 с ядром 6.12.0-124.52.3 и Fedora 44 с ядром 6.19.14-300.

Как и в случае с уязвимостью Copy Fail, проблемы в xfrm-ESP и RxRPC вызваны (https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md) выполнением расшифровки данных по месту c
использованием функции splice(), передающей данные между файловыми дескрипторами и каналами (pipe) без копирования, путём передачи ссылок на элементы в страничном кэше. Смещения для операции записи рассчитывались без должных проверок, учитывающих использование прямой ссылки на элементы в страничном кэше, что позволяло через отправку специально оформленных запросов перезаписать 4 байта по выбранному смещению и изменить находящееся страничном кэше содержимое любого файла.

Все операции чтения из файлов в первую очередь отдают содержимое из страничного кэша. В случае модификации данных в страничном кэше операции чтения из файла приведут к возвращению не реально хранимой на накопителе информации, а подменённых данных. Эксплуатация уязвимости сводится к изменению страничного кэша для исполняемого файла с флагом suid root. Например, для получения прав root можно прочитать исполняемый файл /usr/bin/su для его помещения в страничный кэш, после чего добиться подстановки своего кода в загруженное в страничный кэш содержимого этого файла. Последующий запуск утилиты "su" приведёт к тому, что в память будет загружен не оригинальный исполняемый файл с накопителя, а изменённая копия из страничного кэша.

Раскрытие информации об уязвимостях и скоординированный выпуск обновлений с устранением проблем было намечено на 12 мая, но из-за
утечки информации (https://www.openwall.com/lists/oss-security/2026/05/07/12) сведения об уязвимости пришлось опубликовать (https://www.openwall.com/lists/oss-security/2026/05/07/8) до публикации исправлений. В конце апреля в публичном списке рассылки netdev были опубликованы патчи к rxrpc (https://lore.kernel.org/all/afKV2zGR6rrelPC7@v4bel/), ipsec (https://lore.kernel.org/all/afLDKSvAvMwGh7Fy@v4bel/) и xfrm (https://lore.kernel.org/all/20260504073403.38854-1-h3xrabbit@gmail.com/), без упоминания, что они связаны с устранением уязвимости. 5 мая мэйнтейнер подсистемы IPsec принял в git-репозиторий netdev изменение (https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4) c предлагаемым исправлением в модуле xfrm-esp, описание к которому во многом повторяло описание проблемы, приведшей к уязвимости Copy Fail в модуле algif_aead. Один из исследователей безопасности заинтересовался этим исправлением, сумел создать (https://afflicted.sh/blog/posts/copy-fail-2.html) рабочий эксплоит и опубликовал его (https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo), не зная о том, что на раскрытие сведений о проблеме до 12 мая введено эмбарго.

Обновления с исправлениями для ядра Linux и пакетов с ядром в дистрибутивах пока не опубликованы, но доступны устраняющие проблемы патчи - xfrm-esp (https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4) и rxrpc (https://lore.kernel.org/all/afKV2zGR6rrelPC7@v4bel/). CVE-идентификаторы не присвоены, что усложняет отслеживание обновления пакетов в дистрибутивах. В качестве обходного пути защиты можно заблокировать загрузку модулей ядра esp4, esp6 и rxrpc:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"



Источник: https://www.opennet.ru/opennews/art.shtml?num=65395 (https://www.opennet.ru/opennews/art.shtml?num=65395)

https://www.opennet.ru/opennews/art.shtml?num=65395
vak: (Знайка)
[personal profile] vak
1. People have exactly one canonical full name.
...
40. People have names.

Прикольный список заблуждений. Есть много в именах такого, что и не снилось нашим мудрецам. 😀
vak: (Робот 3)
[personal profile] vak
Покажу уровень интеллекта нынешнего Claude Code.

На досуге рихтую редактор Notepad Turbo. Хочу добавить юнит тестирование текстового UI. Кто пользовался ncurses, знает, что проверить содержимое экрана та ещё морока. Здесь Turbo Vision: с ним маленько полегче, но тоже не сахар.

Даю задание Клод Коду:
Note: Turbo Vision has support for testing TUI classes. See build/_deps/tvision-src/test/tvision/teditor.test.cpp and other files in that directory as an example. Can we adapt this methodology for testing our NN classes? Please come up with a plan.
Через пять минут получаю детальный анализ кода и план разработки тестов для TUI классов. Запускаю на выполнение - через пятнадцать минут имею 11 тестов в трёх файлах:Сам бы я неделю возился.

Даю следующий запрос:
Many of our classes have Scintilla interfaces. Do we exercise these interfaces in unit tests? Can we learn something useful from existing Scintilla tests in thirdparty/scintilla/test/unit directory?
Получаю неплохой план, командую выполнять. Имеем ещё 35 тестов:

(no subject)

May. 7th, 2026 05:42 pm

Apple Lisa

May. 6th, 2026 11:53 pm
vak: (Аристипп)
[personal profile] vak
Один крутой чувак повторил древний компьютер Apple Lisa на современной программируемой логике.

Подробности в блоге: https://lisalist2.com/index.php/topic,694.0.html

Lisa была мечтой Стива Джобса. В 1983 году такой компьютер казался фантастикой. Разработка была завершена, Lisa вышла в продажу, и... оглушительно провалилась. За эти деньги можно было купить четыре Макинтоша. Стива Джобса уволили.

Майское настроение

May. 6th, 2026 04:24 pm
vak: (Украина)
[personal profile] vak
Россияне угрожают объявить Киеву войну в случае «движухи» на 9 мая.

(no subject)

May. 7th, 2026 01:01 am

(no subject)

May. 6th, 2026 07:58 am
ufm: (Default)
[personal profile] ufm
Вот всегда так. Только думаешь систему на домашнем компе проапгрейдить, так у каноникла - жопа.

(no subject)

May. 6th, 2026 06:35 am
ufm: (Default)
[personal profile] ufm
Repost

Мальчик: прячет хуй в логотипе

Мужчина: разрабатывает и выводит на рынок целую серию хардвера, чтобы сложить хуй из его иконок

src: https://t.me/uxfromhell/11201

(no subject)

May. 5th, 2026 09:45 am
ufm: (Default)
[personal profile] ufm
Россияне, суки, что-ж вы делаете? Она-ж и так на всю голову хворая была. Нафига вы её на тяжёлые наркотики подсадили?

https://www.youtube.com/watch?v=-YDZs7yOqkc

(no subject)

May. 5th, 2026 03:01 am
ufm: (Default)
[personal profile] ufm
Еще из прикольного в #Pony

Кто догадается, не подглядывая, что делает данная операция:

a = b = a

(no subject)

May. 5th, 2026 02:30 am
ufm: (Default)
[personal profile] ufm
разработчики #pony не очень высокого мнения о программистах. И это правильно.
---
When using infix operators in complex expressions a key question is the precedence, i.e. which operator is evaluated first. Given this expression:

1 + 2 * 3 // Compilation failed.

We will get a value of 9 if we evaluate the addition first and 7 if we evaluate the multiplication first. In mathematics, there are rules about the order in which to evaluate operators and most programming languages follow this approach.

The problem with this is that the programmer has to remember the order and people aren’t very good at things like that. Most people will remember to do multiplication before addition, but what about left bit shifting versus bitwise and? Sometimes people misremember (or guess wrong) and that leads to bugs. Worse, those bugs are often very hard to spot.

Pony takes a different approach and outlaws infix precedence. Any expression where more than one infix operator is used must use parentheses to remove the ambiguity. If you fail to do this the compiler will complain.

This means that the example above is illegal in Pony and should be rewritten as:

1 + (2 * 3) // 7

Repeated use of a single operator, however, is fine:

1 + 2 + 3 // 6
vak: (Бодхидхарма)
[personal profile] vak
Продолжаю штудировать статью "Disentangling Boltzmann Brains, the Time-Asymmetry of Memory, and the Second Law". Больцмановские мозги были только цветочки, а вот вам ягодки.

Авторы посвящают ключевую часть раздела 4 («Как и почему интуиция вводит нас в заблуждение») анализу того, почему наши воспоминания кажутся направленными исключительно в прошлое и на чём на самом деле основана эта асимметрия. Их рассуждение проходит через пять шагов и завершается поразительным выводом.

Память как физическая система

Авторы начинают с формализации памяти в физических терминах )
vak: (Бодхидхарма)
[personal profile] vak
Подкину крышесносительной физики вам в ленту.

Представьте себе Вселенную, достигшую теплового равновесия — состояния максимальной энтропии, в котором материя и энергия распределены равномерно, и в среднем ничего интересного не происходит. Это долгосрочная судьба, предсказываемая для нашей Вселенной (иногда называемая «тепловой смертью»).

Однако равновесие не является полностью статичным. Статистическая механика говорит нам, что даже в равновесии постоянно происходят случайные флуктуации. Большинство из них малы, но при достаточно большом времени произойдут сколь угодно большие и маловероятные флуктуации. Подождите достаточно долго — и частицы случайно сложатся в любую конфигурацию, какую можно вообразить: стул, планету, галактику или…

Тревожная идея

мозг. Причём мозг, идентичный вашему прямо сейчас, со всеми вашими воспоминаниями, восприятиями, сенсорными сигналами и ощущением себя как личности, читающей этот текст. Такой мозг — возникающий как случайная флуктуация в остальном пустой равновесной Вселенной — называется «больцмановским мозгом» (BB), в честь Людвига Больцмана, который впервые обратил внимание на подобные рассуждения о флуктуациях в 1890-х годах.

Ключевая особенность: больцмановский мозг был бы субъективно неотличим от настоящего мозга. Он «ощущал» бы, что у него есть тело, «помнил» бы детство, «считал» бы, что живёт во Вселенной возрастом 14 миллиардов лет со звёздами и планетами — но всё это не было бы реальным. «Воспоминания» были бы случайными конфигурациями частиц, не связанными причинно с каким-либо настоящим прошлым.

Почему это проблема

Вот тревожный аргумент:
  1. Если Вселенная проводит чрезвычайно долгое время в состоянии (или близком к состоянию) равновесия, флуктуации, порождающие изолированные мозги, будут происходить бесконечно часто.
  2. Создание целой Вселенной с низкой энтропией — 14 миллиардов лет космической эволюции, приводящих к реальному мозгу на реальной планете — несоизмеримо менее вероятно, чем создание одного лишь мозга.
  3. Следовательно, среди всех наблюдателей, имеющих «ваш» текущий опыт, подавляющее большинство — это больцмановские мозги, а не результат космической истории.
  4. Из вероятностного аргумента самопозиционирования следует, что вы, скорее всего, являетесь больцмановским мозгом.
Это означало бы, что ваши воспоминания не отражают реального прошлого, ваши научные данные не фиксируют реальные эксперименты, а Вселенная, которую вы считаете наблюдаемой, не существует в том виде, как вы о ней думаете.

Почему это трудно отвергнуть

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

Второй ответ — «мы знаем, что второе начало термодинамики выполняется, значит, в прошлом энтропия была ниже» — тоже проблематичен. Откуда мы знаем второе начало? Из экспериментальных данных и воспоминаний. Но именно они и ставятся под сомнение: больцмановский мозг обладал бы идентичными (но ложными) записями. Использование второго начала для опровержения гипотезы BB является круговым рассуждением, поскольку сама вера во второе начало опирается на доверие к нашим воспоминаниям.

Связь с космологией

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

(no subject)

May. 3rd, 2026 10:35 pm
ufm: (Default)
[personal profile] ufm
Repost

Исходники Волков Командерп

Данила Сухарев из Таллина разыскал Всеволода Волкова, получил от него исходники Volkov Commander и опубликовал.

https://github.com/ddanila/vc (https://github.com/ddanila/vc)
https://arvutimuuseum.ee/ru/sw00006-3/ (https://arvutimuuseum.ee/ru/sw00006-3/)

https://www.dreamwidth.org/tools/commentcount?user=vak&ditemid=1538637
comments

https://vak.dreamwidth.org/1538637.html
vak: (Аристипп)
[personal profile] vak
Arvutimuuseum публикует небольшой исторический архив материалов Volkov Commander.

В репозитории сохранены оригинальные архивные файлы, а также распакованные снимки исходных текстов для удобного просмотра. Сейчас в нем есть:
  • ранняя бинарная версия для справки, сохраненная как оригинальный ZIP-архив;
  • архив исходных текстов Volkov Commander 4.05 и распакованное дерево исходников;
  • архив исходных текстов Volkov Commander 4.99.09 и распакованное дерево исходников.
Оригинальные ZIP-файлы оставлены в репозитории, потому что они сохраняют детали, которые сам Git не хранит, включая исходные временные метки отдельных файлов. Коммиты и теги в Git датированы по временным меткам, найденным в архивах, а распакованные деревья исходных текстов добавлены для удобства.

Публикация сопровождается коротким историческим комментарием Всеволода Волкова. В переписке от 1 мая 2026 года он так описал происхождение Volkov Commander:

> Initially, the program was conceived simply as a joke: a tiny assembler
> program that looked like NC 3.0, whose only function was to list directory
> contents. Then, in my spare time, I added individual functions: copying,
> viewing, and so on. After a while, I had something usable. Moreover, on those
> PC/XT-class computers, the program ran significantly faster and took up less
> precious RAM. I began developing it for my own use. Other users noticed the
> program, and it began to spread around the world. Back then, it didn’t have
> its own name. Users came up with the name Volkov Commander.

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

https://github.com/ddanila/vc
https://arvutimuuseum.ee/ru/sw00006-3/
Page generated May. 9th, 2026 06:31 am
Powered by Dreamwidth Studios