https://lwn.net/Articles/905663 #yeswecan #provider

Заметка про одну из моих любимых тем, про инфраструктурные площадки.

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

Насколько я понял, суд запретил деятельность этой компании, но сообщество не понимает, правомерно ли github удалил код, или нет.

Вопрос важный, потому что есть мнение, что код сам по себе не хороший или плохой, плохо(тоже спорное мнение, BTW) если ты его поднимешь и начнешь предоставлять услуги по отмыванию.

https://github.com/tornado-repositories - вот новое место для этого кода, ждем, удалит это github, или нет.

Напомню, что я считаю, что инфраструктурная площадка, конечно, не может стереть этот код, без решения суда.

https://discourse.llvm.org/t/rfc-lldb-telemetry-metrics/64588

Предложение по добавлению телеметрии в LLDB.

TL;DR - Google(а кто бы сомневался) хочет оптимизировать разработку. Держать телеметрию в виде патчей, думаю, неудобно.

G-word, конечно, в тексте не упомянут, сказано про некую "company that ships LLDB in an internal toolchain could send usage to an internal server for usage aggregation, or a distro could send logs to somewhere in..."

А может, они хотят следить за подозрительной активностью своих разработчиков во время отладки - ну чтобы те не ставили break point на код другого отдела.

Who cares.

Лично мне кажется, что внутрикорпоративная телеметрия - норм.

ЖЫРа пока нет, я ожидал большего.

Коллеги, вы, наверняка, решали задачу "купить стол для работы домой".

Я вот тоже захотел, но все, что я вижу, по тем или иным причинам, мне не очень нравится.

Ищу хороший белый стол на ножках, без регулировки по высоте(хожу много), ну, вот, как в офисе Я, например. С рабочей поверхностью примерно метра 1.5 - 2 квадратных, угловой/прямой - уже неважно.

Не вычурный, хорошо сбитый. Не фабрики "Большевичка".

* https://www.ozon.ru/category/kompyuternye-i-pismennye-stoly-38454/?text=стол&from_global=true - пролистал страниц 20, треш, угар, содомия.

* https://market.yandex.ru/catalog--kompiuternye-i-pismennye-stoly/18049603/list?srnum=1677&was_redir=1&rt=11&rs=eJwzKlRy4lK82Hix6cK-C7sVLuwCUnsu7L_Yc7EPKLT1YsOFvRe7L-wUuHWml0uJhYNBQFCDIYuhisPIyMjMwtzSoIHx6OJJrAGMVawcIMYsRsJmAQD1hztq&suggest=1&suggest_type=search&text=стол%20компьютерный&hid=10785221&local-offers-first=0&glfilter=21194330%3A22268790 - да примерно то же самое.

* https://ergostol.ru/goods/stol-lord/ - неплохо, но мне кажется, что дорого.

* https://zamm.ru/catalog/v_nalichii/stol_tandem/stol-pryamoy-tandem-glubina-700-mm-70-sm-dlina-1800-mm-180-sm-tsvet-st-belyy-premium-w1000-st9-aa-25_1/ - пока мой лучший вариант.

* https://www.bestmebelshop.ru/catalog/stoly-kompyuternye/stol-kompyuternyy-viktor-3-bms/ - можно накликать интересную мне конфигурацию, цена норм, но вид, КМК, не очень презентабельный, да и фабрика "Большевичка".

Накидайте ссылок, pls.

https://www.phoronix.com/news/Mesa-CI-Begins-Mold

Нам вот тут пишут, что #mesa перешла в своем CI на #mold.

Я уже несколько рас писал тут, что Mesa - те еще пионеры, с них станется. Один с трудом работающий проект будет линковать другой с трудом работающий проект, nuff said.

Пишут, что линковка стала ажно в 20 раз быстрее. С 20 секунд до одной.

Это довольно удивительно, потому что у меня линковка этого барахла занимает, ну, нисколько.

И, конечно, была интересна мотивация.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/6877

TL;DR - lld даже не участвовал в соревновании.

Ну, реально, сравнили какой-то застывший в развитии лет 10 назад gold, никогда не развивавшийся bfd, и mold.

Mold, конечно, победил.

В основном коммите я бы хотел отметить:

* С особым цинизмом забили на воспроизводимость. md5? Не, не слышали. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17992/diffs?commit_id=eb6ce47d4f75d545aaeed94ebe90c8dfbf43a576#1f8d74bba33f14a5cb315d6aeefff120f8c34506_0_6

* https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17992/diffs?commit_id=eb6ce47d4f75d545aaeed94ebe90c8dfbf43a576#ef0374780e379cec309797720f270719b2ba12fb_83_83 - а вот это вообще мякотка. Mold еще не научился работать без багов, но зато придумал interceptor(mold —run xxx), чтобы уметь оборачивать сборочные системы, и подменять в них линкер.

Ебени они там объелись, короче, что первые пионеры, что вторые.

Почему не lld, тема не раскрыта.

Ну, я спросил, чо. https://gitlab.freedesktop.org/mesa/mesa/-/issues/6877#note_1522796

https://www.opennet.ru/opennews/art.shtml?num=57676

Нам пишут, что G-word DE тоже хочет следить за своими пользователями.

На этот раз все вполне себе централизовано, данные попадут в IBM RedHat GNOME.

Я не понял две вещи:

* Почему не в systemd-то сразу?

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

Слушайте, а вы же замечали, как перед релизом проясняется сознание? #gold

Ну, типа, на одни и те же вещи начинаешь смотреть совсем по другому, очень быстро отделяешь нужное от ненужного.

Что нужно сделать прямо сейчас, любым хаком, а что можно отложить на потом.

У меня, короче, есть долгоиграющая проблема, с шедулером сборок на выполнение.

Там, по сути, есть две особенности, которые осложняют мне жизнь:

* Средняя сборочный узел половину времени жрет 1 ядро, и почти не жрет памяти(configure), а вторую половину времени может выжирать NCPU ядер(make -j). Поэтому выделять шедулером NCPU ядер на все время работы узла - довольно расточительно, машина недогружена.

* Обычно можно считать, что "make -j" упирается в CPU, и на память можно не обращать внимание, это сильно облегчает задачу. Но есть отдельные типы сборок, когда памяти жрется много в среднем, или в пике(это разные проблемы, на самом деле). И если таких узлов запустить в параллель несколько, то они начнут умирать с OOM.

Я че-то вертел, крутил это, удовлетворительного решения пока не нашел.

Но релиз-то скоро!

(я хотел до конца лета успеть, но, кажется, немного не успеваю)

И, на днях, я, как это заведено перед релизом, сказал "ебись оно там все конем", сделал простую аппроксимацию всего этого дела:

* На машине есть N слотов, каждый из которых может херачить NCPU тредов сборки. В этих слотах выполняются "мелкие" сборки, которые не жрут памяти. Это нам дает N * NCPU максимум выполняющихся компиляций. В целом, можно показать, что "make -j" часть этой конструкции выполнится примерно за то же время, как будто если бы сборки работали последовательно, в NCPU потоков, но с бОльшим пиковым потреблением памяти. В предположении, что памяти нам заведомо хватает, это нормально. Зачем тогда вообще делать N слотов, а не 1? Чтобы configure части тоже имели возможность работать параллельно. Почему не сделать N == NCPU, чтобы одновременно могло работать NCPU configure? Потому что памяти начнет не хватать очень быстро с ростом NCPU.

* На машине есть 1 слот для монопольного исполнения "тяжелых" задач.

Тут есть тонкий момент, что сейчас это реализовано так, что эти два пула независимы, то есть, с монопольной тяжелой задачей может вертеться какое-то количество легких, но, в целом, пока это проблемой не является, потому что тяжелые сборки - "концевые".

Work like a charm, привычные уже OOM, когда одновременно шли собираться телега и браузер, пропали.

https://github.com/pg83/ix/commit/eef2c90c8af7b9994464bc1e62f2b2d877c21642 - реализация, она прямо очень простая, потому что раздельные пулы с семафорами у меня уже были(для задач, ходящих в сеть), нужно было только докинуть возможность указать пул прямо в сборочном скрипте.

Слушайте, ну мужик сказал - мужик сделал! #ix_run #dev_shell

  ...
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/mconf.o
  HOSTCC  scripts/kconfig/lxdialog/checklist.o
  HOSTCC  scripts/kconfig/lxdialog/inputbox.o
  HOSTCC  scripts/kconfig/lxdialog/menubox.o
  HOSTCC  scripts/kconfig/lxdialog/textbox.o
  HOSTCC  scripts/kconfig/lxdialog/util.o
  HOSTCC  scripts/kconfig/lxdialog/yesno.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/menu.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/mconf
configuration written to .config

*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

> ix run set/menuconfig -- make HOSTCC=cc menuconfig

До этого, чтобы запустить menuconfig для настроек ядра, я запускал сборку ядра через ix, нажмал ctrl-c, шел в оставшуюся сборочную папку, и там, в настроенном окружении, запускал make menuconfig.

Мне было норм, но людям такое, конечно, стыдно отдавать.

Реализовал обещанную фичу, про возможность запуска команды в произвольном #realm.

Стало удобно.

А еще хорошие новости - одному из наших радиослушателей удалось поставить ix, по последней версии инструкции!

Короче, нет причин не попробовать.

Меня тут спрашивают про мою первую попытку сделать дистрибутив Linux, и что там пошло не так. #gold

Тут особо нечего рассказывать, это был мной автоматизированный LFS. Не в плане того, что все оформить в скрипты, это было сделано позже, а в плане того, что я поверх прикрутил пакетный менеджер, и использовал это много лет.

Пакетный менеджер был примитивен донельзя, я даже не уверен, что оформил его в виде скриптов. Например, команда для установки пакета:

find / -type f | sort > before
sudo make install
find / -type f | sort > after
diff before after > /path/to/store/pkg_name

Команду для удаления пакета, думаю, вы себе можете представить сами.

Это была довольно эффективная схема, я ее использовал несколько лет, регулярно подновляя свой LFS.

Понятно, что это никак не масштабируется, да и нафиг никому не вперлось, ну и амбиций про свой дистрибутив я тогда не имел.

Кстати, раз уж про это зашла речь, то потом я перешел на Генту.

Продержалась она у меня пару лет. Потом я ее снес, потому что постоянно ломалась. Выглядело это так - она начинала глючить какими-то мелкими невоспроизводимыми глюками, и назад это все никак не возвращалось.

Я думаю, что это связано непосредственно с темой моего блога - воспроизводимостью и #bootstrap.

Gentoo - это, по сути, "случайное блуждание" в пространстве версий и настроек софта. Если ты однажды напал на бажную glibc, собрал ее с не менее бажным тогда LTO, а потом пересобрал систему новым компилятором, то можете себе представить, как накапливается ошибка. А потом получившимся бажным sed снова собираете какой-то новый gcc.

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

(кстати, в данном случае это вполне формально определено, если посмотреть на процедуру bootstrap как на отображение B, которое переводит один набор бинарников в другой набор бинарников, то нам нужна такая процедура, чтобы B(B(x)) == B(x), то есть B(x) - неподвижная точка для B. Ничо не путаю?)

После получения промежуточных бинарников(инструменты и компилятор) X = B(I), где I - это live cd от fedora(например), все остальные собранные бинари уже зависят только от X, но не зависят от I(потому что X не зависит от I). Поэтому никакого случайного блуждания, зависящего от набора исходных материалов и промежуточно выбранных настроек, речи не идет.

https://www.phoronix.com/news/Linux-THP-Shrinker

Хорошая тема, facebook хочет включить thp на всех по умолчанию, без madvise. Этому мешает тот факт, что большинство huge page в системе получаются прямо очень недоутилизированными.

Меня эта тема заинтересовала, потому что у меня куда-то утекает память.

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

После полного рестарта потребление - несколько сотен мегабайт.

На что, я понять пока не могу.

Думал, что это может быть связано с тем, ч то у меня thp таки включены по умолчанию, но, видимо, нет, потому что рестарт всех программ должен освободить их huge pages в систему.

Совсем коротко - через несколько дней аптайма у меня top показывает потребление памяти(за вычетом кешей) сильно больше, чем сумма rss всех запущенных программ.

Есть идеи?

Я, на самом-то деле, с какой-то частью этой критики согласен.

1) Совершенно не понимаю похвальбу "функциональным пакетным менеджером". Функциональный язык без side effect для построения описания сборки пакета - это не достижение, а какой-то трешак, как по мне. Почему я должен учить еще 1 язык, который мне больше нигде не пригодится, и погружение shell в которого, кстати, сделано на троечку?

Я считаю, что построитель промежуточного представления(ну, считай, готового скрипта для сборки) имеет право сходить в сеть, и что-то там сделать.

Важно не это, важно то, чтобы отображение содержания готового сборочного скрипта на uid ноды было консистентным. Функциональность языка для описания сборочных скриптов тут, возможно, полезна, но совсем не обязательна.

2) Пути в Nix/Guix уж слишком длинные. Я сначала тоже начал с hex-encoded sha, но потом:

* Укоротил длину хеша, чтобы пути влезали на экран. Я не считаю, что мы тут боремся с malicious package maintainer, который будет как-то пытаться сделать так, чтобы подставить зловредный пакет вместо незловредного. Я считаю, что мы тут боремся с "днями рождения", и uid покороче вполне подходит.

* Потом я заменил hex encode на base64, понятно, почему он компактнее? https://github.com/pg83/mix/blob/d12a0becd86f11b9b45222f6bc29e86f46a66249/core/utils.py#L20 Вместо +/= я взял две совершенно случайных буквы, 'PG', чтобы в путях не было какой-то дичи.

* Но меня очень угнетал тот факт, что эти две буквы незаслуженно часто появляются в путях, и я запилил base62 - https://github.com/pg83/ix/blob/main/core/utils.py#L17, после чего все стало совсем хорошо. В python из коробки есть длинная арифметика, поэтому я не стал жестить с оптимизациями этого кода.

Фотографий холостяцкой норы вам в ленту!

А я сегодня, между прочим, занимался сборкой, но не софта(хотя и софта тоже), а кровати.

Кровати не из Икеи, конечно, собирабельны, но до качества Икеи пока далеко. По крайней мере, пару винтов пришлось недокрутить на полсантиметра, чтобы их головки попали, куда надо.

https://discuss.python.org/t/breaking-continuing-out-of-multiple-loops/18354

Тут вот коллеги обсуждают, не добавить ли им goto в python. Ладно, multi-level break, но я, признаться, не вижу особой разницы.

Мне идея кажется всратой, я считаю, что, если нужен break откуда-то глубоко из кода, то следует выделить нужный блок кода в функцию, и позвать из нее return. Так, конечно, сложнее, но IMHO итоговый код получается чище.

Я в инфраструктуре для жизни очень консервативен.

Недавно пришлось сформулировать, почему, мне это показалось интересным, и я решил этим поделиться.

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

Примеры:

1) Обычный выключатель - это черный ящик, он всегда и везде работает одинаковым образом. Возвратный - это протекшая абстракция выключателя, ситуация, когда она протекает - это когда ты идешь ночью наощупь, и пытаешься что-то включить. Не знаю, как вас, а меня клинит в этот момент, когда я нащупываю выключатель, и мое ощущение реальности говорит мне, что он находится в положении ВКЛ, а света нет. Чтобы эта конструкция стала для меня черным ящиком, нужен сервопривод, который будет синхронизировать состояние выключателей с обеих сторон провода.

2) Обычная доставка Озона для меня черный ящик, международная - нет. Международная не является черным ящиком, потому что Озон дает мне handle на объект в другой системе(в Почте России/ЕМС), и говорит: "если там на стыке что-то пойдет не так, то разбираться ты с этим будешь сам". Я не пользуюсь междунароной доставкой Озона, она для меня недостаточно хорошо изолирована. В случае возникновения проблем мне ПРИДЕТСЯ разбираться, как там все работает.

3) Большинство устройств умного дома, да и умные колонки в целом - это вообще не черный ящик, даже рядом не стояло.

Вот, пример с выходных.

Какая-то рандомная умная колонка умеет притворяться тупой bluetooth колонкой. У меня wifi не работает за пределами дома(в другой раз, не все сразу), и, если ее вынести за пределы дома, я не мог ее подключить по bluetooth. Я подумал, что можно внутри дома подключить, и вынести ее за пределы дома. Но нет, когда она теряла соединение с материнским кораблем, то забывала, что делает, и соединение с bluetooth пропадало. Абстракция "тупая bluetooth колонка" - протекла, приходится разбираться, как оно работает внутри.

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

И пока производители не договорятся настолько, чтобы любой девайс можно было воткнуть в любую сеть умного дома. Ну вот как лампочку в розетку, не думая, подойдет этой лампе электричество от МосЭнергоСбыта, или не подойдет.

Я думаю, что разница между мной, и людьми, которые всем этим добром пользуются - это оценка вероятности факапа. Она, в целом, неизвестна, оценок ее нет.

Я думаю, что пользуются этими приблудами пользователи-оптимисты, которые считают, что жопа не случится, и внутрь лезть не надо будет.

Я же пессимист, и считаю эту(неизвестную) величину большой, и не хочу связываться с потенциальными граблями.

BONUS:

Пример свежей технологии, которая, КМК, уже стала таким черным ящиком - это wifi mesh.

Я себе в доме натянул wifi mesh от xiaomi, так, что на всех трех этажах одна и та же wifi сеть, и переключение между устройствами практически незаметно.

Лакмусовой бумажкой для меня стал эксперимент "а что если взять случайные два узла из четырех, и соединить их проводом". Смогу я, без чтения документации, предсказать, что случится, или не смогу?

Mesh подхватил это соединение, увидел, что между устройствами есть более быстрый link, и начал использовать его.

Лезть в конфиги рутеров не пришлось, оно "само".

Да, еще стоит отметить, что я так консервативен именно в мире аппаратных устройств и реального мира вообще. В случае софта, когда эксперимент дешев, можно быстро провести эксперимент, и/или своими силами все починить, я, конечно, менее консервативен, и склонен к экспериментам.

https://www.phoronix.com/review/apple-m2-compilers

Тут вот Миша экспериментирует с clang и gcc в #asahi Linux.

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

Это, кажется, довольно очевидная вещь, потому что я, как разработчик, тюню код под то окружение, в котором его запускаю.

У нас в Я тоже довольно долго была ситуация, что мы не могли переключиться на clang, потому что важный код под gcc работал на несколько процентов быстрее.

Я воспользовался этим аргументом, и сказал, что мы так никогда не переключимся, а вот если переключимся, и все начнут пользоваться clang, то, через какое-то время, ситуация поменяется.

Так и случилось, буквально, за пару лет.

Что там сейчас, и кто побеждает, я не знаю, потому что там теперь PGO/LTO, а они довольно радикально меняют ситуацию.

Хозяйке на заметку:

Не используйте просто bsdtar для распаковки, он упрется в одно ядро, при использовании ssd/nvme.

Используйте bsdcat | bsdtar, оно займет почти полтора(зависит от кодека, может и к 2 подойти).

https://github.com/pg83/ix/blob/main/pkgs/bld/extract/ix.sh#L9

https://www.ozon.ru/seller/troyanskaya-art-524010

Я готов побиться об заклад, что половина картин по ссылке сделана через midjourney, и продается вполне себе по несколько тысяч рубасов.

Очень предприимчиво, будущее наступило, тихо и незаметно.

Посмотрел я на это, и задумался, не нагенерить ли мне домой таких принтов самому.

Реально, зачем отсматривать тонны шлака, в тщетных попытках найти то, что нравится(тема, стиль), когда можно взять, и сделать?

Про libexec.

В вашей файловой системе, наверняка, есть папочка libexec, или /usr/libexec, в которой лежит всякая дичь, про которую вы не понимаете, зачем она.

Сегодня я расскажу, что же там лежит.

На самом деле, вообще никто не понимает, что туда надо класть, но, по факту, кладут следующее:

* Программы, которые не должен видеть пользователь, но которые может позвать ваша программа. Ну, вот, git кладет туда бинарники или скрипты вида git-X, и тогда вызов драйвера "git X" просто сделает exec на libexec/git-X. Довольно понятно, разумно, не надо замусоривать PATH всяким говном.

* Программы, которые может запустить какая-то библиотека. Это уже немного более странно, но тоже вполне понятно. Например, это libwebkit, который может позвать сетевой воркер, слинкованный в отдельный процесс.

* Этот пункт я называю "всякое всратое говно, которое лично мне доставляет много проблем". Чаще всего это какие-то .so, на которые вызывающая программа хочет сделать LD_PRELOAD для своей подпрограммы. Сложно?

Сейчас станет понятнее.

1) в coreutils есть программа stdbuf. https://manpages.debian.org/stretch/coreutils/stdbuf.1.en.html - теперь вы знаете, как она сделана(перехватывает и подменяет вызовы через LD_PRELOAD).

2) В mold есть режим —run, который перехватывает вызовы линкера, и заменяет их на вызовы mold. Теперь вы тоже знаете, как оно сделано. (кстати, пока писал текст, посмотрел на trunk mold, сейчас они это кладут в lib/mold/, что не по фен-шую)

Я бы это все делал бы через prctl, но то же я.

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

bin/bin/{{pkg_name}} - программы, вызываемые программами
bin/lib/{{pkg_name}} - библиотеки для LD_PRELOAD из третьего пункта
lib/bin/{{pkg_name}} - сетевой процесс в webkit
lib/lib/ я пока не встречал

(реальная схема чуть другая, но для понимания это неважно)

Это мне нужно не только для красоты, но и для понимания, какое барахло удалять из пакета, в зависимости от того, собираем мы его сейчас как lib, или как bin.

Картинка на миллиард.

“Jeflon Zuckergates”

Занимательная ИИ-генетика.
Stable Diffusion

https://twitter.com/TechBroDrip/status/1565711996279959553

Какая прелесть, нам пишут, что вышел свежий gawk - https://www.opennet.ru/opennews/art.shtml?num=57732

А у меня про него, как раз, уже есть две истории:

* Они отказались от поддержки yacc, им теперь bison подавай, поэтому для #bootstrap я заморозил предыдущую версию.

https://github.com/pg83/ix/blob/main/pkgs/bld/boot/5/gawk/ix.sh

* Ну и мякотка - с этим gawk падает сборка ядра:

awk -f ../arch/x86/tools/gen-insn-attr-x86.awk 
  ../arch/x86/lib/x86-opcode-map.txt 
  > /ix/build/GtyXZzklYHhZgPK5/.../inat-tables.c
make[4]: *** [arch/x86/Build:9: 
  .../src/tools/objtool/arch/x86/lib/inat-tables.c] 
Segmentation fault

Буду ли я это репортить?

Я терпеть не могу проекты от GNU, у них какая-то совершенно безумная бюрократия(потому что господин Столлман, полагаю, до сих пор считает, что писать программу для компьютера - это привилегия).

Наверняка придется зарегистрироваться и получать спам с пары списков рассылки только чтобы отправить баг, ну их в жопу.