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

Вот, есть текстовый браузер links http://links.twibright.com/, в нем как бы есть графический режим, но он застрял на linux frame buffer.

Wayland? Да вы чо, ебу дали? Ага, конечно.

Я взял https://devel.dob.sk/links-sdl/ - это набор патчей для links, которые так и не вошли в основную ветку (или, точнее, вошли, а потом их неаккуратно выпилили, ссылку не дам, потому что не нашел links в каком-нить git)

Патч был написан в 2004 году, так просто он под современный links не подошел, но я его творчески доработал - https://github.com/pg83/ix/blob/main/pkgs/bin/links/sdl/sdl.c

Особенно мне доставила строчка https://github.com/pg83/ix/blob/main/pkgs/bin/links/sdl/sdl.c#L381 - я не понимаю, что она значит, но без нее ничего не работало, а скопировал я ее из соседнего драйвера.

Хитрым хаком добавил этот драйвер в сборку - https://github.com/pg83/ix/blob/main/pkgs/bin/links/sdl/ix.sh#L27 . По сути, просто подменил уже встроенный в сборку драйвер на свой, чтобы не возиться со сборочными файлами.

На картинке - links, запущенный поверх SDL1-compat, который является враппером над SDL2, который работает поверх wayland. Классический SDL1 под wayland не работает.

Обратите внимание на то, что там настоящие картинки и шрифты, и что это wayland сессия. Как обычно, делаю скриншот телефоном, чтобы было видно, что все это добро работает на реальном железе!

https://www.phoronix.com/news/GNOME-44-Released

Вот, пожалуйста, действительно, раньше всех!

Сегодня 22-е, я про это написал 18-го.

https://lobste.rs/s/plmk9r/new_names_for_oil_project_oil_shell

В дурке выбирают новое название для oil shell. Нувыпонели.

https://stal-ix.github.io/

У нас, кстати, появилось лого.

https://deno.land/
https://wasmer.io/

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

Первое - это JS runtime, написанный на Rust, поверх V8.

Второе - WA (WebAssembly) runtime, написанный на Rust.

Вот объясните мне, почему это не хайпожорство, почему в этом есть какое-то added value, по сравнению с той же nodejs/v8?

Я не понимаю, почему тут вообще принципиально работает мантра "rust is a safe language":

* рантаймы живут по своим правилам, после того, как ты сделал unsafe jump из rust кода в сгенеренный байткод v8/webassembly, все, ты сам по себе - никакой семантики Rust тут и рядом не стояло, у тебя семантика garbage collected v8/webassembly/whatever. Ну, то есть, у нас тут вступают в строй гарантии кодогенераторов, а не семантики Rust.

* Немножко более subtle штука. Вот сделал я где-то в своем скрипте new File("xxx") (или как там это выглядит в nodejs). Ну у меня "где-то" должен появиться какой-то очень "тонкий" объект, который отвечает за преобразование ABI соответствующего runtime в ABI операционной системы (это, фактически, и есть "мякотка" nodejs или любого такого рантайма). Почему на Rust ее писать особенно хорошо? В моем представлении, это 2 строчки safe кода, на хендл, пришедший из unsafe внешнего мира, который мы преобразуем в параметры для точно такого же unsafe по сути ядра. Сложно написал? На Rust написан код, который распаковывает строку, получает путь в fs, делает syscall, и упаковывает int в качестве результата. Тут, простите, нет места ошибке, на чем ты это не напиши, я не видел CVE про эти места в nodejs/v8.

Утверждение, что deno там сильно безопаснее, чем nodejs - это какое-то фуфло и хайп, нет там причин быть "более безопасным".

#charity

https://lobste.rs/s/v9w2r7/weka_violates_minio_s_open_source

https://blog.min.io/weka-violates-minios-open-source-licenses/

MinIO хуесосят какую-то компанию, решившую распространять бинари от minio в составе своего продукта.

Судя по всему, по делу - их код идет под affero #gpl.

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

Я хочу прицепиться к фразе из пресс-релиза:

"At MinIO, we are dedicated to the principles of open source software"

Ужасная, отвратительная, насквозь двуличная, фраза, которую можно было бы с легкостью переложить на MongoDB/Elastic/прочие "плохие" open source, с которыми не нужно иметь дела.

Несколько раз уже писал, что open source - он разный. Есть "щедрый", который, по сути, про charity, и есть "жадный" - который про "отдайте мне все производные от моего продукта", или, еще хуже, - "первая доза бесплатно".

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

Я не оправдываю компанию, которая решила не соблюдать AGPL, но это битва жабы и гадюки, а не добра и зла!

Не волнуйтесь

#vendor

Сегодня про еще один механизм де-вендоринга, который я называю "кузькина мать".

https://github.com/pg83/ix/blob/main/pkgs/bld/devendor/devendor.sh

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

Этот скрипт делает очень простую штуку - он удаляет все заголовки из заданной директории, и зануляет все исходники.

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

Используется это, например, так: https://github.com/pg83/ix/blob/main/pkgs/bin/yt/ix.sh#L31 https://github.com/pg83/ix/blob/main/pkgs/bin/darktable/ix.sh#L80 (иногда перед configure, а иногда после, перед build фазой)

HN - контора пи%:,:сов.

Я вчера запостил https://news.ycombinator.com/item?id=35302329

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

Возможно, так сработал антиспам, потому что сначала мы промахнулись мимо "Show HN", удалили сообщение, и запостили заново.

Возможно, это какое-то лимбо для новых авторов/постов, но в гайдах нигде про такое не написано.

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

https://bmcgee.ie/posts/2022/11/getting-nixos-to-keep-a-secret/

А вот, как, например, секреты интегрируются в store в nix. TL;DR - криптуются с помощью host ssh key, дальше хранятся в store plain text.

Осталось понять, как в nix работают с ssh host key - участвует он в вычислении хешей, или нет.

https://distrowatch.com/weekly.php?issue=20230327#waiting

В distrowatch, кстати, дистрибутив сначала попадает в лимбо, где он должен потусить хотя бы год. Потому что много нас - а distrowatch один, и им приходят по 2 - 4 новых дистрибутива в неделю. Поэтому надо продержаться хотя бы год, прежде чем быть удостоенным попасть в список Linux дистрибутивов.

https://www.phoronix.com/news/OpenBLAS-0.3.22-Released

"The OpenBLAS 0.3.22 highlights amount to:

- Initial support for processing with the EmScripten JavaScript converter albeit only a single-threaded build for now"

Я просто оставлю это здесь.

Реально, кому может понадобиться реализация BLAS в JavaScript, да еще в виде emscripten?

Будни #bootstrap

Закончил собирать YT. Не весь, пока только сервер.

С удивлением обнаружил, что там нет цели install:

[5968/5968] Linking CXX executable yt/yt/server/all/ytserver-all
ninja: Entering directory `/ix/build/B771eHwr4Dr1dzEA/obj'
ninja: error: unknown target 'install'

Не знаю, что этим имелось в виду, наверное, то, что структуру пакета пусть придумывает человек, решивший это запустить?

Запустить тоже не получилось:

pg# ./ytserver-all
YT_VERIFY(func) at library/cpp/yt/phdr_cache/phdr_cache.cpp:29 in operator()
Illegal instruction

В дебагере это выглядит так - https://gist.github.com/pg83/ae955a0397e6ab36662e5d32ab556c1a

(вообще, довольно дико видеть падение в своем же коде в open source проекте)

Падает все потому, что я собрал yt статически, а у нас он собирается в режиме "dynamic libc", это когда все собирается статически, но линкуется с libc.so.6, чтобы работала подгрузка .so, ну и вот такие хаки с переопределением символов.

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

Собрать полностью статический бинарь было сложно, но, к счастью, я знал, что надо делать:

* экспортируемый код, хотя и умеет собираться с MUSL, при экспорте это свойство не очень сохранил (все ifdef в коде есть, а вот ключика для сборки - нет). Пришлось включать поддержку руками: https://github.com/pg83/ix/blob/main/pkgs/bin/yt/unwrap/ix.sh#L36

* так же пришлось отвязать сборку от #conan - https://github.com/pg83/ix/blob/main/pkgs/bin/yt/unwrap/ix.sh#L28, ну и подхачить всякие пути, чтобы по местам, куда conan подложил бы файлики, лежало что-то разумное - https://github.com/pg83/ix/blob/main/pkgs/bin/yt/unwrap/ix.sh#L81

* так же творчески пришлось запатчить наше расширение для stl - https://github.com/pg83/ix/blob/main/pkgs/bin/yt/unwrap/ix.sh#L48 (у нас, в нашем stl, мы умеем описывать forward declarations для всех классов, чего стандарт до сих пор не умеет)

Почему пришлось развендорить libc++?

Тонкий вопрос.

По зависимостям в сборку приезжал бы мой libc++. И, казалось бы, это не страшно, потому что в Я stl переложен в другой inline namespace - https://github.com/ytsaurus/ytsaurus/blob/main/contrib/libs/cxxsupp/libcxx/include/__wrappers_config#L4, но вот у нас внутри libc++ все еще таргетирован на libcxxrt (это такой рантайм для обработки исключений), а у меня - libc++abi, и вместе они не живут, потому что ABI диктует, где и какие символы должны лежать, получается пересечение.

Поэтому libc++ мне пришлось девендорить, ну и соорудить свой libc++, который бы включал в себя все релевантные патчи. Например, у нас итераторы - это голые указатели, и vector<bool> ведет себя разумно. Вот так я все попатчил - https://github.com/pg83/ix/blob/main/pkgs/lib/c%2B%2B/14/unwrap/ix.sh

Вишенка на торте - сборка всего поддерева кастомным компилятором, с кастомной (патченой) libc++ - https://github.com/pg83/ix/blob/main/pkgs/bin/yt/ix.sh#L4

(я так свободно про все про это пишу, потому что оперирую только теми знаниями, которые мы выложили в open source)

Сложно?

Умеючи - пара вечеров, а так - да, сложно.

https://futureoflife.org/open-letter/pause-giant-ai-experiments/ #strong_ai

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

Проблема в том, что джинна в бутылку уже не загнать:

* Нет такого преступления, на которое не пошел бы капитал, и далее по тексту.

* Ну вот даже и договорятся западные компании промеж себя, но кто помешает заниматься развитием этой темы всему остальному (нерукопожатному) миру?

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

Эту чашу, к сожалению, нам придется испить до дна.

https://tobtu.com/blog/2023/3/breaking-xor-shift-prng/

Вкусный текст про взлом какого-там генератора случайных чисел.

"After the author was told this was using an insecure algorithm "Xor Shift", the author claimed it's secure because it's two different Xor Shift algorithms xored together and has multiple arrays that are randomly selected. Then added "probably the most secure PRNG available" to the read me. OK let's go"

TL;DR - кто-то запилил модуль ядра Linux с реализацией какого-то странного генератора PRNG, который "зачем-то" использовался в каких-то кастомных ядрах от непонятных вендоров:

* комбинирует (через xor) два генератора xor shift
* странно работает с многопоточностью - имеет несколько независимых потоков, тред привязывается к набору потоков

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

https://www.phoronix.com/review/intel-scalability-optimizations

Сравнение Intel Clear Linux с "каким-то другим Linux".

Сравнение, на мой взгляд, весьма интересное.

Видно, что сначала отрыв Intel от Ubuntu невелик, и, скорее всего, это компиляция с правильными ключами.

Но, почти на каждой картинке, наступает момент, когда Intel Clear Linux показывает существенно лучшую масштабируемость.

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

Какие и как, кто-нибудь понимает?

https://www.forbes.ru/tekhnologii/486983-italia-pervoj-v-mire-zapretila-dostup-k-chatgpt

"Поводом для этого стала утечка, о которой OpenAI сообщила на прошлой неделе"

https://github.com/twitter/the-algorithm

https://news.ycombinator.com/item?id=35391433

https://blog.twitter.com/engineering/en_us/topics/open-source/2023/twitter-recommendation-algorithm

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

https://github.com/twitter/the-algorithm/issues/709

Пишут, что twitter выложил алгоритм ранжирования.

Если это первоапрельская шутка - то почему это смешно?

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

Короче, мне срочно нужна пояснительная бригада!

Думаю, сегодня самое лучшее время сказать, что шутка затянулась.

Никакого дистрибутива Linux я не делаю, и делать не собираюсь, что это за велосипедизм?

Весь код, да и пакетная база, на которые я тут ссылался - это переделанные с помощью chatgpt пакеты из проекта Nix https://nixos.org/, дай им бог здоровья.

Всем спасибо, всем пока!

Вечерний #rant

https://github.com/twitter/the-algorithm

Тем временем, репа с этим проектом набрала 37к звезд.

Мне вот интересно, кто эти люди, и что они полайкали в этом проекте?

Я ставлю звезду в трех случаях:

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

КМК, выложенный код не удовлетворяет ни одному из этих критериев.