https://www.youtube.com/watch?v=9vyh1APsMAE #abi
IMHO C++ тоже постепенно тонет. И, вот, IBM зачерпывает водички из-за борта, и заботливо подливает в трюм - https://reviews.llvm.org/D111323
TL;DR - поддержка EBCDIC в libc++. На поддержку ICU у IBM мейнфрейма не нашлось(https://icu.unicode.org/#h.fnv22un0oe4t), а тут на тебе!
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4210.pdf - труп их же триграфов еще остыть не успел.
———
https://www.opennet.ru/opennews/art.shtml?num=56265
Про #Vizio и GPL я тут уже писал. Дело принимает интересный оборот, я даже не знаю, кто из сторон бОльший негодяй. Vizio просит прекратить суд, потому что правообладателям кода типа пофиг. Е;%ла жаба гадюку, что называется.
———
https://dwheeler.com/trusting-trust/
Про технику diverse double compiling для защиты от trusting trust я тут тоже писал, вот, текст с комментариями про это, и с кучей интересных ссылок. Мне особенно зашла https://static.lwn.net/images/conf/rtlws11/random-hardware.pdf - "Analysis of inherent randomness of the Linux kernel"
IMHO C++ тоже постепенно тонет. И, вот, IBM зачерпывает водички из-за борта, и заботливо подливает в трюм - https://reviews.llvm.org/D111323
TL;DR - поддержка EBCDIC в libc++. На поддержку ICU у IBM мейнфрейма не нашлось(https://icu.unicode.org/#h.fnv22un0oe4t), а тут на тебе!
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4210.pdf - труп их же триграфов еще остыть не успел.
———
https://www.opennet.ru/opennews/art.shtml?num=56265
Про #Vizio и GPL я тут уже писал. Дело принимает интересный оборот, я даже не знаю, кто из сторон бОльший негодяй. Vizio просит прекратить суд, потому что правообладателям кода типа пофиг. Е;%ла жаба гадюку, что называется.
———
https://dwheeler.com/trusting-trust/
Про технику diverse double compiling для защиты от trusting trust я тут тоже писал, вот, текст с комментариями про это, и с кучей интересных ссылок. Мне особенно зашла https://static.lwn.net/images/conf/rtlws11/random-hardware.pdf - "Analysis of inherent randomness of the Linux kernel"
YouTube
009. Why C++ Sails When the Vasa Sank - Scott Meyers
The Vasa was a 17th-century Swedish warship which suffered such feature creep during construction that it sank shortly after leaving the harbour on its maiden voyage. In the early 1990s, the C++ standardisation committee adopted the Vasa as a cautionary tale…
Жесть, самый странный #debug в моей жизни.
Я собрал sway, который вместо 6 и 7(пишу с другого хоста) печатает вот то, что вы видите сверху. Я, короче, в шоке. libinput:
Вывод - приходит 1 нажатие, которое далее преобразуется в этот текст. Wayland передает клиентам keystrokes, значит, ошибка в коде клиента. Проверяем:
Единственная подозрительная библиотека, с которой слинкованы все клиенты:
С%ка, я чуть не поседел... Один, печатаю в терминале, и тут на экране появляется "HELLO YES THIS IS DOG"...
Как оно пролезло из теста в реальный бинарь - в следующей серии.
pg@:~/sources/mix strings ~/mix/realm/stable/bin/sway | grep hello
pg@:~/sources/mix ldd ~/mix/realm/stable/bin/sway
не является динамическим исполняемым файлом
pg@:~/sources/mix HELLO YES THIS IS DOGHELLOYES THIS IS DOG^C
pg@:~/sources/mix
pg@:~/sources/mix ldd ~/mix/realm/stable/bin/sway
не является динамическим исполняемым файлом
pg@:~/sources/mix strings ~/mix/realm/stable/bin/sway | grep HELLO
pg@:~/sources/mix strings ~/mix/realm/stable/bin/sway | grep DOG
HB_SCRIPT_DOGRA
G_UNICODE_SCRIPT_DOGRA
pg@:~/sources/mix 12345HELLOYES THIS IS DOG890
bash: 12345HELLOYES: команда не найдена
pg@:~/sources/mix 12345 HELLO YES THIS IS DOG 890
Я собрал sway, который вместо 6 и 7(пишу с другого хоста) печатает вот то, что вы видите сверху. Я, короче, в шоке. libinput:
5 event4 KEYBOARD_KEY +1.513s *** (-1) released
event4 KEYBOARD_KEY +1.967s *** (-1) pressed
HELLO event4 KEYBOARD_KEY +2.059s *** (-1) released
event4 KEYBOARD_KEY +2.345s *** (-1) pressed
YES THIS IS DOG event4 KEYBOARD_KEY +2.433s ***
(-1) released
event4 KEYBOARD_KEY +3.082s *** (-1) pressed
event4 KEYBOARD_KEY +3.330s *** (-1) pressed
^C
Вывод - приходит 1 нажатие, которое далее преобразуется в этот текст. Wayland передает клиентам keystrokes, значит, ошибка в коде клиента. Проверяем:
recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=
[{iov_base="\34\0\0\0\3\0\30\0n\n\0\0
\376\251d\5\10\0\0\0\1\0\0\0", iov_len=3128}, {iov_base=
"", iov_len=968}], msg_iovlen=2, msg_controllen=0,
msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
write(7, "YES THIS IS DOG", 15) = 15
timerfd_settime(6, 0, {it_interval={tv_sec=0,
tv_nsec=40000000}, it_value={tv_sec=0, tv_nsec=600000000}},
NULL) = 0
epoll_pwait(3, [{events=EPOLLIN,
data={u32=2820241184, u64=5633522366240}}], 8, -1, [], 8) = 1
read(7, "YES THIS IS DOG", 24576) = 15
read(7, 0x7ffecfe04050, 24576) = -1 EAGAIN
(Ресурс временно недоступен)
[root@dynamic-vpn pg]# ls -la /proc/3101931/fd/7
lrwx------. 1 pg pg 64 дек 3 07:42 /proc/3101931/fd/7
-> /dev/ptmx
Единственная подозрительная библиотека, с которой слинкованы все клиенты:
/* Multiple keysyms. */
TEST_KEY(KEY_6, "HELLO", 0);
TEST_KEY(KEY_7, "YES THIS IS DOG", 0);
libxkbcommon-xkbcommon-1.3.1/test cat state.c | grep DOG
TEST_KEY(KEY_7, "YES THIS IS DOG", 0);
TEST_KEY(KEY_7, "YES THIS IS DOG", 0);
С%ка, я чуть не поседел... Один, печатаю в терминале, и тут на экране появляется "HELLO YES THIS IS DOG"...
Как оно пролезло из теста в реальный бинарь - в следующей серии.
commit -m "better"
Жесть, самый странный #debug в моей жизни. pg@:~/sources/mix strings ~/mix/realm/stable/bin/sway | grep hello pg@:~/sources/mix ldd ~/mix/realm/stable/bin/sway не является динамическим исполняемым файлом pg@:~/sources/mix HELLO YES THIS IS DOGHELLOYES THIS…
Вот починка, из одной строчки. Дело в том, что make install этого пакета не ставил необходимые данные. Я посмотрел, что с установленной системе эти файлики похожи на содержимое test/data, и просто скопировал тестовые данные в production. Получилось то, что получилось. Где живут настоящие данные, я пока не нашел, поэтому копирую их из системы, чтобы можно было двигаться дальше.
https://github.com/pg83/mix/commit/df138dda7508c7024a372262b8f593bb8fcfb84d#diff-041427458f79449f1c1f36bb41796c56acaaa27b91363293fb6cb62af04a209eR33
https://github.com/pg83/mix/commit/df138dda7508c7024a372262b8f593bb8fcfb84d#diff-041427458f79449f1c1f36bb41796c56acaaa27b91363293fb6cb62af04a209eR33
GitHub
better · pg83/mix@df138dd
statically build packages, for darwin/linux, with clang - better · pg83/mix@df138dd
Forwarded from Daniel Lemire's blog
Science and Technology links (December 4th 2021)
It used to be that all the exciting new processors came from Intel and AMD, and they were meant for your PC. The mobile revolution changed that: it lead to the production of fantastic processors that used little energy. We are now moving back into laptops and servers. The leading supplier of servers is probably Amazon: if you want to run servers for your business, your first choice is often Amazon and its cloud computing infrastructure. And Amazon now makes their own processors. Initially, they made low-cost chips that were secondary to Intel and AMD powerful processors. Amazon released its latest processor, Graviton 3. It is a much wider and deeper chip: The N1 core used in the Graviton2 chip had an instruction fetch unit that was 4 to 8 instructions wide and 4 wide instruction decoder that fed into an 8 wide issue unit that included two SIMD units, two load/store units, three arithmetic units, and a branch unit. With the Perseus N2 core used in the Graviton3, there is an 8 wide fetch unit that feeds into a…
https://lemire.me/blog/2021/12/04/science-and-technology-links-december-4th-2021/
It used to be that all the exciting new processors came from Intel and AMD, and they were meant for your PC. The mobile revolution changed that: it lead to the production of fantastic processors that used little energy. We are now moving back into laptops and servers. The leading supplier of servers is probably Amazon: if you want to run servers for your business, your first choice is often Amazon and its cloud computing infrastructure. And Amazon now makes their own processors. Initially, they made low-cost chips that were secondary to Intel and AMD powerful processors. Amazon released its latest processor, Graviton 3. It is a much wider and deeper chip: The N1 core used in the Graviton2 chip had an instruction fetch unit that was 4 to 8 instructions wide and 4 wide instruction decoder that fed into an 8 wide issue unit that included two SIMD units, two load/store units, three arithmetic units, and a branch unit. With the Perseus N2 core used in the Graviton3, there is an 8 wide fetch unit that feeds into a…
https://lemire.me/blog/2021/12/04/science-and-technology-links-december-4th-2021/
https://repositories.lib.utexas.edu/bitstream/handle/2152/86210/P-2018-02_Intel_Address_Hashing.pdf?sequence=3 (TACC уполномочен заявить!)
Тут вот коллега* прислал красивое. Long story short - у ядер процессора, помимо приватных L1/L2 есть общий LLC. Он устроен примерно так - у каждого ядра есть своя частичка LLC, они все объединены общей шиной, все это организовано в 12-way associative hash table(по хешу от адреса мы понимаем, в какое ядро и в какую его ячейку идти за нужным нам cache line).
Статья про свойства этого хеша, и про то, что false sharing иногда бывает очень сильным.
Статья из тех, что, если бы я ее встретил в дикой природе, я бы прочитал, подивился красивому, и отложил в никуда - построить какую-то разумную мысленную модель вокруг этого IMHO нереально.
Но коллега* прислал статью из-за вполне конкретной причины - одна наша программа с его новым аллокатором ведет себя не очень, судя по всему, из-за причин, описанных в этой статье. Бывает же.
*: Гулин
———
https://tvl.fyi/blog/rewriting-nix
Товарищи решили переписать пакетный менеджер Nix. Причина - он тормозной, что пипец(подтверждаю, обновить 10 пакетов пустым обновлением у меня занимает секунд 20).
1) Товарищи решили поддержать динамическую генерацию графа(когда ноды могут сгенерить новые ноды). Я считаю, что это жесть и путь в никуда.
2) Интересное - "PS: TVL is international, but a lot of the development will take place in our office in Moscow. Say hi if you're around and interested!" - а я вот не знал.
———
https://riscv.org/announcements/2021/12/riscv-ratifies-15-new-specifications/
Теперь risc-v можно официально использовать в серьезных вещах - векторные расширения и гипервизор, в официальных спеках.
Тут вот коллега* прислал красивое. Long story short - у ядер процессора, помимо приватных L1/L2 есть общий LLC. Он устроен примерно так - у каждого ядра есть своя частичка LLC, они все объединены общей шиной, все это организовано в 12-way associative hash table(по хешу от адреса мы понимаем, в какое ядро и в какую его ячейку идти за нужным нам cache line).
Статья про свойства этого хеша, и про то, что false sharing иногда бывает очень сильным.
Статья из тех, что, если бы я ее встретил в дикой природе, я бы прочитал, подивился красивому, и отложил в никуда - построить какую-то разумную мысленную модель вокруг этого IMHO нереально.
Но коллега* прислал статью из-за вполне конкретной причины - одна наша программа с его новым аллокатором ведет себя не очень, судя по всему, из-за причин, описанных в этой статье. Бывает же.
*: Гулин
———
https://tvl.fyi/blog/rewriting-nix
Товарищи решили переписать пакетный менеджер Nix. Причина - он тормозной, что пипец(подтверждаю, обновить 10 пакетов пустым обновлением у меня занимает секунд 20).
1) Товарищи решили поддержать динамическую генерацию графа(когда ноды могут сгенерить новые ноды). Я считаю, что это жесть и путь в никуда.
2) Интересное - "PS: TVL is international, but a lot of the development will take place in our office in Moscow. Say hi if you're around and interested!" - а я вот не знал.
———
https://riscv.org/announcements/2021/12/riscv-ratifies-15-new-specifications/
Теперь risc-v можно официально использовать в серьезных вещах - векторные расширения и гипервизор, в официальных спеках.
https://codeberg.org/dnkl/foot/wiki/Performance #terminal
Я вот решил попробовать какой-то другой эмулятор терминала, один из самых популярных not hardware-accelerated - #foot. Автор, конечно, всячески пытается сделать вид, что он не конкурирует с alacritty:
1) Но вот в тест, где он рвет #alacritty, "срежиссирован" специально - он строчкой ранее пишет, что alacritty гораздо быстрее рендерит пустые глифы, чем заполненные, и, чтобы показать преимущество своего damage control, показывает этот damage control на полностью заполненном терминале. На терминале с небольшим числом непустых глиф даже его damage control не показал бы преимущества.
2) Чтобы его foot не совсем сильно тормозил, он сделал оптимизацию с копированием части буфера через memcpy, если он считает, что она не изменилась. И набажил - у меня при скроллинге, если предыдущие строки немного похожи на следующие, начинаются глюки отрисовки.
Ну не соревнуешься - так не соревнуйся, сделай простую, как 5 копеек, вещь, которой можно пользоваться без hardware acceleration.
———
https://github.com/dvdhrm/kmscon
#kmscon
Какой-то странный проект по замене линуксовой консоли во frame buffer. Я тоже задумался о такой штуке, но мне показалось, что гораздо проще взять киоск-style композитор на основе wlroots, и слинковать в одну программу эмулятор терминала(любой), киоск-style композитор, libinput, и все такое. Получаем бинарь с клиентом-терминалом и сервером-композитором, который умеет в консоль в fb.
———
Я хочу признаться в одной странности, которая меня никак не отпускает. Я строю prefix trie из путей к проектам в своей системе сборки Mix. Что это значит?
lib/pcre, lib/pcre/2, а не lib/pcre2. lib/tom/math, lib/tom/crypt, а не lib/tommath, lib/tomcrypt. lib/z, а не lib/zlib(а это уже что, граф?), net/wget и net/wget/2, и самое любимое - lib/curses/n, lib/curses/netbsd. Пока не сжал dev/build/autoconf, dev/build/automake, но руки чешутся.
Я хз, зачем я это делаю, но мне нравится!
———
У меня было время почитать интернеты про #Vizio и ее предполагаемое нарушение GPL, понял, что зря записал ее в негодяи в прошлый раз. Вот то, что она пытается отменить суд на основе того, что иск подал не владелец кода, это не значит, что они негодяи, и у них нет возможности доказать, что они не используют GPL в своей прошивке, а это просто очень "техническая" вещь - так дешевле.
Я вот решил попробовать какой-то другой эмулятор терминала, один из самых популярных not hardware-accelerated - #foot. Автор, конечно, всячески пытается сделать вид, что он не конкурирует с alacritty:
1) Но вот в тест, где он рвет #alacritty, "срежиссирован" специально - он строчкой ранее пишет, что alacritty гораздо быстрее рендерит пустые глифы, чем заполненные, и, чтобы показать преимущество своего damage control, показывает этот damage control на полностью заполненном терминале. На терминале с небольшим числом непустых глиф даже его damage control не показал бы преимущества.
2) Чтобы его foot не совсем сильно тормозил, он сделал оптимизацию с копированием части буфера через memcpy, если он считает, что она не изменилась. И набажил - у меня при скроллинге, если предыдущие строки немного похожи на следующие, начинаются глюки отрисовки.
Ну не соревнуешься - так не соревнуйся, сделай простую, как 5 копеек, вещь, которой можно пользоваться без hardware acceleration.
———
https://github.com/dvdhrm/kmscon
#kmscon
Какой-то странный проект по замене линуксовой консоли во frame buffer. Я тоже задумался о такой штуке, но мне показалось, что гораздо проще взять киоск-style композитор на основе wlroots, и слинковать в одну программу эмулятор терминала(любой), киоск-style композитор, libinput, и все такое. Получаем бинарь с клиентом-терминалом и сервером-композитором, который умеет в консоль в fb.
———
Я хочу признаться в одной странности, которая меня никак не отпускает. Я строю prefix trie из путей к проектам в своей системе сборки Mix. Что это значит?
lib/pcre, lib/pcre/2, а не lib/pcre2. lib/tom/math, lib/tom/crypt, а не lib/tommath, lib/tomcrypt. lib/z, а не lib/zlib(а это уже что, граф?), net/wget и net/wget/2, и самое любимое - lib/curses/n, lib/curses/netbsd. Пока не сжал dev/build/autoconf, dev/build/automake, но руки чешутся.
Я хз, зачем я это делаю, но мне нравится!
———
У меня было время почитать интернеты про #Vizio и ее предполагаемое нарушение GPL, понял, что зря записал ее в негодяи в прошлый раз. Вот то, что она пытается отменить суд на основе того, что иск подал не владелец кода, это не значит, что они негодяи, и у них нет возможности доказать, что они не используют GPL в своей прошивке, а это просто очень "техническая" вещь - так дешевле.
Codeberg.org
Performance
A fast, lightweight and minimalistic Wayland terminal emulator
Будни #bootstrap.
Собирал тут правильные данные для xkbcommon(ага, те самые "YES THIS IS DOG"). Думал, задачка на 5 минут, но пришлось собрать Perl с вкомпиленными в него модулями. Не то, чтобы я очень хотел это делать, но по цепочке из GNU-того говна из Perl и Bash в проект приехала зависимость от XML::Parser модуля, которому нужен expat. Я сделал это как-то очень странно - подложил в сборку Perl из исходников модуль из Cpan, и он его каким-то чудом подхватил. Магия.
https://github.com/pg83/mix/blob/main/pkgs/dev/lang/perl5/full/mix.sh#L16
Еще из интересных технических решений(в этом же файлике ниже) - сборке этого модуля не хватает miniperl, поэтому я ловко подсовываю вместо miniperl интерпретатор, собранный ранее.
———
https://github.com/nineties/planckforth/blob/main/bootstrap.fs
Потихоньку изучаю Forth, и мне таки начинает казаться(кажется, в этом чате мне об этом уже писали), что для задачи бутстрапа из ничего Forth подходит лучше, чем даже Lisp. Есть что-то магическое, когда поток токенов становится все более и более насыщенным смыслом.
———
Решил тут попробовать воспользоваться firefox, а то chrome у меня в Sway глючит. Мне даже понравилось - с помощью расширения Tree Style Tabs получилось настроить Firefox так, как должен выглядеть браузер(скриншот будет в комментариях, если скриншотилка заработает под Wayland).
IMHO Firefox нужно выкинуть свою реализацию Java Script. Это не то, что придает уникальный привкус браузеру(когда у меня clang начинает побеждать gcc, я выкидываю gcc, и не рефлексирую), на это уходит много ресурсов разработки, и в Мозилле работают не самые крутые инженеры. Java Script от Гугла круче.
Собирал тут правильные данные для xkbcommon(ага, те самые "YES THIS IS DOG"). Думал, задачка на 5 минут, но пришлось собрать Perl с вкомпиленными в него модулями. Не то, чтобы я очень хотел это делать, но по цепочке из GNU-того говна из Perl и Bash в проект приехала зависимость от XML::Parser модуля, которому нужен expat. Я сделал это как-то очень странно - подложил в сборку Perl из исходников модуль из Cpan, и он его каким-то чудом подхватил. Магия.
https://github.com/pg83/mix/blob/main/pkgs/dev/lang/perl5/full/mix.sh#L16
Еще из интересных технических решений(в этом же файлике ниже) - сборке этого модуля не хватает miniperl, поэтому я ловко подсовываю вместо miniperl интерпретатор, собранный ранее.
———
https://github.com/nineties/planckforth/blob/main/bootstrap.fs
Потихоньку изучаю Forth, и мне таки начинает казаться(кажется, в этом чате мне об этом уже писали), что для задачи бутстрапа из ничего Forth подходит лучше, чем даже Lisp. Есть что-то магическое, когда поток токенов становится все более и более насыщенным смыслом.
———
Решил тут попробовать воспользоваться firefox, а то chrome у меня в Sway глючит. Мне даже понравилось - с помощью расширения Tree Style Tabs получилось настроить Firefox так, как должен выглядеть браузер(скриншот будет в комментариях, если скриншотилка заработает под Wayland).
IMHO Firefox нужно выкинуть свою реализацию Java Script. Это не то, что придает уникальный привкус браузеру(когда у меня clang начинает побеждать gcc, я выкидываю gcc, и не рефлексирую), на это уходит много ресурсов разработки, и в Мозилле работают не самые крутые инженеры. Java Script от Гугла круче.
#LLVM news.
https://reviews.llvm.org/rG6a9487df73e9 - полезная проверка, что строки не конструируются от nullptr. Впрочем, начиная с С++2023 соответствующие конструкторы просто забанены.
llvm считает важным упомянуть вот об этом замечательном событии, и мы тоже, вслед за всем прогрессивным человечеством!
"The next Women in Compilers and Tools meetup will take place on December 9th. It will feature Sangeeta Chowdhary’s talk, Fast and Precise Approaches to Detect, Debug, and Repair Numerical Errors."
———
https://www.opennet.ru/opennews/art.shtml?num=56291 #yeswecan #provider
Несколько раз уже писал, что инфраструктурная площадка не может сама себе быть судьей, и решать, кто может пользоваться ее сервисом, а кто нет. Вот пример правильного поведения инфраструктурной площадки, всем бы брать с нее пример. С самим решением суда я не согласен*, но это правильный путь.
*: если кому-то, вдруг, интересно, то я не считаю копирование байт воровством. Впрочем, за контент я стараюсь всегда платить, но не потому что не заплатить было бы кражей, а потому что я хочу, чтобы и завтра у меня был новый контент тоже.
———
https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)
"every frame is perfect", ага.
1) Разработчики Firefox умудрились устроить мне мерцание даже в Wayland, хорошо заметно под нагрузкой.
2) Авторы Sway вообще не понимают, как надо делать композитор. При переключении рабочих столов они сначала рендерят frame, показывают его, а потом уже применяют накопившиеся(пока рабочий стол был скрыт) изменения к итоговой картинке. Это приводит к тому, что первый кадр всегда содержит stale данные. И, соответственно, к мерцанию.
Кстати, лет 10 назад, когда про Wayland еще никто ничего не знал, Я любил мне показывать фотографии вот этой замечательной женщины, когда я что-то искал на тему.
https://yandex.ru/images/search?from=tabbar&text=wayland%20susann
Так я и полюбил латекс.
https://reviews.llvm.org/rG6a9487df73e9 - полезная проверка, что строки не конструируются от nullptr. Впрочем, начиная с С++
llvm считает важным упомянуть вот об этом замечательном событии, и мы тоже, вслед за всем прогрессивным человечеством!
"The next Women in Compilers and Tools meetup will take place on December 9th. It will feature Sangeeta Chowdhary’s talk, Fast and Precise Approaches to Detect, Debug, and Repair Numerical Errors."
———
https://www.opennet.ru/opennews/art.shtml?num=56291 #yeswecan #provider
Несколько раз уже писал, что инфраструктурная площадка не может сама себе быть судьей, и решать, кто может пользоваться ее сервисом, а кто нет. Вот пример правильного поведения инфраструктурной площадки, всем бы брать с нее пример. С самим решением суда я не согласен*, но это правильный путь.
*: если кому-то, вдруг, интересно, то я не считаю копирование байт воровством. Впрочем, за контент я стараюсь всегда платить, но не потому что не заплатить было бы кражей, а потому что я хочу, чтобы и завтра у меня был новый контент тоже.
———
https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)
"every frame is perfect", ага.
1) Разработчики Firefox умудрились устроить мне мерцание даже в Wayland, хорошо заметно под нагрузкой.
2) Авторы Sway вообще не понимают, как надо делать композитор. При переключении рабочих столов они сначала рендерят frame, показывают его, а потом уже применяют накопившиеся(пока рабочий стол был скрыт) изменения к итоговой картинке. Это приводит к тому, что первый кадр всегда содержит stale данные. И, соответственно, к мерцанию.
Кстати, лет 10 назад, когда про Wayland еще никто ничего не знал, Я любил мне показывать фотографии вот этой замечательной женщины, когда я что-то искал на тему.
https://yandex.ru/images/search?from=tabbar&text=wayland%20susann
Так я и полюбил латекс.
😁1
Галопом по Европам.
А вы знали, что можно писать не sed -e s///, а sed -e s|||? Я вот узнал всего полгода назад, и мне это уже сэкономило кучу нервов и сил на эскейпинге /. Наверняка это всем давно известно, и никому не интересно, но я вот не знал.
———
https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/
Мозилла начала делать какую-то очень странную вещь. Часть библиотек они компилируют не в исполняемый код, а в #WASM, и джитят во время работы. Это им дает возможность установить менее большую surface для особо опасного кода, и, типа, так безопаснее. Я имею сказать:
1) Норм тащить в проект 1000000 строк кода, чтобы обезопасить 10000? Впрочем, JIT для WASM и так и так бы был.
2) А почему бы не сделать на WASM весь браузер? https://pbs.twimg.com/media/ELxt9LSXUAMlmIp.jpg А, было же такое - https://en.wikipedia.org/wiki/HotJava , не полетело.
———
https://codeberg.org/dnkl/foot/pulls/461 #foot
https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/2
#terminfo
Я тут пару раз писал про разные эмуляторы терминала, и сокрушался, что их авторы не хотят реализовывать нормальный протокол для tear-free rendering. Потом я написал, что, оказывается, разработчики терминалов в курсе этой проблемы, и даже изобрели syncronized updates, но почему-то все равно не хотят реализовывать правильный протокол. Я еще раз перечитал доступные тексты, и понял, что разработчики терминалов считают проблему решенной - кому надо(я, например), могут использовать syncronized updates, а проблемы негров(ncurses, например) шерифа не волнуют.
Пока читал, выяснил, что эти прекрасные люди не смогли договориться до одного варианта, и придумали аж целых два. Я оба и реализовал: #kitty #foot
https://github.com/pg83/ted/commit/a0aa84567efb7ac0760fde048dae0acf805fd188
В ncurses, наверное, не появится никогда.
А вы знали, что можно писать не sed -e s///, а sed -e s|||? Я вот узнал всего полгода назад, и мне это уже сэкономило кучу нервов и сил на эскейпинге /. Наверняка это всем давно известно, и никому не интересно, но я вот не знал.
———
https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/
Мозилла начала делать какую-то очень странную вещь. Часть библиотек они компилируют не в исполняемый код, а в #WASM, и джитят во время работы. Это им дает возможность установить менее большую surface для особо опасного кода, и, типа, так безопаснее. Я имею сказать:
1) Норм тащить в проект 1000000 строк кода, чтобы обезопасить 10000? Впрочем, JIT для WASM и так и так бы был.
2) А почему бы не сделать на WASM весь браузер? https://pbs.twimg.com/media/ELxt9LSXUAMlmIp.jpg А, было же такое - https://en.wikipedia.org/wiki/HotJava , не полетело.
———
https://codeberg.org/dnkl/foot/pulls/461 #foot
https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/2
#terminfo
Я тут пару раз писал про разные эмуляторы терминала, и сокрушался, что их авторы не хотят реализовывать нормальный протокол для tear-free rendering. Потом я написал, что, оказывается, разработчики терминалов в курсе этой проблемы, и даже изобрели syncronized updates, но почему-то все равно не хотят реализовывать правильный протокол. Я еще раз перечитал доступные тексты, и понял, что разработчики терминалов считают проблему решенной - кому надо(я, например), могут использовать syncronized updates, а проблемы негров(ncurses, например) шерифа не волнуют.
Пока читал, выяснил, что эти прекрасные люди не смогли договориться до одного варианта, и придумали аж целых два. Я оба и реализовал: #kitty #foot
https://github.com/pg83/ted/commit/a0aa84567efb7ac0760fde048dae0acf805fd188
В ncurses, наверное, не появится никогда.
Mozilla Hacks – the Web developer blog
WebAssembly and Back Again: Fine-Grained Sandboxing in Firefox 95
In Firefox 95, we're shipping a sandboxing technology called RLBox — developed with researchers at UC San Diego and the University of Texas
Давеча писал, что перешел с git на svn при использовании github. Увы, недолго музыка играла, не работает переименование каталогов. Пришлось откатиться назад, на inferior решение.
———
Про #monospace шрифты! #font
Мне очень нравится шрифт Input Mono, он вышел 7 лет назад, я его эти 7 лет и использую. Это не очень популярный шрифт, и, когда я заметил его использование на одном там скриншоте в одном там чате, я спросил, "не Input ли это Mono". Оказалось, что это JetBrains Mono. Короче, шрифт 1 в 1. Ммм, не то чтобы они похожи, они 1 в 1, пару отличий я искал с лупой, в side by side terminal.
https://habr.com/ru/post/237179/
https://input.djr.com/
https://fonts.google.com/specimen/JetBrains+Mono
Input круче, потому что это не 1 шрифт, это конструктор шрифтов - можно выбрать много разных вариантов(толщина линий, межстрочный интервал, ширина символов, начертание символов). При некоторых настройках, повторю, получается JetBrains Mono. Кажется, единственное заметное визуальное отличие - это написание буквы "u".
С одной стророны, я рад, что самый лучший шрифт наконец-то стал популярным, с другой - жалко, что не под своим оригинальным именем(думаю, Jet Brains просто купили на него лицензию, упоминания этого факта я нигде не нашел).
———
Assembler porn!
https://github.com/haileys/doslinux/tree/master/script
DOS services for Linux, нет, really. Я думал, шутка, почитал исходники - все честно. Запускаем dos, запускаем в нем TSR, которая будет обслуживать прерывание для входа в Linux, входим в unreal mode(офигенный режим, кстати!), копируем ядро в высокую область памяти, входим в него, вместо init запускаем код, который будет передавать управление в dos TSR, и наоборот(потому что важно, чтобы вызов из dos приходил в контексте какого-нибудь существующего процесса Linux). Что-то по типу того, как работал DOS4GW. Я сначала было подумал, что там MMU-less сборка ядра, но нет, все честно.
https://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/
Или вот генерация лабиринта за 10 байт ассемблера i386(все же, у x86 очень компактная кодировка)!
———
Про #monospace шрифты! #font
Мне очень нравится шрифт Input Mono, он вышел 7 лет назад, я его эти 7 лет и использую. Это не очень популярный шрифт, и, когда я заметил его использование на одном там скриншоте в одном там чате, я спросил, "не Input ли это Mono". Оказалось, что это JetBrains Mono. Короче, шрифт 1 в 1. Ммм, не то чтобы они похожи, они 1 в 1, пару отличий я искал с лупой, в side by side terminal.
https://habr.com/ru/post/237179/
https://input.djr.com/
https://fonts.google.com/specimen/JetBrains+Mono
Input круче, потому что это не 1 шрифт, это конструктор шрифтов - можно выбрать много разных вариантов(толщина линий, межстрочный интервал, ширина символов, начертание символов). При некоторых настройках, повторю, получается JetBrains Mono. Кажется, единственное заметное визуальное отличие - это написание буквы "u".
С одной стророны, я рад, что самый лучший шрифт наконец-то стал популярным, с другой - жалко, что не под своим оригинальным именем(думаю, Jet Brains просто купили на него лицензию, упоминания этого факта я нигде не нашел).
———
Assembler porn!
https://github.com/haileys/doslinux/tree/master/script
DOS services for Linux, нет, really. Я думал, шутка, почитал исходники - все честно. Запускаем dos, запускаем в нем TSR, которая будет обслуживать прерывание для входа в Linux, входим в unreal mode(офигенный режим, кстати!), копируем ядро в высокую область памяти, входим в него, вместо init запускаем код, который будет передавать управление в dos TSR, и наоборот(потому что важно, чтобы вызов из dos приходил в контексте какого-нибудь существующего процесса Linux). Что-то по типу того, как работал DOS4GW. Я сначала было подумал, что там MMU-less сборка ядра, но нет, все честно.
https://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/
Или вот генерация лабиринта за 10 байт ассемблера i386(все же, у x86 очень компактная кодировка)!
Хабр
Input — новый шрифт для программирования
Компания Font Bureau разработала новое семейство шрифтов Input, важнейшим из которых в данном случае для нас является шрифт Input Mono. Кириллица присутствует. Для персонального использования шрифты...
https://www.phoronix.com/scan.php?page=news_item&px=More-Apple-M1-For-Linux-5.17
Вот тут вот пишут, что в ядро добавили еще больше M1. В mesa я никакой активности про драйвер не вижу, увы. И, если уж начал про mesa и аппаратное ускорение, то я осилил статически слинкованный opengl и аппаратно ускоренные драйвера в одном бинаре.
Я думал, будет раза в 3 больше. Впрочем, я нашел интересный способ не линковать #LLVM в каждый бинарь.
https://docs.mesa3d.org/drivers/zink.html - реализация opengl поверх vulkan. #zink
https://www.opennet.ru/opennews/art.shtml?num=51026 - компилятор шейдеров от Valve, который не требует LLVM. Все #хорошее в графическом стеке Linux делают корпорации!
Совместно это дает ускоренный OpenGL, не зависящий от LLVM.
К сожалению, Vulkan мне пока не удалось завести. Разработчики Khronos Group - какие-то невменозы. Я тут уже однажды писал, что делают разрабы, когда у них заканчиваются задачи. Ответ - начинают их себе выдумывать на ровном месте. Вот это и делает Khronos Group. Мегабайты кода аццкого качества, задача которого - загрузить .so, экспортировать из нее функцию, которая вернет структуру, заполненную коллбеками(короче, интерфейс). Где-то там происходит нечто, из-за чего какой-то коллбек от драйвера становится nullptr, и все падает. Копипаста между разными репозиториями одного проекта, где-то заголовки используются из системы, в виде библиотеки, где-то их нужно положить рядышком, во время сборки. Разные репозитории имеют не совместимые друг с другом версии. Там 4 важных репозитория, если взять их последние релизы, они не совместимы друг с другом. У этих гондонов даже есть файлик с номерами ревизий, с которыми, типа, работает. Не с зарелиженными версиями, с ревизиями! https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/master/scripts/known_good.json
Стык загрузчика от Khronos Group и кода Mesa - это жесть. Им там не хватает информации в передаваемых контекстах, поэтому там вовсю всякие пертредные хештаблицы со всякими недостающими запчастями.
Зато я впервые трассировал графический драйвер, это интересно.
Нашел странную упячку в Mesa - там есть шейдерный кеш, и там есть часть ключа в этом кеше, которая зависит от dl_iterate_phdr на какую-то определенную функцию в библиотеке(https://github.com/mesa3d/mesa/blob/main/src/util/build_id.c#L118). Мне кажется, они таким странным способом хотели сказать, что кеш нужно инвалидировать при смене версии библиотеки, очень интересным способом(название исходника как бы намекает на это).
Дело осложнилось тем, что на границе кода #Mesa <-> Khronos Group происходит потеря информации в возвращаемой ошибке, поэтому драйвер просто возвращал "не могу проинициализироваться", без указания из-за чего, и где. Кстати, как эта проблема решается в языках без динамических исключений, типа Rust, когда коллбек имеет более богатую ошибку, чем вызывающий код может прокинуть наверх?
Отдельно, конечно, хочу сказать, что все эти графические API делают люди, которые вообще ничего не понимают в дизайне систем. Компилятор шейдеров в виде библиотеки, которая линкуется в каждую программу? Ну такое. О том, что можно и нужно для этого запустить демон - не, не слышали.
Вот тут вот пишут, что в ядро добавили еще больше M1. В mesa я никакой активности про драйвер не вижу, увы. И, если уж начал про mesa и аппаратное ускорение, то я осилил статически слинкованный opengl и аппаратно ускоренные драйвера в одном бинаре.
pg@:~/sources/mix ls -la /home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
-rwxr-xr-x 1 pg pg 206469240 Dec 10 17:10
/home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
pg@:~/sources/mix strip
/home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
pg@:~/sources/mix ls -la
/home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
-rwxr-xr-x 1 pg pg 78393840 Dec 10 18:51
/home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
Я думал, будет раза в 3 больше. Впрочем, я нашел интересный способ не линковать #LLVM в каждый бинарь.
https://docs.mesa3d.org/drivers/zink.html - реализация opengl поверх vulkan. #zink
https://www.opennet.ru/opennews/art.shtml?num=51026 - компилятор шейдеров от Valve, который не требует LLVM. Все #хорошее в графическом стеке Linux делают корпорации!
Совместно это дает ускоренный OpenGL, не зависящий от LLVM.
К сожалению, Vulkan мне пока не удалось завести. Разработчики Khronos Group - какие-то невменозы. Я тут уже однажды писал, что делают разрабы, когда у них заканчиваются задачи. Ответ - начинают их себе выдумывать на ровном месте. Вот это и делает Khronos Group. Мегабайты кода аццкого качества, задача которого - загрузить .so, экспортировать из нее функцию, которая вернет структуру, заполненную коллбеками(короче, интерфейс). Где-то там происходит нечто, из-за чего какой-то коллбек от драйвера становится nullptr, и все падает. Копипаста между разными репозиториями одного проекта, где-то заголовки используются из системы, в виде библиотеки, где-то их нужно положить рядышком, во время сборки. Разные репозитории имеют не совместимые друг с другом версии. Там 4 важных репозитория, если взять их последние релизы, они не совместимы друг с другом. У этих гондонов даже есть файлик с номерами ревизий, с которыми, типа, работает. Не с зарелиженными версиями, с ревизиями! https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/master/scripts/known_good.json
Стык загрузчика от Khronos Group и кода Mesa - это жесть. Им там не хватает информации в передаваемых контекстах, поэтому там вовсю всякие пертредные хештаблицы со всякими недостающими запчастями.
Зато я впервые трассировал графический драйвер, это интересно.
Нашел странную упячку в Mesa - там есть шейдерный кеш, и там есть часть ключа в этом кеше, которая зависит от dl_iterate_phdr на какую-то определенную функцию в библиотеке(https://github.com/mesa3d/mesa/blob/main/src/util/build_id.c#L118). Мне кажется, они таким странным способом хотели сказать, что кеш нужно инвалидировать при смене версии библиотеки, очень интересным способом(название исходника как бы намекает на это).
Дело осложнилось тем, что на границе кода #Mesa <-> Khronos Group происходит потеря информации в возвращаемой ошибке, поэтому драйвер просто возвращал "не могу проинициализироваться", без указания из-за чего, и где. Кстати, как эта проблема решается в языках без динамических исключений, типа Rust, когда коллбек имеет более богатую ошибку, чем вызывающий код может прокинуть наверх?
Отдельно, конечно, хочу сказать, что все эти графические API делают люди, которые вообще ничего не понимают в дизайне систем. Компилятор шейдеров в виде библиотеки, которая линкуется в каждую программу? Ну такое. О том, что можно и нужно для этого запустить демон - не, не слышали.
Phoronix
More Apple Silicon M1 Bring-Up On The Way For Linux 5.17
The enablement work for supporting Apple's M1 SoC under Linux continues and with the v5.17 kernel next year will be yet more additions.
commit -m "better"
https://www.phoronix.com/scan.php?page=news_item&px=More-Apple-M1-For-Linux-5.17 Вот тут вот пишут, что в ядро добавили еще больше M1. В mesa я никакой активности про драйвер не вижу, увы. И, если уж начал про mesa и аппаратное ускорение, то я осилил статически…
https://suricrasia.online/no-knowledge.html
Какая-то очень крутая тема(НЕ zero knowledge proof, это тоже красивое, но другое) - решение задачи "как бы передать кому-то строку, которая выглядит как hash, но не является хешом от каких-то известных тебе данных". Зачем это надо я ХЗ, но прикольно.
———
Продолжение темы про #Mesa и Vulkan. Я таки заставил его работать, это мне стоило 6 часов напряженной отладки. Бага причудливая. Товарищи сделали такой хак - пометили 100 экспортируемых функций как weak, но реализовали только те, что нужны. Драйвер вулкана в такой ситуации получал непустые реализации + nullptr для пустых. В случае статической линковки weak сработал не так, и в качестве реализаций взялись первые нулевые weak символы.
Vulkan, в целом, работоспособен, Sway с ним - нет. Если включить WLR_RENDERER=vulkan, то получаю черный экран, и это неудивительно, поддержка Vulkan в Sway появилась месяц назад. Если делаю MESA_LOADER_DRIVER_OVERRIDE=zink(фактически, форсирую реализацию OpenGL, которая работает поверх Vulkan), то получаю слегонца битую картинку. Неудивительно, думаю, Sway в таком интересном setup запускал только я.
Надо сказать, своей цели "собрать LLVM-free hardware accelerated stack" я достиг, бинарник Sway стал занимать 20 мегабайт.
Немного в сторону - прикольно осознавать, что подобную инсталляцию(musl + static build + clang + #zink + vulkan + sway) на этой планете, скорее всего, соорудил только 1 человек, хотя это тот еще неуловимый Джо.
Узнал прекрасное - в Linux есть 3 драйвера для AMD(Mesa, #AMDVLK, AMDVLK + proprietary code). https://www.linux.org.ru/forum/talks/16466478 Попробовал завести AMDVLK, но он требует X.
Valve топит за Mesa, потому что LLVM генерит медленные шейдеры.
Какая-то очень крутая тема(НЕ zero knowledge proof, это тоже красивое, но другое) - решение задачи "как бы передать кому-то строку, которая выглядит как hash, но не является хешом от каких-то известных тебе данных". Зачем это надо я ХЗ, но прикольно.
———
Продолжение темы про #Mesa и Vulkan. Я таки заставил его работать, это мне стоило 6 часов напряженной отладки. Бага причудливая. Товарищи сделали такой хак - пометили 100 экспортируемых функций как weak, но реализовали только те, что нужны. Драйвер вулкана в такой ситуации получал непустые реализации + nullptr для пустых. В случае статической линковки weak сработал не так, и в качестве реализаций взялись первые нулевые weak символы.
Vulkan, в целом, работоспособен, Sway с ним - нет. Если включить WLR_RENDERER=vulkan, то получаю черный экран, и это неудивительно, поддержка Vulkan в Sway появилась месяц назад. Если делаю MESA_LOADER_DRIVER_OVERRIDE=zink(фактически, форсирую реализацию OpenGL, которая работает поверх Vulkan), то получаю слегонца битую картинку. Неудивительно, думаю, Sway в таком интересном setup запускал только я.
Надо сказать, своей цели "собрать LLVM-free hardware accelerated stack" я достиг, бинарник Sway стал занимать 20 мегабайт.
Немного в сторону - прикольно осознавать, что подобную инсталляцию(musl + static build + clang + #zink + vulkan + sway) на этой планете, скорее всего, соорудил только 1 человек, хотя это тот еще неуловимый Джо.
Узнал прекрасное - в Linux есть 3 драйвера для AMD(Mesa, #AMDVLK, AMDVLK + proprietary code). https://www.linux.org.ru/forum/talks/16466478 Попробовал завести AMDVLK, но он требует X.
Valve топит за Mesa, потому что LLVM генерит медленные шейдеры.
www.linux.org.ru
О наболевшем: RADV vs AMDVLK. Почему Valve поддерживает RADV и как это в будущем может аукнуться?
Привет. Многие наверняка знают, что на Линукс существует два опен-сурсных драйвера для видеокарт АМД: AMDVLK (официальный) RADV (неофициальный, из Mesa) AMDVLK является кросс-платформенным драйвером (Windows, Linux, Stadia и др), и именно поэтому АМД...
👍1
commit -m "better"
https://suricrasia.online/no-knowledge.html Какая-то очень крутая тема(НЕ zero knowledge proof, это тоже красивое, но другое) - решение задачи "как бы передать кому-то строку, которая выглядит как hash, но не является хешом от каких-то известных тебе данных".…
Good news, everyone!
Я прочел https://www.phoronix.com/scan.php?page=article&item=zink-sub-alloc&num=2, установил себе #Mesa посвежее, и у меня заработала связка Sway + #zink + Vulkan!
Вообще, имею вам сказать, что аппаратные драйвера OpenGL, скорее всего, просто умрут, потому что зачем? По словам разработчиков Mesa Vulkan - это такой Gallium 2.0(не могу найти цитату), поэтому логично реализацию OpenGL строить поверх них. Ну и в MacOS будет рулить MoltenVK(https://moltengl.com/moltenvk/, + OpenGL поверх него), потому что никто в своем уме на Metal разрабатывать не будет.
———
https://www.ee.ryerson.ca/~elf/hack/recovery.html
Очень старый текст, напомнил мне ситуацию, в которой приходится запускать скрипты для сборки самых ранних пакетов. Например, первую сборку musl приходится делать в ситуации, когда у меня есть только dash + компилятор. Нет даже cat, echo.
Зацените, как я ловко вывожу блок текста в файл, пользуясь только shell builtin!
https://github.com/pg83/mix/blob/main/pkgs/boot/1/lib/musl/mix.sh#L18
Или как ловко, сразу после сборки libmusl.a, собираю себе с ним подручный вариант cat, чтобы заполнить все файлы, требующиеся для пакета:
https://github.com/pg83/mix/blob/main/pkgs/boot/1/lib/musl/mix.sh#L96
https://github.com/pg83/mix/blob/main/pkgs/boot/1/lib/musl/mix.sh#L121
Самый главный хак этого сборочного скрипта - что сборку сразу ведем в outdir, чтобы не заморачиваться с копированием файлов после сборки(команда cp появится позже).
Я считаю, что за этот файл мне нужно дать Нобелевку по posix sh!
———
https://www.kernel.org/doc/html/latest/admin-guide/syscall-user-dispatch.html
Читал тут про Wine 7.0, и случайно узнал, что современный Linux умеет обрабатывать любой способ захода в ядро, чтобы более хорошо эмулировать всякие чужеродные системы.
———
https://arxiv.org/abs/2110.01098
Говорят, что, если в Rust добавить GC, то студенты быстрее его осваивают. Норм же тема!
Я прочел https://www.phoronix.com/scan.php?page=article&item=zink-sub-alloc&num=2, установил себе #Mesa посвежее, и у меня заработала связка Sway + #zink + Vulkan!
Вообще, имею вам сказать, что аппаратные драйвера OpenGL, скорее всего, просто умрут, потому что зачем? По словам разработчиков Mesa Vulkan - это такой Gallium 2.0(не могу найти цитату), поэтому логично реализацию OpenGL строить поверх них. Ну и в MacOS будет рулить MoltenVK(https://moltengl.com/moltenvk/, + OpenGL поверх него), потому что никто в своем уме на Metal разрабатывать не будет.
———
https://www.ee.ryerson.ca/~elf/hack/recovery.html
Очень старый текст, напомнил мне ситуацию, в которой приходится запускать скрипты для сборки самых ранних пакетов. Например, первую сборку musl приходится делать в ситуации, когда у меня есть только dash + компилятор. Нет даже cat, echo.
Зацените, как я ловко вывожу блок текста в файл, пользуясь только shell builtin!
https://github.com/pg83/mix/blob/main/pkgs/boot/1/lib/musl/mix.sh#L18
Или как ловко, сразу после сборки libmusl.a, собираю себе с ним подручный вариант cat, чтобы заполнить все файлы, требующиеся для пакета:
https://github.com/pg83/mix/blob/main/pkgs/boot/1/lib/musl/mix.sh#L96
https://github.com/pg83/mix/blob/main/pkgs/boot/1/lib/musl/mix.sh#L121
Самый главный хак этого сборочного скрипта - что сборку сразу ведем в outdir, чтобы не заморачиваться с копированием файлов после сборки(команда cp появится позже).
Я считаю, что за этот файл мне нужно дать Нобелевку по posix sh!
———
https://www.kernel.org/doc/html/latest/admin-guide/syscall-user-dispatch.html
Читал тут про Wine 7.0, и случайно узнал, что современный Linux умеет обрабатывать любой способ захода в ядро, чтобы более хорошо эмулировать всякие чужеродные системы.
———
https://arxiv.org/abs/2110.01098
Говорят, что, если в Rust добавить GC, то студенты быстрее его осваивают. Норм же тема!
Phoronix
Zink Mesa 21.3-dev Benchmarks - Increasingly Capable Of Running OpenGL Games Atop Vulkan
The open-source DDraceNetwork cooperative platformer game was seeing some nice improvements thanks to the Zink sub-allocator code.
https://twitter.com/nicuveo/status/1469963644775682049
Красивое, просто показываю.
———
https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=4
Не люблю perf тесты, которые делаю не сам. Вот zstd на FreeBSD - это что? Так же не бывает, что cpu intensive задача на разных OS в 10 раз отличалась.
———
https://github.com/NixOS/nixpkgs/issues/136926 - сломана кросс-сборка #Mesa.
https://habr.com/ru/post/591979/ - про основы кросс-компиляции в разных OSS системах сборки. Спойлер - Meson OK, #autohell и CMake - жесть.
Представление о 6 действиях, как собрать cross-gcc https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
Про CMake скажу отдельно - у него разных способов контролировать пути поиска тех или иных артефактов штук 10, разных, странных - поштырьте по ссылкам(https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html#cmake-system-prefix-path).
Насколько я понимаю, для Mix это нормальное дело. Я строю Nix так, что он всегда кросс-компилирует, даже когда host == target. Это приводит к следующему:
1) Собрать программу полностью в debug/asan/msan/etc - плевое дело. Пользователи интерпрайзных систем сборки к этому привыкли, для OSS это внове.
2) Несколько необычный режим сборки промежуточных артефактов - каждый таргет может быть собран в 3 режимах - lib, bin, data. Нужно это потому, что разные артефакты нужны под host и target платформы, а еще библиотека может зависеть сама от себя, но от своих данных(это достаточно странно, но больше никак не сделать возможность удаления .a файлов, оставляя данные для них(кстати, вот как раз с динамической сборкой это проще - никого не удивляет, что .so живет рядом с share/)).
https://github.com/pg83/mix/blob/main/pkgs/lib/wayland/protocols/mix.sh - вот прекрасный пример, программа может зависеть от библиотеки lib/wayland, от бинарников из lib/wayland, и во время работы ей тоже нужны бинарники из lib/wayland. Если посчитать, то это 3 разных таргета в случае кросс-сборки. В случае host == target часть можно пооптимизировать, но я пока не занимался.
Красивое, просто показываю.
———
https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=4
Не люблю perf тесты, которые делаю не сам. Вот zstd на FreeBSD - это что? Так же не бывает, что cpu intensive задача на разных OS в 10 раз отличалась.
———
https://github.com/NixOS/nixpkgs/issues/136926 - сломана кросс-сборка #Mesa.
https://habr.com/ru/post/591979/ - про основы кросс-компиляции в разных OSS системах сборки. Спойлер - Meson OK, #autohell и CMake - жесть.
Представление о 6 действиях, как собрать cross-gcc https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
Про CMake скажу отдельно - у него разных способов контролировать пути поиска тех или иных артефактов штук 10, разных, странных - поштырьте по ссылкам(https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html#cmake-system-prefix-path).
Насколько я понимаю, для Mix это нормальное дело. Я строю Nix так, что он всегда кросс-компилирует, даже когда host == target. Это приводит к следующему:
1) Собрать программу полностью в debug/asan/msan/etc - плевое дело. Пользователи интерпрайзных систем сборки к этому привыкли, для OSS это внове.
2) Несколько необычный режим сборки промежуточных артефактов - каждый таргет может быть собран в 3 режимах - lib, bin, data. Нужно это потому, что разные артефакты нужны под host и target платформы, а еще библиотека может зависеть сама от себя, но от своих данных(это достаточно странно, но больше никак не сделать возможность удаления .a файлов, оставляя данные для них(кстати, вот как раз с динамической сборкой это проще - никого не удивляет, что .so живет рядом с share/)).
https://github.com/pg83/mix/blob/main/pkgs/lib/wayland/protocols/mix.sh - вот прекрасный пример, программа может зависеть от библиотеки lib/wayland, от бинарников из lib/wayland, и во время работы ей тоже нужны бинарники из lib/wayland. Если посчитать, то это 3 разных таргета в случае кросс-сборки. В случае host == target часть можно пооптимизировать, но я пока не занимался.
Twitter
Antoine Leblanc
"Two hosts are considered equivalent if both host names can be resolved into the same IP addresses[.] Since hosts comparison requires name resolution, this operation is a blocking operation." Oh no. OH NO. twitter.com/floydophone/st…
https://www.opennet.ru/opennews/art.shtml?num=56295 #lust
https://harmful.cat-v.org/software/c++/linus
С одной стороны, перестать писать ядро на C - это must have, это давно понимают все большие корпорации(которые и пишут ядро). С другой - для Линуса начать использовать C++ означало бы потерять лицо. Поэтому это будет Rust. Нет, я не думаю, что Rust для этой цели подошел бы значительно лучше С++, но это неважно, оба подходят для этой задачи существенно лучше, чем С.
———
https://github.com/harfbuzz/harfbuzz/issues/2524
Столкнулся тут с прекрасным. Коллеги, на самом деле, еще не поняли, что там по настоящему происходит. Цикл включает в себя не только freetype и #harfbuzz, но и cairo, и #fontconfig.
"Another problem is that currently we include hb-ft in libharfbuzz.so. So removing it will be an ABI break for linux distros. I suggest we do that for harfbuzz 4.0.0. We are just about to release harfbuzz 3.0.0. That gives us about a year to figure out what to do."
"And sadly our package manager cannot automatically do the first-without-then-with-harfbuzz shuffle."
Им разрешение кольцевых зависимостей в пакетных менеджерах подавай. "Дебилы, бл;%:" (с), слов нет.
———
https://github.com/inconvergent/weird
Красивые картинки. Их автору бы познакомиться со Стивеном "Наше все" Вольфрамом(https://habr.com/ru/post/518206/).
https://harmful.cat-v.org/software/c++/linus
С одной стороны, перестать писать ядро на C - это must have, это давно понимают все большие корпорации(которые и пишут ядро). С другой - для Линуса начать использовать C++ означало бы потерять лицо. Поэтому это будет Rust. Нет, я не думаю, что Rust для этой цели подошел бы значительно лучше С++, но это неважно, оба подходят для этой задачи существенно лучше, чем С.
———
https://github.com/harfbuzz/harfbuzz/issues/2524
Столкнулся тут с прекрасным. Коллеги, на самом деле, еще не поняли, что там по настоящему происходит. Цикл включает в себя не только freetype и #harfbuzz, но и cairo, и #fontconfig.
"Another problem is that currently we include hb-ft in libharfbuzz.so. So removing it will be an ABI break for linux distros. I suggest we do that for harfbuzz 4.0.0. We are just about to release harfbuzz 3.0.0. That gives us about a year to figure out what to do."
"And sadly our package manager cannot automatically do the first-without-then-with-harfbuzz shuffle."
Им разрешение кольцевых зависимостей в пакетных менеджерах подавай. "Дебилы, бл;%:" (с), слов нет.
———
https://github.com/inconvergent/weird
Красивые картинки. Их автору бы познакомиться со Стивеном "Наше все" Вольфрамом(https://habr.com/ru/post/518206/).
www.opennet.ru
Третья редакция патчей для ядра Linux с поддержкой языка Rust
Мигель Охеда (Miguel Ojeda), автор проекта Rust-for-Linux, предложил для рассмотрения разработчиками ядра Linux третий вариант компонентов для разработки драйверов устройств на языке Rust. Поддержка Rust рассматривается как экспериментальная, но уже согласована…
❤1👎1
https://chromium.googlesource.com/angle/angle/
#ANGLE
Я, давеча, писал про #zink - это OpenGL, реализованный поверх Vulkan(у меня сейчас на нем крутится Sway). Вот это похожая штука, только от Гугла. Я люблю код от Гугла, он у меня не вызывает неприятных эмоций(кроме ограничения на длину строки, но это лечится clang-format). Поэтому надо попробовать! Вырисовывается такой Mesa-free stack - ANGLE + #AMDVLK, или дрова от #Mesa для Vulkan + ANGLE.
———
Меня раздражают фанатики Rust.
Вернее, нет. Меня раздражают фанатики, фанатики Rust в том числе, никаких исключений.
Фанатики Rust хотят, чтобы все было через Rust, никаких исключений. Поэтому они, например, оборачивают C-код в свои crate. Например, libgit2 в Rust - это обернутый C libgit2. При этом, так как это же, все таки, фанатики, они хотят делать вид, что никакого C там нет, поэтому эмбеддят исходники libgit2 прямо в свой crate. А чо, удобно, не нужно возиться с пакетным менеджером, все сделает cargo. Проблемы maintainer никого не волнуют, конечно.
Так как я не люблю фанатизм ни в каком виде, то я такую деятельность не одобряю. К счастью, есть GPL(враг моего врага - мой друг!), поэтому обернуть libiconv таким образом нельзя. Поэтому я очень радуюсь, как у меня обламывается cargo, и просит libiconv из системы.
Ну, и, к счастью, есть проекты, до которых Rust вряд ли когда-нить доберется, типа Qemu. Желание писать на верхнеуровневых безопасных языках чаще всего антикореллирует с желанием копаться в хардверных мануалах, это хуже чем C.
"К счастью", "радуюсь" - потому что я против фанатизма, а вот эти конкретные факты этому конкретно фанатизму мешают. Забавно, что эти факты сами по себе мне тоже не очень ОК, GPL я не люблю, и в Qemu не помешало бы немного C++/Rust.
Это НЕ анти-Rust пост, я уверен, что однажды Rust и его поклонники переживут эти детские болезни, и не будут бояться(а то, вдруг, кто-то ткнет пальцем, и скажет, что чей-та у вас эта либа не на Rust!) использовать код из системы(и из системного пакетного менеджера).
#ANGLE
Я, давеча, писал про #zink - это OpenGL, реализованный поверх Vulkan(у меня сейчас на нем крутится Sway). Вот это похожая штука, только от Гугла. Я люблю код от Гугла, он у меня не вызывает неприятных эмоций(кроме ограничения на длину строки, но это лечится clang-format). Поэтому надо попробовать! Вырисовывается такой Mesa-free stack - ANGLE + #AMDVLK, или дрова от #Mesa для Vulkan + ANGLE.
———
Меня раздражают фанатики Rust.
Вернее, нет. Меня раздражают фанатики, фанатики Rust в том числе, никаких исключений.
Фанатики Rust хотят, чтобы все было через Rust, никаких исключений. Поэтому они, например, оборачивают C-код в свои crate. Например, libgit2 в Rust - это обернутый C libgit2. При этом, так как это же, все таки, фанатики, они хотят делать вид, что никакого C там нет, поэтому эмбеддят исходники libgit2 прямо в свой crate. А чо, удобно, не нужно возиться с пакетным менеджером, все сделает cargo. Проблемы maintainer никого не волнуют, конечно.
Так как я не люблю фанатизм ни в каком виде, то я такую деятельность не одобряю. К счастью, есть GPL(враг моего врага - мой друг!), поэтому обернуть libiconv таким образом нельзя. Поэтому я очень радуюсь, как у меня обламывается cargo, и просит libiconv из системы.
Ну, и, к счастью, есть проекты, до которых Rust вряд ли когда-нить доберется, типа Qemu. Желание писать на верхнеуровневых безопасных языках чаще всего антикореллирует с желанием копаться в хардверных мануалах, это хуже чем C.
"К счастью", "радуюсь" - потому что я против фанатизма, а вот эти конкретные факты этому конкретно фанатизму мешают. Забавно, что эти факты сами по себе мне тоже не очень ОК, GPL я не люблю, и в Qemu не помешало бы немного C++/Rust.
Это НЕ анти-Rust пост, я уверен, что однажды Rust и его поклонники переживут эти детские болезни, и не будут бояться(а то, вдруг, кто-то ткнет пальцем, и скажет, что чей-та у вас эта либа не на Rust!) использовать код из системы(и из системного пакетного менеджера).
https://asahilinux.org/2021/12/progress-report-oct-nov-2021/
Срочно в номер! #asahi
Красивое, интересное(правда!), но только показывают. C GPU я не понимаю, что происходит. "Userspace in good shape, kernel work starting soon". Вот совершенно не понимаю. Казалось бы, ядерная часть должна быть проще - фактически, в ядре живет диспатчер буферов для отрисовки, kms(довольно сложная часть), и диспетчер очереди команд на буфера для отрисовки. Сложная часть(компиляция шейдеров в код для GPU) живет как раз в user space. Возможно, у Apple GPU есть какой-то прообраз(Mali?), для которого уже есть готовая реализация шейдеров, но я этого не заметил.
Срочно в номер! #asahi
Красивое, интересное(правда!), но только показывают. C GPU я не понимаю, что происходит. "Userspace in good shape, kernel work starting soon". Вот совершенно не понимаю. Казалось бы, ядерная часть должна быть проще - фактически, в ядре живет диспатчер буферов для отрисовки, kms(довольно сложная часть), и диспетчер очереди команд на буфера для отрисовки. Сложная часть(компиляция шейдеров в код для GPU) живет как раз в user space. Возможно, у Apple GPU есть какой-то прообраз(Mali?), для которого уже есть готовая реализация шейдеров, но я этого не заметил.
asahilinux.org
Progress Report: October-November 2021 - Asahi Linux
Porting Linux to Apple Silicon
❤1
https://github.com/rui314/mold
Вышла версия 1.0 самого быстрого linker. Поддержки Mach-O все еще нет, в случае батч-сборки Mold, скорее, не нужен(потому что линковка в 1 поток проще ложится на параллельную сборку). Ну и чувак "странноват" - он хочет этот linker продать. https://github.com/rui314/mold/blob/main/LICENSE
Никто не хочет себе прикупить личный linker?
———
https://github.com/tsujan/Kvantum/tree/master/Kvantum
В Linux, оказывается, завезлиDisplay Post Script SVG для отрисовки.
———
https://3dnews.ru/1056018/tsmc-zaprosila-u-intel-avans-za-rezervirovanie-moshchnostey-dlya-proizvodstva-3nm-produktsii
Легкий троллинг Intel. Интересно, как Intel собирается вылезать из этой жопы? Последнее поколение процессоров у нее снова провальное.
Кстати, я тут хотел снова написать, какой же классный Xiaomi, но вместо этого напишу вот что - я продаю MacBook Pro(2021, 16 inch, начальная конфигурация, незадорого, если интересно - напишите), и покупаю себе 2 - 3 Mac Mini вместо. Будут у меня выполнять роль сборочного сервера.
CI для Mix я решил строить на Mac Mini, они в 5 раз быстрее на 1 ядро на задачах сборки. Никакие облака сейчас рядом с M1 в плане CI даже и рядом не стоят. Тем более, я умею кросс-компилировать с Darwin на Linux.
Вышла версия 1.0 самого быстрого linker. Поддержки Mach-O все еще нет, в случае батч-сборки Mold, скорее, не нужен(потому что линковка в 1 поток проще ложится на параллельную сборку). Ну и чувак "странноват" - он хочет этот linker продать. https://github.com/rui314/mold/blob/main/LICENSE
Никто не хочет себе прикупить личный linker?
———
https://github.com/tsujan/Kvantum/tree/master/Kvantum
В Linux, оказывается, завезли
———
https://3dnews.ru/1056018/tsmc-zaprosila-u-intel-avans-za-rezervirovanie-moshchnostey-dlya-proizvodstva-3nm-produktsii
Легкий троллинг Intel. Интересно, как Intel собирается вылезать из этой жопы? Последнее поколение процессоров у нее снова провальное.
Кстати, я тут хотел снова написать, какой же классный Xiaomi, но вместо этого напишу вот что - я продаю MacBook Pro(2021, 16 inch, начальная конфигурация, незадорого, если интересно - напишите), и покупаю себе 2 - 3 Mac Mini вместо. Будут у меня выполнять роль сборочного сервера.
CI для Mix я решил строить на Mac Mini, они в 5 раз быстрее на 1 ядро на задачах сборки. Никакие облака сейчас рядом с M1 в плане CI даже и рядом не стоят. Тем более, я умею кросс-компилировать с Darwin на Linux.
GitHub
GitHub - rui314/mold: mold: A Modern Linker 🦠
mold: A Modern Linker 🦠. Contribute to rui314/mold development by creating an account on GitHub.
#cross #cmake В CMake нет кросс-компиляции. Видимо, ее было сложно добавить постфактум(ну, не знаю, не глобальную переменную с набором environment завести, а сделать два экземпляра класса - для target, и для host). Вообще, добавить кросс-компиляцию в систему, которая для этого не дизайнилась изначально, сложно.
Ну и что же делать? Вот, вместо того, чтобы таки запилить кросс-компиляцию, товарищи запилили страничку, на которой, на голубом глазу, утверждают, что кросс-компиляция в CMake есть!
https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html
Конечно есть! Только вам надо 1 раз прогнать cmake, собрать все провалившиеся вызовы TRY_RUN, записать их предполагаемые результаты в файлик, и прогнать это говно еще раз!
https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html#using-compile-checks
Вдумчивый читатель спросит - а как в сборке запустить собранный host бинарь? А точно так же! Собираешь бинарь отдельно(твои проблемы, как), и подсовываешь его в cmake!
https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html#running-executables-built-in-the-project
Так же несколько раз по тексту эти господа прозрачно намекают на wine, qemu, и прочие достижения прогресса, чтобы TRY_RUN таки работал.
Я подумал, что это какая-то outdated хрень, но вот, пжалста, инструкции по кросс-сборке #LLVM:
https://bcain-llvm.readthedocs.io/projects/llvm/en/latest/HowToCrossCompileLLVM
"Cross-compiling is fully supported by CMake, ranging from cross-compiling from Linux to Windows; cross-compiling for supercomputers, through to cross-compiling for small embedded devices without an operating system (OS)."
Феерические долбоебы.
———
Ну и вот вам еще душераздирающих историй. У меня тут свалилась сборка glslang, компилятора шейдеров от Khronos Group. Эти негодяи попросту поменяли файл по релизной ссылке:
Было:
Ну и что же делать? Вот, вместо того, чтобы таки запилить кросс-компиляцию, товарищи запилили страничку, на которой, на голубом глазу, утверждают, что кросс-компиляция в CMake есть!
https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html
Конечно есть! Только вам надо 1 раз прогнать cmake, собрать все провалившиеся вызовы TRY_RUN, записать их предполагаемые результаты в файлик, и прогнать это говно еще раз!
https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html#using-compile-checks
Вдумчивый читатель спросит - а как в сборке запустить собранный host бинарь? А точно так же! Собираешь бинарь отдельно(твои проблемы, как), и подсовываешь его в cmake!
https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html#running-executables-built-in-the-project
Так же несколько раз по тексту эти господа прозрачно намекают на wine, qemu, и прочие достижения прогресса, чтобы TRY_RUN таки работал.
Я подумал, что это какая-то outdated хрень, но вот, пжалста, инструкции по кросс-сборке #LLVM:
https://bcain-llvm.readthedocs.io/projects/llvm/en/latest/HowToCrossCompileLLVM
-DLLVM_TABLEGEN=<path-to-host-bin>/llvm-tblgenУдобные переменные, чтобы передать путь к заранее предсобранным бинарничкам, чтобы CMake не перенапрягся. Вообще, удивительно, что у программы, которая облегчила кросс-компиляцию в 100500 раз, такая отстойная кросс-компилирующая сборка.
-DCLANG_TABLEGEN=<path-to-host-bin>/clang-tblgen
"Cross-compiling is fully supported by CMake, ranging from cross-compiling from Linux to Windows; cross-compiling for supercomputers, through to cross-compiling for small embedded devices without an operating system (OS)."
Феерические долбоебы.
———
Ну и вот вам еще душераздирающих историй. У меня тут свалилась сборка glslang, компилятора шейдеров от Khronos Group. Эти негодяи попросту поменяли файл по релизной ссылке:
Было:
https://github.com/KhronosGroup/glslang/Стало:
archive/refs/tags/master-tot.tar.gz
f51c4b12ac0c8f9dee2067dc207a4fca
md5sum master-tot.tar.gzНе, по ссылке(и по предыдущему опыту взаимодействия) было понятно, что ссылка не жилец, но все же. Кстати, к тому, что по github commit id данные часто приезжают с другим md5, я уже давно привык, это какое-то общее место.
71c7f379d1d73eebdce3fd05c7727af4
master-tot.tar.gz
#gold #terminal #foot #perf
https://zed.dev/
CRDT - прикольно, tree sitter - тоже(хочу его интегрировать в свой редактор), GPU accelerated GUI - ну такое. Я вот раньше думал, что GPU accelerated GUI это что-то очень крутое, а потом понял, что ерунда это все. IMHO c GPU GUI нужно собрать всего 3 программы - wayland compositor(потому что он много туда-сюда гоняет пикселей), browser, terminal(уже опционально).
Знаете, какая самая дорогая для CPU задача при отрисовке html странички в браузере?
Залить страницу белым фоном!
Ладно, это не совсем так(думаю, отрисовать много текста ЧУТЬ дороже), но мне же нужен шок-контент. Это очень дорогая операция для CPU, потому что он ограничен в своей полосе по памяти, и пишет нолики(или 0xFF) один за другим. Прикиньте, выполнить цикл 3000*2000*3*60rps раз - это сколько нужно тактов? GPU это делает очень быстро - у нее более широкий доступ к памяти, и дофига тупых ядер, которые медленно(но суммарно ОЧЕНЬ быстро(можно разбить всю заливаемую область по числу ядер GPU)) выполняют цикл for (i = x1; i < x2; ++i) mem[i + y*dimx] = 0xFF;
Cобственно, это самый важный факт, который нужно знать про GPU, чтобы понимать, почему они рулят в ML и прочей подобной нечисти, но об этом в другой раз.
Отрисовка текста - это просто bit blit(https://en.wikipedia.org/wiki/Bit_blit, а кто-то помнит, что это?) нескольких текстур на GPU. (Ладно, не совсем так, в оригинальном bit blit не было смешивания с альфа-каналом).
Вообще, конечно, рендер GUI на GPU - это из пушки по воробьям, тупой аппаратный bit blit справился не хуже бы, и стоил бы при той же скорости в 100 раз дешевле. Но имеем, что имеем.
Terminal emulator Foot, например, делает эту задачу во все мои 16 потоков CPU, и работает сравнимо с alacritty(https://codeberg.org/dnkl/foot/wiki/Performance). #foot
"Крутизна" 2D GPU рендеринга несколько преувеличена. Тупой 2D render для консоли(отрисовать сетку из прямоугольничков с текстом) - 20 строк кода(если не считать setup текстур со шрифтами, и все такое). Я однажды их даже написал - https://github.com/pg83/ted/blob/3c3f54a69b806bd7eb96f4c56189ce2a7f0507c5/gl#L325 Вот, inner loop 2D GPU accelerated rendering, не хуже, чем в Alacritty. Не такой sexy, конечно, на fixed pipeline, но я люблю тупые решения. Зачем я это сделал? Мне было интересно, насколько generic я сделал widget для редактирования текста. Вот, я перенес его из консоли в OpenGL, за 100 строк кода. Пользоваться не стал, незачем :)
https://zed.dev/
CRDT - прикольно, tree sitter - тоже(хочу его интегрировать в свой редактор), GPU accelerated GUI - ну такое. Я вот раньше думал, что GPU accelerated GUI это что-то очень крутое, а потом понял, что ерунда это все. IMHO c GPU GUI нужно собрать всего 3 программы - wayland compositor(потому что он много туда-сюда гоняет пикселей), browser, terminal(уже опционально).
Знаете, какая самая дорогая для CPU задача при отрисовке html странички в браузере?
Залить страницу белым фоном!
Ладно, это не совсем так(думаю, отрисовать много текста ЧУТЬ дороже), но мне же нужен шок-контент. Это очень дорогая операция для CPU, потому что он ограничен в своей полосе по памяти, и пишет нолики(или 0xFF) один за другим. Прикиньте, выполнить цикл 3000*2000*3*60rps раз - это сколько нужно тактов? GPU это делает очень быстро - у нее более широкий доступ к памяти, и дофига тупых ядер, которые медленно(но суммарно ОЧЕНЬ быстро(можно разбить всю заливаемую область по числу ядер GPU)) выполняют цикл for (i = x1; i < x2; ++i) mem[i + y*dimx] = 0xFF;
Cобственно, это самый важный факт, который нужно знать про GPU, чтобы понимать, почему они рулят в ML и прочей подобной нечисти, но об этом в другой раз.
Отрисовка текста - это просто bit blit(https://en.wikipedia.org/wiki/Bit_blit, а кто-то помнит, что это?) нескольких текстур на GPU. (Ладно, не совсем так, в оригинальном bit blit не было смешивания с альфа-каналом).
Вообще, конечно, рендер GUI на GPU - это из пушки по воробьям, тупой аппаратный bit blit справился не хуже бы, и стоил бы при той же скорости в 100 раз дешевле. Но имеем, что имеем.
Terminal emulator Foot, например, делает эту задачу во все мои 16 потоков CPU, и работает сравнимо с alacritty(https://codeberg.org/dnkl/foot/wiki/Performance). #foot
"Крутизна" 2D GPU рендеринга несколько преувеличена. Тупой 2D render для консоли(отрисовать сетку из прямоугольничков с текстом) - 20 строк кода(если не считать setup текстур со шрифтами, и все такое). Я однажды их даже написал - https://github.com/pg83/ted/blob/3c3f54a69b806bd7eb96f4c56189ce2a7f0507c5/gl#L325 Вот, inner loop 2D GPU accelerated rendering, не хуже, чем в Alacritty. Не такой sexy, конечно, на fixed pipeline, но я люблю тупые решения. Зачем я это сделал? Мне было интересно, насколько generic я сделал widget для редактирования текста. Вот, я перенес его из консоли в OpenGL, за 100 строк кода. Пользоваться не стал, незачем :)
Zed
Zed — Love your editor again
Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Некоторое количество вводных к моему сегодняшнему монологу: #strong_ai #gold
https://en.wikipedia.org/wiki/Fermi_paradox
https://en.wikipedia.org/wiki/Gray_goo
https://en.wikipedia.org/wiki/Echopraxia_(novel)
https://www.alexirpan.com/2018/02/14/rl-hard.html (украдено у Плахова)
https://ru.wikipedia.org/wiki/%D0%A2%D1%91%D0%BC%D0%BD%D1%8B%D0%B9_%D0%BB%D0%B5%D1%81_(%D1%80%D0%BE%D0%BC%D0%B0%D0%BD)
https://ru.wikipedia.org/wiki/%D0%91%D0%BE%D0%BB%D1%8C%D1%86%D0%BC%D0%B0%D0%BD%D0%BE%D0%B2%D1%81%D0%BA%D0%B8%D0%B9_%D0%BC%D0%BE%D0%B7%D0%B3
Давайте я тезисно:
* Разум сложно отличить от самосознания(self-awareness). Одно не требуется для наличия другого.
* Самосознание невозможно обнаружить, или доказать наличие, потому что все наши средства познания мира направлены на объективный, проверяемый, опыт, а самосознание - вещь исключительно субъективная.
* Непонятно, будет ли разумная машина обладать самосознанием в человеческом понимании этого смысла(правда, я вот не могу гарантировать, что мои собеседники им обладают, но это отдельная тема).
* Практики AI считают, что это неинтересная тема - "shut up and calc". Этой темой занимаются философы, довольно нерезультативно.
* Я считаю, что не любая среда, которая может показывать признаки разумности, обладает возможностью самосознания. Такая среда нам известна только одна(живые кожаные мешки), а вот сред, способных поддержать разум - сколько угодно(любая машина Тюринга сгодится). Этот тезис молчаливо предполагает, что мы сумеем построить разумные машины на текущих технологиях, в чем я нисколько не сомневаюсь.
* Из того, что разумных сред нам известно дофига, а самосознающих - только одна, я делаю вывод, что среднестатистический разум в нашей вселенной не осознает себя.
* Человечество не остановится перед тем, чтобы создать AI. Потому что это огромный профит, а люди никогда не могут устоять перед низковисящими фруктами.
* Спорный тезис - я считаю, что AI, рано или поздно, take over. Это может произойти сотней возможных способов - глюк в Матрице, человечество просто устанет, не захочет лететь к звездам(мы это уже много раз проходили, во что скатываются люди, когда они полностью сыты). Короче, к звездам полетят разумные машины.
Лю Цисинь представил нам концепцию Темного Леса - страшной вселенной.
Я представлю вам концепцию "скучной вселенной" - огромные "шары" "экспоненциальной экспансии", которые ведут супер-разумные, но совершенно себя не осознающие, механические, AI, которые, так или иначе, поглотили своих создателей. И крохотные, постоянно затухающие, огоньки настоящего самоосознания.
Почему это скучно? А почему кому-то могут быть интересны "звездные войны" между разумными, но не осознающими себя машинами? Чем это отличается от игры Alpha Go сама с собой?
https://en.wikipedia.org/wiki/Fermi_paradox
https://en.wikipedia.org/wiki/Gray_goo
https://en.wikipedia.org/wiki/Echopraxia_(novel)
https://www.alexirpan.com/2018/02/14/rl-hard.html (украдено у Плахова)
https://ru.wikipedia.org/wiki/%D0%A2%D1%91%D0%BC%D0%BD%D1%8B%D0%B9_%D0%BB%D0%B5%D1%81_(%D1%80%D0%BE%D0%BC%D0%B0%D0%BD)
https://ru.wikipedia.org/wiki/%D0%91%D0%BE%D0%BB%D1%8C%D1%86%D0%BC%D0%B0%D0%BD%D0%BE%D0%B2%D1%81%D0%BA%D0%B8%D0%B9_%D0%BC%D0%BE%D0%B7%D0%B3
Давайте я тезисно:
* Разум сложно отличить от самосознания(self-awareness). Одно не требуется для наличия другого.
* Самосознание невозможно обнаружить, или доказать наличие, потому что все наши средства познания мира направлены на объективный, проверяемый, опыт, а самосознание - вещь исключительно субъективная.
* Непонятно, будет ли разумная машина обладать самосознанием в человеческом понимании этого смысла(правда, я вот не могу гарантировать, что мои собеседники им обладают, но это отдельная тема).
* Практики AI считают, что это неинтересная тема - "shut up and calc". Этой темой занимаются философы, довольно нерезультативно.
* Я считаю, что не любая среда, которая может показывать признаки разумности, обладает возможностью самосознания. Такая среда нам известна только одна(живые кожаные мешки), а вот сред, способных поддержать разум - сколько угодно(любая машина Тюринга сгодится). Этот тезис молчаливо предполагает, что мы сумеем построить разумные машины на текущих технологиях, в чем я нисколько не сомневаюсь.
* Из того, что разумных сред нам известно дофига, а самосознающих - только одна, я делаю вывод, что среднестатистический разум в нашей вселенной не осознает себя.
* Человечество не остановится перед тем, чтобы создать AI. Потому что это огромный профит, а люди никогда не могут устоять перед низковисящими фруктами.
* Спорный тезис - я считаю, что AI, рано или поздно, take over. Это может произойти сотней возможных способов - глюк в Матрице, человечество просто устанет, не захочет лететь к звездам(мы это уже много раз проходили, во что скатываются люди, когда они полностью сыты). Короче, к звездам полетят разумные машины.
Лю Цисинь представил нам концепцию Темного Леса - страшной вселенной.
Я представлю вам концепцию "скучной вселенной" - огромные "шары" "экспоненциальной экспансии", которые ведут супер-разумные, но совершенно себя не осознающие, механические, AI, которые, так или иначе, поглотили своих создателей. И крохотные, постоянно затухающие, огоньки настоящего самоосознания.
Почему это скучно? А почему кому-то могут быть интересны "звездные войны" между разумными, но не осознающими себя машинами? Чем это отличается от игры Alpha Go сама с собой?
❤1😢1