Меня сегодня тянет на философию, а, значит, и вас тоже.
Перед прочтением текста желательно ознакомиться с https://www.scottaaronson.com/writings/bignumbers.html
Можно взглянуть на https://www.quora.com/What-is-the-largest-number-that-can-reasonably-be-written-by-hand #bb
Какое самое большое число можно записать на салфетке?
Физик бы сказал что-то типа "100^500", с большим количеством нулей, и был бы сильно не прав.
Число "максимальное число, которое может вывести на печать машина Тюринга длиной до 1000 символов, и остановиться" сильно, невообразимо сильно, больше.
Но это все так, прелюдия.
https://en.wikipedia.org/wiki/Hierarchy_problem
Я сегодня хочу спросить несколько вопросов про "проблему масштаба" в физике, потому что мне кажется, что физики ее вообще неправильно формулируют, их формулировка не позволяет ничего понять(или даже просто пофантазировать) про окружающий нас мир.
Физики спрашивают, почему физические константы имеют такой большой разброс. Это потому, что они не знают, что такое по настоящему большие числа. 100^500 - это, типа, много.
Я спрашиваю, почему физические константы и величины - это такие МАЛЕНЬКИЕ числа.
* Почему число атомов во вселенной может быть выражено степенной записью числа с небольшими показателями? Почему это, например, не число Аккермана, или число Тюринга?
* Почему все известные физические константы и отношения между ними так хорошо записываются степенной записью числа с небольшими показателями?
* Почему они вообще записываются числами, которые могут поместиться на листке салфетки?
* Почему они вообще записываются числами, которые могут прийти в голову человекообразной обезьяне?
* Ну и финальный вопрос - почему наша вселенная так хорошо описывается числами A^B, с небольшими A, B?
* Есть ли какие-то физические величины, которые так не описываются, и нужна более сильная математическая запись из статьи выше?
Перед прочтением текста желательно ознакомиться с https://www.scottaaronson.com/writings/bignumbers.html
Можно взглянуть на https://www.quora.com/What-is-the-largest-number-that-can-reasonably-be-written-by-hand #bb
Какое самое большое число можно записать на салфетке?
Физик бы сказал что-то типа "100^500", с большим количеством нулей, и был бы сильно не прав.
Число "максимальное число, которое может вывести на печать машина Тюринга длиной до 1000 символов, и остановиться" сильно, невообразимо сильно, больше.
Но это все так, прелюдия.
https://en.wikipedia.org/wiki/Hierarchy_problem
Я сегодня хочу спросить несколько вопросов про "проблему масштаба" в физике, потому что мне кажется, что физики ее вообще неправильно формулируют, их формулировка не позволяет ничего понять(или даже просто пофантазировать) про окружающий нас мир.
Физики спрашивают, почему физические константы имеют такой большой разброс. Это потому, что они не знают, что такое по настоящему большие числа. 100^500 - это, типа, много.
Я спрашиваю, почему физические константы и величины - это такие МАЛЕНЬКИЕ числа.
* Почему число атомов во вселенной может быть выражено степенной записью числа с небольшими показателями? Почему это, например, не число Аккермана, или число Тюринга?
* Почему все известные физические константы и отношения между ними так хорошо записываются степенной записью числа с небольшими показателями?
* Почему они вообще записываются числами, которые могут поместиться на листке салфетки?
* Почему они вообще записываются числами, которые могут прийти в голову человекообразной обезьяне?
* Ну и финальный вопрос - почему наша вселенная так хорошо описывается числами A^B, с небольшими A, B?
* Есть ли какие-то физические величины, которые так не описываются, и нужна более сильная математическая запись из статьи выше?
🔥13
#GNOME hate speech
gtk4 - это FAIL.
https://archlinux.org/packages/extra/x86_64/gtk4/
Почти все проекты, которые перешли на gtk4 - это либо составные части gnome, либо библиотеки, от которых эти составные части зависят.
Почему независимые вендоры не спешат переходить на gtk4?
Мой ответ заключается в том, что довольно много интеграционных библиотек написала Canonical, и они никогда не будут портированы на gtk4.
Речь идет про библиотеки libappindicator, libgtklayershell, и подобные.
Это код интеграции тулкита с desktop environment - уведомления, значки в tray, возможность разработки всякого рода панелей и лончеров.
Почему они не будут портированы на gtk4?
Потому что у GNOME свой, ни с кем не совместимый, путь, и они на херу вертели общепринятые(ну, скажем, в KDE и wlroots) способы интеграции, а gtk3, в основном, используется как gnome-independent toolkit во всяком стороннем софте. Как я уже сказал, это всякого рода панели и лончеры для sway, и так далее.
Видимо, предполагается, что софт на gtk4 должен использовать гномоинтеграции с десктопом, а это совсем не интересно авторам стороннего софта.
———
https://drewdevault.com/2022/05/25/Google-has-been-DDoSing-sourcehut.html
Кеш пакетов для Go от Google ддосит репозитории с этими пакетами.
Кровь из глаз, леденящий душу пиздец, шок, сенсация, поgoраммисты от Google не умеют в элементарный распределенный rate limiter.
Судя по ссылкам на тикеты, они не осилили общий state на разных проксях, зато умеют крутить ручки "ну давайте ходить в 2 раза реже, авось мейнтейнеры отъебутся".
"Currently, a single request for a module may cause refetch traffic for several days after. That may be what you are experiencing. One idea we've been discussing is to make it such that our job only make refresh requests if the module is deemed "popular" enough (e.g. the module has been requested 100 times in the last week). However, this is going to require some re-architecting, and database changes, so it is taking some time to work through."
Зато забанили ДеВолта в своем трекере, да.
У меня, в целом, нет сомнений про общую квалификацию программистов на go, но Google мог бы и получше.
———
https://www.positech.co.uk/cliffsblog/2022/06/05/code-bloat-has-become-astronomical/
rant от старого погромиста про современный софт, и про code bloat.
Не могу не согласиться.
Вообще, я раньше считал, что код нельзя писать во второй раз, и надо переиспользовать по максимуму.
Постепенно я мигрурую к мысли, что какой-то код неплохо бы иногда начинать снова и снова. Знаете, как в отжиге, чтобы выбираться из локального оптимума.
Базы данных все еще недостаточно хороши, и, КМК, им полезно регулярное перепридумывание.
Опять же, до работ Лемира я думал, что парсер float и парсер json - решенные задачи, но нет, даже там есть, что добавить.
Другое дело, если вы переписываете код без внесения в результат чего-то нового - нет, так не надо делать. Еще один такой же base64 никому не нужен.
gtk4 - это FAIL.
https://archlinux.org/packages/extra/x86_64/gtk4/
Почти все проекты, которые перешли на gtk4 - это либо составные части gnome, либо библиотеки, от которых эти составные части зависят.
Почему независимые вендоры не спешат переходить на gtk4?
Мой ответ заключается в том, что довольно много интеграционных библиотек написала Canonical, и они никогда не будут портированы на gtk4.
Речь идет про библиотеки libappindicator, libgtklayershell, и подобные.
Это код интеграции тулкита с desktop environment - уведомления, значки в tray, возможность разработки всякого рода панелей и лончеров.
Почему они не будут портированы на gtk4?
Потому что у GNOME свой, ни с кем не совместимый, путь, и они на херу вертели общепринятые(ну, скажем, в KDE и wlroots) способы интеграции, а gtk3, в основном, используется как gnome-independent toolkit во всяком стороннем софте. Как я уже сказал, это всякого рода панели и лончеры для sway, и так далее.
Видимо, предполагается, что софт на gtk4 должен использовать гномоинтеграции с десктопом, а это совсем не интересно авторам стороннего софта.
———
https://drewdevault.com/2022/05/25/Google-has-been-DDoSing-sourcehut.html
Кеш пакетов для Go от Google ддосит репозитории с этими пакетами.
Кровь из глаз, леденящий душу пиздец, шок, сенсация, поgoраммисты от Google не умеют в элементарный распределенный rate limiter.
Судя по ссылкам на тикеты, они не осилили общий state на разных проксях, зато умеют крутить ручки "ну давайте ходить в 2 раза реже, авось мейнтейнеры отъебутся".
"Currently, a single request for a module may cause refetch traffic for several days after. That may be what you are experiencing. One idea we've been discussing is to make it such that our job only make refresh requests if the module is deemed "popular" enough (e.g. the module has been requested 100 times in the last week). However, this is going to require some re-architecting, and database changes, so it is taking some time to work through."
Зато забанили ДеВолта в своем трекере, да.
У меня, в целом, нет сомнений про общую квалификацию программистов на go, но Google мог бы и получше.
———
https://www.positech.co.uk/cliffsblog/2022/06/05/code-bloat-has-become-astronomical/
rant от старого погромиста про современный софт, и про code bloat.
Не могу не согласиться.
Вообще, я раньше считал, что код нельзя писать во второй раз, и надо переиспользовать по максимуму.
Постепенно я мигрурую к мысли, что какой-то код неплохо бы иногда начинать снова и снова. Знаете, как в отжиге, чтобы выбираться из локального оптимума.
Базы данных все еще недостаточно хороши, и, КМК, им полезно регулярное перепридумывание.
Опять же, до работ Лемира я думал, что парсер float и парсер json - решенные задачи, но нет, даже там есть, что добавить.
Другое дело, если вы переписываете код без внесения в результат чего-то нового - нет, так не надо делать. Еще один такой же base64 никому не нужен.
👍13🔥2
Подхватываем флешмоб.
Меня регулярно спрашивают, почему мои посты про #GNOME такие резкие.
Отвечаю - я их ненавижу!
Они плохие люди, и другие плохие люди.
Они хотят смерти Wayland, и хотят заменить его на dbus! Dbus, Карл!
И, пока я жив, я буду делать все, что в моих силах, чтобы не допустить этого!
Меня регулярно спрашивают, почему мои посты про #GNOME такие резкие.
Отвечаю - я их ненавижу!
Они плохие люди, и другие плохие люди.
Они хотят смерти Wayland, и хотят заменить его на dbus! Dbus, Карл!
И, пока я жив, я буду делать все, что в моих силах, чтобы не допустить этого!
😁46🔥3👍1
Я периодически занимаюсь yak stalix shaving, если вы понимаете, о чем я.
Меня, например, довольно сильно интересует, кто из программ жрет батарейку, и, особенно, кто жрет ее не по делу.
Делаю я это довольно просто, через какое-то время после запуска ноутбука запускаю htop, и смотрю, кто из постоянно висящих процессов сожрал больше всего батарейки.
Мой топ:
epiphany - 20 попугаев
sway - 16 попугаев
ananicy-cpp - 6 попугаев
telegram-desktop - 6 попугаев
Если с первыми двумя все понятно, epiphany - тормозное говно, sway периодически делает много memcpy, то к двум оставшимся есть вопросы.
Я начал с телеги, потому что какого хрена? ananicy писал какой-то пионер, а вот телега, когда ей не пользуются, не должна делать ни-фи-га.
Но нет, strace показал, что телега просыпается 125 раз в секунду, не делает нихрена, и снова засыпает.
(кстати, судя по интеренетам, людям довольно часто рекомендуют это делать, для борьбы с багами. Так-то понятно, что встраиваться в чужеродный и неконтролируемый event loop - так себе идея)
(небольшая ремарка - event loop в glib - 200KB всратейшего кода на C, в QT - 15KB хорошо документированного и простого кода на С++. Это я опять к тому, что на С нельзя писать никакие серьезные объемы кода, ни gui библиотеку, ни ядро Linux, да)
Короче, это тоже не помогло, через какое-то время телега снова начинает сыпать в strace 125 раз в секунду какой-то хней.
Я так полагаю, что это какой-то непонятный таймер, и разработчики просто промахнулись, должно было быть 8 секунд.
Потому что что может телега хотеть делать 125 раз в секунду?
Багрепорт еще не завел, не успел.
Меня, например, довольно сильно интересует, кто из программ жрет батарейку, и, особенно, кто жрет ее не по делу.
Делаю я это довольно просто, через какое-то время после запуска ноутбука запускаю htop, и смотрю, кто из постоянно висящих процессов сожрал больше всего батарейки.
Мой топ:
epiphany - 20 попугаев
sway - 16 попугаев
ananicy-cpp - 6 попугаев
telegram-desktop - 6 попугаев
Если с первыми двумя все понятно, epiphany - тормозное говно, sway периодически делает много memcpy, то к двум оставшимся есть вопросы.
Я начал с телеги, потому что какого хрена? ananicy писал какой-то пионер, а вот телега, когда ей не пользуются, не должна делать ни-фи-га.
Но нет, strace показал, что телега просыпается 125 раз в секунду, не делает нихрена, и снова засыпает.
[pid 28550] poll([{fd=5, events=POLLIN},
{fd=16, events=POLLIN}], 2, 8) = 0
(Timeout)
[pid 28550] poll([{fd=5, events=POLLIN},
{fd=16, events=POLLIN}], 2, 8) = 0
(Timeout)
[pid 28550] poll([{fd=5, events=POLLIN},
{fd=16, events=POLLIN}], 2, 8) = 0
(Timeout)
[pid 28550] poll([{fd=5, events=POLLIN},
{fd=16, events=POLLIN}], 2, 8) = 0
(Timeout)
[pid 28550] poll([{fd=5, events=POLLIN},
{fd=16, events=POLLIN}], 2, 8) = 0
(Timeout)
Я докопался, что это происходит в glib/dbus event loop, и хотел уже было списать все на гноморазработчиков, но увидел по исходникам qt, https://github.com/qt/qtbase/blob/dev/src/gui/platform/unix/qgenericunixeventdispatcher.cpp , что это несложно переключить на встроенный в qt event loop.(кстати, судя по интеренетам, людям довольно часто рекомендуют это делать, для борьбы с багами. Так-то понятно, что встраиваться в чужеродный и неконтролируемый event loop - так себе идея)
(небольшая ремарка - event loop в glib - 200KB всратейшего кода на C, в QT - 15KB хорошо документированного и простого кода на С++. Это я опять к тому, что на С нельзя писать никакие серьезные объемы кода, ни gui библиотеку, ни ядро Linux, да)
Короче, это тоже не помогло, через какое-то время телега снова начинает сыпать в strace 125 раз в секунду какой-то хней.
Я так полагаю, что это какой-то непонятный таймер, и разработчики просто промахнулись, должно было быть 8 секунд.
Потому что что может телега хотеть делать 125 раз в секунду?
Багрепорт еще не завел, не успел.
GitHub
qtbase/src/gui/platform/unix/qgenericunixeventdispatcher.cpp at dev · qt/qtbase
Qt Base (Core, Gui, Widgets, Network, ...). Contribute to qt/qtbase development by creating an account on GitHub.
👍20
https://www.opennet.ru/opennews/art.shtml?num=57320
Pyston-модуль, для ускорения обычного CPython кода. Новость довольно интересная сама по себе, можно поспекулировать про эти оптимизации, и про грядущий 3.11, который я, например, на своих приборах не вижу, зато команда рапортует про двузначный профит.
Но я хочу поговорить про другой аспект этой шняги. А именно, про то, что компиляцию в native code нужно делать в отдельном демоне, а не в разделяемой библиотеке.
#fontconfig #daemon_vs_dylib
В современных операционных системах слишком многое делается через загрузку разделяемого кода в пространоство процесса, нежели через отдельные демоны.
Just to name a few:
* fontconfig - резолвинг имен шрифтов в пути. Сейчастам дичь в библиотеке, которая раз в 20 секунд перечитывает fc cache.
* Рендеринг глифов в freetype
* Рендеринг svg. Зачем тащить в каждое приложение inferior librsvg, когда можно рендерить все через классный inkscape?
* mesa, shaders - компилятор на основе llvm для шейдеров
* теперь вот компилятор для python bytecode
* clangd - тут хорошо, тут люди подумали головой
* nss модули в libc- тут, уже, вроде, есть консенсус, что не надо так.
Лично я считаю, что это жесть, и что OS-е строение идет не туда.
Посудите сами. Чем меньше возможных состояний у программы, тем лучше:
* Потому что проще тестировать. Для тестирования 2 программ с M, N состояниями нужно порядка N + M тестов, для совокупной программы нужно еще + N*M*alpha тестов. Потому что в совокупной программе все равно будет пошаренный state, типа аллокатора.
* Потому что баги имеют ограниченный scope. Представьте себе проезд по памяти в однопоточной программе, которая конвертирует python bytecode -> native code с помощью llvm. В случае демона, вы можете этого даже не заметить, если проезд произошел "куда надо", или демон просто рестартанет, и вы тоже это не заметите. В случае загрузки .so падает все приложение. А я вам скажу, что тащить в long living program компилятор из llvm - это для очень отчаянных людей. Оно обычно живет в short living процессах компиляции, и даже авторы clangd/xcode понимают это, и изолируют код clang/llvm в отдельных процессах.
* Проще кешировать результат работы того или иного блока кода. Посмотрите, например, как устроено кеширование байткода в pyston, или кеширование шейдеров в mesa. В случае отдельных демонов, которые занимаются компиляцией шейдеров или байткода, можно взгромоздить общесистемный memcached, и просто забыть про эту задачу. Можно не пересобирать svg иконки от запуска к запуску приложения! Да много чего станет проще и лучше.
* Более просто подменить реализацию. Это прямо не очень очевидно, но заменить демон с хорошо определенным интерфейсом существенно проще, чем подменить .so, с кучей торчащих отовсюду запчастей. Ну, типа, не понравилось, как pystond компилирует python bytecode, заменил на что-то более мощное.
* Треды в .so и/или программе, fork() в .so и/или программе.
В случае Linux и прочего OSS, это классическая проблема общин, и что тут можно сделать - совершенно непонятно, в каждый момент времени проще накостылять еще одну .so, чем договориться про устраивающий всех способ запустить session daemon.
В случае macOS, кстати, есть все шансы, что Apple пойдет правильным путем.
Pyston-модуль, для ускорения обычного CPython кода. Новость довольно интересная сама по себе, можно поспекулировать про эти оптимизации, и про грядущий 3.11, который я, например, на своих приборах не вижу, зато команда рапортует про двузначный профит.
Но я хочу поговорить про другой аспект этой шняги. А именно, про то, что компиляцию в native code нужно делать в отдельном демоне, а не в разделяемой библиотеке.
#fontconfig #daemon_vs_dylib
В современных операционных системах слишком многое делается через загрузку разделяемого кода в пространоство процесса, нежели через отдельные демоны.
Just to name a few:
* fontconfig - резолвинг имен шрифтов в пути. Сейчастам дичь в библиотеке, которая раз в 20 секунд перечитывает fc cache.
* Рендеринг глифов в freetype
* Рендеринг svg. Зачем тащить в каждое приложение inferior librsvg, когда можно рендерить все через классный inkscape?
* mesa, shaders - компилятор на основе llvm для шейдеров
* теперь вот компилятор для python bytecode
* clangd - тут хорошо, тут люди подумали головой
* nss модули в libc- тут, уже, вроде, есть консенсус, что не надо так.
Лично я считаю, что это жесть, и что OS-е строение идет не туда.
Посудите сами. Чем меньше возможных состояний у программы, тем лучше:
* Потому что проще тестировать. Для тестирования 2 программ с M, N состояниями нужно порядка N + M тестов, для совокупной программы нужно еще + N*M*alpha тестов. Потому что в совокупной программе все равно будет пошаренный state, типа аллокатора.
* Потому что баги имеют ограниченный scope. Представьте себе проезд по памяти в однопоточной программе, которая конвертирует python bytecode -> native code с помощью llvm. В случае демона, вы можете этого даже не заметить, если проезд произошел "куда надо", или демон просто рестартанет, и вы тоже это не заметите. В случае загрузки .so падает все приложение. А я вам скажу, что тащить в long living program компилятор из llvm - это для очень отчаянных людей. Оно обычно живет в short living процессах компиляции, и даже авторы clangd/xcode понимают это, и изолируют код clang/llvm в отдельных процессах.
* Проще кешировать результат работы того или иного блока кода. Посмотрите, например, как устроено кеширование байткода в pyston, или кеширование шейдеров в mesa. В случае отдельных демонов, которые занимаются компиляцией шейдеров или байткода, можно взгромоздить общесистемный memcached, и просто забыть про эту задачу. Можно не пересобирать svg иконки от запуска к запуску приложения! Да много чего станет проще и лучше.
* Более просто подменить реализацию. Это прямо не очень очевидно, но заменить демон с хорошо определенным интерфейсом существенно проще, чем подменить .so, с кучей торчащих отовсюду запчастей. Ну, типа, не понравилось, как pystond компилирует python bytecode, заменил на что-то более мощное.
* Треды в .so и/или программе, fork() в .so и/или программе.
В случае Linux и прочего OSS, это классическая проблема общин, и что тут можно сделать - совершенно непонятно, в каждый момент времени проще накостылять еще одну .so, чем договориться про устраивающий всех способ запустить session daemon.
В случае macOS, кстати, есть все шансы, что Apple пойдет правильным путем.
www.opennet.ru
Представлен Pyston-lite, JIT-компилятор для штатного Python
Разработчики проекта Pyston, предлагающего высокопроизводительную реализацию языка Python, использующую современные технологии JIT-компиляции, представили расширение Pyston-lite с реализацией JIT-компилятора для CPython. Если Pyston является ответвлением…
👍10🔥2
Меня тут в комментариях спрашивали, что я собираюсь делать с вопроизведением звука через bluetooth, потому что в Linux оно нормально работает только через PipeWire. #cras #sndio
Я на это ответил, что у меня есть 2 варианта:
1) alsa умеет предоставлять bluetooth out, как свое устройство. Этот способ я оставил на самый крайний случай, потому что разработчики alsa упыри, и я не хочу связываться с их способом микшировать звук.
2) Есть такая вундервафля - ChromiumOS. И в ней есть звуковой демон, про который никто ничего не знает, но он умеет в bluetooth.
Сегодня мой рассказ про CRAS - Chromium Audio Server. https://www.chromium.org/chromium-os/chromiumos-design-docs/cras-chromeos-audio-server/ . Ну, точнее, про мое хождение по мукам с ним.
Лежит он вот тут - https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras
Про этот софт, действительно, никто за пределами ChromeOS никто ничего не знает. Информации 0, даже в Arch нет пакета с ним, я тут первопроходец.
Вот его процедура сборки(точнее, подготовка зависимостей) - https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/install_deps.sh
Видно, что коллеги особо не заморачивались, методичностью гугла тут и не пахнет.
* Сборка завязана на glibc, пришлось добавить отсутствующий файл в musl - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/gnushim/ieee754.h
* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/cras/ix.sh#L59 - коллеги упустили какой-то missing include.
* без плагинов, монолитный бинарь, google кремень.
* Все бы ничего, но, как выяснилось, в 19 году Гугл препринял попытку переписать часть этого кода на Rust.
Тут я взвыл, потому что компилятор Rust у меня все еще не готов.
Но, пораскинув мозгами, и почитав код - https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/src/server/rust/, я понял, что они переписали 1(один) файл, и на этом остановились.
Я человек вредный, я полагаю, что там кто-то получил премию за внедрение безопасного языка, а потом на это забили, потому что нафиг никому не нужно.
Так за 3 года в репе и остался 1 файл на rust(по существу, еще там ворох кодогенерации, чтобы обернуть сишные типы).
Я решил, что ну его в жопу, нашел место, в котором был осуществлен акт вандализма, и просто взял имплементаци оттуда.
Кстати, давайте их сравним:
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/src/server/rust/src/rate_estimator.rs
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/454c81a0669c2c5ffc7132d870b7421291b6630e/cras/src/server/rate_estimator.c
Выделений памяти там нет, просто фигачим в буфер фиксированного размера семплы, а потом считаем регрессию.
Выводы, конечно, каждый может сделать сам для себя, но так-то rust оказался несколько многословнее, совершенно на пустом месте.
Собственно, остатки сборочного файла - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/cras/ix.sh#L64 - это выковыривание зависимости от rust, и добавление старого кода в сборку.
Кстати, хочу на этом примере показать разницу в подходах конвенциональных дистрибутивов, и моего.
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/cras/ix.sh#L70
Есть ощущение, что коллеги пытаются оформить diff так, чтобы результат был пригоден для редактирования человеком. В данном случае они, честь по чести, отредактировали бы Makefile, добавили туда новый файл, и так далее.
Я же руководствуюсь эффективностью. Мне надо собрать определенный код - я его добавлю в заведомо собираемый файл, одной строчкой. Да, это нечитаемая мешанина на выходе, но зато я решил задачу за 5 секунд, и оно не сломается при обновлении Makefile.
КМК, это очень важно.
Короче, cras я собрал, но пока не могу похвастаться тем, что он у меня заработал.
Кажется, Google не очень заинтересован тем, чтобы этот код использовали где-то вне ChromeOS - доков нет, примера конфига нет, —help не работает!
Пока запускаю strace, читаю код.
Возможно, это гнилое дело, но, на самом деле, очень интересно само по себе!
Я на это ответил, что у меня есть 2 варианта:
1) alsa умеет предоставлять bluetooth out, как свое устройство. Этот способ я оставил на самый крайний случай, потому что разработчики alsa упыри, и я не хочу связываться с их способом микшировать звук.
2) Есть такая вундервафля - ChromiumOS. И в ней есть звуковой демон, про который никто ничего не знает, но он умеет в bluetooth.
Сегодня мой рассказ про CRAS - Chromium Audio Server. https://www.chromium.org/chromium-os/chromiumos-design-docs/cras-chromeos-audio-server/ . Ну, точнее, про мое хождение по мукам с ним.
Лежит он вот тут - https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras
Про этот софт, действительно, никто за пределами ChromeOS никто ничего не знает. Информации 0, даже в Arch нет пакета с ним, я тут первопроходец.
Вот его процедура сборки(точнее, подготовка зависимостей) - https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/install_deps.sh
Видно, что коллеги особо не заморачивались, методичностью гугла тут и не пахнет.
* Сборка завязана на glibc, пришлось добавить отсутствующий файл в musl - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/gnushim/ieee754.h
* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/cras/ix.sh#L59 - коллеги упустили какой-то missing include.
* без плагинов, монолитный бинарь, google кремень.
* Все бы ничего, но, как выяснилось, в 19 году Гугл препринял попытку переписать часть этого кода на Rust.
Тут я взвыл, потому что компилятор Rust у меня все еще не готов.
Но, пораскинув мозгами, и почитав код - https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/src/server/rust/, я понял, что они переписали 1(один) файл, и на этом остановились.
Я человек вредный, я полагаю, что там кто-то получил премию за внедрение безопасного языка, а потом на это забили, потому что нафиг никому не нужно.
Так за 3 года в репе и остался 1 файл на rust(по существу, еще там ворох кодогенерации, чтобы обернуть сишные типы).
Я решил, что ну его в жопу, нашел место, в котором был осуществлен акт вандализма, и просто взял имплементаци оттуда.
Кстати, давайте их сравним:
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/src/server/rust/src/rate_estimator.rs
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/454c81a0669c2c5ffc7132d870b7421291b6630e/cras/src/server/rate_estimator.c
Выделений памяти там нет, просто фигачим в буфер фиксированного размера семплы, а потом считаем регрессию.
Выводы, конечно, каждый может сделать сам для себя, но так-то rust оказался несколько многословнее, совершенно на пустом месте.
Собственно, остатки сборочного файла - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/cras/ix.sh#L64 - это выковыривание зависимости от rust, и добавление старого кода в сборку.
Кстати, хочу на этом примере показать разницу в подходах конвенциональных дистрибутивов, и моего.
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/cras/ix.sh#L70
Есть ощущение, что коллеги пытаются оформить diff так, чтобы результат был пригоден для редактирования человеком. В данном случае они, честь по чести, отредактировали бы Makefile, добавили туда новый файл, и так далее.
Я же руководствуюсь эффективностью. Мне надо собрать определенный код - я его добавлю в заведомо собираемый файл, одной строчкой. Да, это нечитаемая мешанина на выходе, но зато я решил задачу за 5 секунд, и оно не сломается при обновлении Makefile.
КМК, это очень важно.
Короче, cras я собрал, но пока не могу похвастаться тем, что он у меня заработал.
Кажется, Google не очень заинтересован тем, чтобы этот код использовали где-то вне ChromeOS - доков нет, примера конфига нет, —help не работает!
Пока запускаю strace, читаю код.
Возможно, это гнилое дело, но, на самом деле, очень интересно само по себе!
🔥13👍1
https://blogs.blackberry.com/en/2022/06/symbiote-a-new-nearly-impossible-to-detect-linux-threat
Простите, но не могу терпеть до завтра :D
"Symbiote: A New, Nearly-Impossible-to-Detect Linux Threat"
"What makes Symbiote different from other Linux malware that we usually come across, is that it needs to infect other running processes to inflict damage on infected machines. Instead of being a standalone executable file that is run to infect a machine, it is a shared object (SO) library that is loaded into all running processes using LD_PRELOAD (T1574.006), and parasitically infects the machine. Once it has infected all the running processes, it provides the threat actor with rootkit functionality, the ability to harvest credentials, and remote access capability."
.so, LD_PRELOAD, я так понимаю, у меня оно даже не запустится.
Простите, но не могу терпеть до завтра :D
"Symbiote: A New, Nearly-Impossible-to-Detect Linux Threat"
"What makes Symbiote different from other Linux malware that we usually come across, is that it needs to infect other running processes to inflict damage on infected machines. Instead of being a standalone executable file that is run to infect a machine, it is a shared object (SO) library that is loaded into all running processes using LD_PRELOAD (T1574.006), and parasitically infects the machine. Once it has infected all the running processes, it provides the threat actor with rootkit functionality, the ability to harvest credentials, and remote access capability."
.so, LD_PRELOAD, я так понимаю, у меня оно даже не запустится.
BlackBerry
Symbiote: A New, Nearly-Impossible-to-Detect Linux Threat
There's a new, nearly-impossible-to-detect Linux threat that may be hiding in your running processes. Learn more about "Symbiote," discovered via new joint research by Intezer and BlackBerry.
😁11👍4🔥2❤1
https://semianalysis.substack.com/p/apple-m2-die-shot-and-architecture?s=r
M2, конечно, разочарование.
За два года Apple выкатили +20% перфа, что, кажется, сравнимо со скоростью роста конкурентов.
Ну и я совершенно не могу понять этого жлобства - 1 CPU ядро занимает порядка квадратного миллиметра, почему бы не напихать их 20 штук?
Ладно, на самом деле, могу, 20 штук напихают в Mac Pro, и продадут за кучу денег.
M2, конечно, разочарование.
За два года Apple выкатили +20% перфа, что, кажется, сравнимо со скоростью роста конкурентов.
Ну и я совершенно не могу понять этого жлобства - 1 CPU ядро занимает порядка квадратного миллиметра, почему бы не напихать их 20 штук?
Ладно, на самом деле, могу, 20 штук напихают в Mac Pro, и продадут за кучу денег.
SemiAnalysis
Apple M2 Die Shot and Architecture Analysis – Big Cost Increase And A15 Based IP
Apple announced their new 20 billion transistor M2 SoC at WWDC. Unfortunately, it’s quite a minor uplift in performance in some areas such as CPU. Apple’s gains mostly came from the GPU and video editing side of things.
😁7
https://lwn.net/Articles/897198/, paywall, но, все равно, тема интересная, не могу не затронуть. #vendor
TL;DR - fedora офигели от сложности де-вендоринга Java, и решили поставлять ее as is, с теми либами, которые вендорит Oracle.
https://lwn.net/ml/fedora-devel/CA+voJeUVXW2XYHKaJ8S2N3KgvSMVUx6TsKFOvDDnjctsdO70jA@mail.gmail.com/ - переписка про это.
Я, с одной стороны, считаю, что это правильный путь, с другой - максимализм Федоры меня поражает, они хотят оставить завендоренными и freetype, и harfbuzz. А это значит, что гуевые Java приложения будут выглядеть ЕЩЕ более вырвиглазно.
С другой стороны, понятно, почему таки вендорить эти библиотеки им нужно - они хотят поставлять один tgz файл для всех версий федоры и rhel, с целью упрощения прохождения java conformance test. Тест нельзя не проходить, если ты хочешь называть финальный продукт Java.
Что еще интересного:
* вендоры периодически патчат уязвимости быстрее, чем это делают дистрибутивы. Это, практически, шах и мат для аргументов в стиле "завендоренные либы содержат уязвимости, кототорые никто не обновляет". Обновляют, просто умеют считать деньги, и не обновляют, когда impact нулевой.
* Пишут, что девендоринг Java, и, тем более, динамическая ее линковка, стоили несколько десятков человеко-лет компании. "To introduce properly working dynamically linked JDK to Fedora took several excellent engineers several years. Even after a decade, there are remaining unfixed issues. And new issues are appearing.", и "This is the holy grail we have been pursuing for last 10 years. But now we gave up. To keep java alive in Fedora, we have to take this one step back." Вообще, тут, конечно, динамическая линковка кажется каким-то совершенно cargo cult, а не чем-то полезным.
* С поддержкой Wayland все не очень понятно.
* Так же рассматривались 2 решения, которые не нашли поддержки - просто переупаковывать сборку от Oracle, или забить на Java в репозиториях at all, потому что для прода все равно ставят Oracle. Ну, понятно, такое не прокатило, а зря.
* Вендоры иногда так патчат забандленные библиотеки, что их невозможно смержить с upstream. Не вижу в этом проблем per se, пусть патчат. На то это и OSS, что можно не договариваться с упырями в upstream, и просто самому себе готовить нужный продукт.
TL;DR - fedora офигели от сложности де-вендоринга Java, и решили поставлять ее as is, с теми либами, которые вендорит Oracle.
https://lwn.net/ml/fedora-devel/CA+voJeUVXW2XYHKaJ8S2N3KgvSMVUx6TsKFOvDDnjctsdO70jA@mail.gmail.com/ - переписка про это.
Я, с одной стороны, считаю, что это правильный путь, с другой - максимализм Федоры меня поражает, они хотят оставить завендоренными и freetype, и harfbuzz. А это значит, что гуевые Java приложения будут выглядеть ЕЩЕ более вырвиглазно.
С другой стороны, понятно, почему таки вендорить эти библиотеки им нужно - они хотят поставлять один tgz файл для всех версий федоры и rhel, с целью упрощения прохождения java conformance test. Тест нельзя не проходить, если ты хочешь называть финальный продукт Java.
Что еще интересного:
* вендоры периодически патчат уязвимости быстрее, чем это делают дистрибутивы. Это, практически, шах и мат для аргументов в стиле "завендоренные либы содержат уязвимости, кототорые никто не обновляет". Обновляют, просто умеют считать деньги, и не обновляют, когда impact нулевой.
* Пишут, что девендоринг Java, и, тем более, динамическая ее линковка, стоили несколько десятков человеко-лет компании. "To introduce properly working dynamically linked JDK to Fedora took several excellent engineers several years. Even after a decade, there are remaining unfixed issues. And new issues are appearing.", и "This is the holy grail we have been pursuing for last 10 years. But now we gave up. To keep java alive in Fedora, we have to take this one step back." Вообще, тут, конечно, динамическая линковка кажется каким-то совершенно cargo cult, а не чем-то полезным.
* С поддержкой Wayland все не очень понятно.
* Так же рассматривались 2 решения, которые не нашли поддержки - просто переупаковывать сборку от Oracle, или забить на Java в репозиториях at all, потому что для прода все равно ставят Oracle. Ну, понятно, такое не прокатило, а зря.
* Вендоры иногда так патчат забандленные библиотеки, что их невозможно смержить с upstream. Не вижу в этом проблем per se, пусть патчат. На то это и OSS, что можно не договариваться с упырями в upstream, и просто самому себе готовить нужный продукт.
🔥6👍1
https://www.opennet.ru/opennews/art.shtml?num=57340
Вышла свежая версия PHP.
Некоторые полезные фичи, которые, определенно, нужно подсветить:
"Добавлены отдельные типы "false" и "null", которые могут принимать только одно допустимое значение и использоваться, например, для возвращения функцией признака завершения с ошибкой или пустого значения. Ранее "false" и "null" могли использоваться только в связке с другими типами (например, "string|false"), а теперь могут применяться отдельно"
"Объявлены устаревшими частично поддерживаемые вызываемые объекты (callable), которые могут быть вызваны через "call_user_func($callable)", но не поддерживают вызов в форме "$callable()":
"self::method"
"parent::method"
"static::method"
["self", "method"]
["parent", "method"]
["static", "method"]
["Foo", "Bar::method"]
[new Foo, "Bar::method"]"
ШТО?
Зачем люди продолжают писать код на этом, я не очень понимаю, да и не стремлюсь.
Вышла свежая версия PHP.
Некоторые полезные фичи, которые, определенно, нужно подсветить:
"Добавлены отдельные типы "false" и "null", которые могут принимать только одно допустимое значение и использоваться, например, для возвращения функцией признака завершения с ошибкой или пустого значения. Ранее "false" и "null" могли использоваться только в связке с другими типами (например, "string|false"), а теперь могут применяться отдельно"
"Объявлены устаревшими частично поддерживаемые вызываемые объекты (callable), которые могут быть вызваны через "call_user_func($callable)", но не поддерживают вызов в форме "$callable()":
"self::method"
"parent::method"
"static::method"
["self", "method"]
["parent", "method"]
["static", "method"]
["Foo", "Bar::method"]
[new Foo, "Bar::method"]"
ШТО?
Зачем люди продолжают писать код на этом, я не очень понимаю, да и не стремлюсь.
www.opennet.ru
Началось альфа-тестирование PHP 8.2
Представлен первый альфа-выпуск новой ветки языка программирования PHP 8.2. Релиз намечен на 24 ноября. Основные новшества, уже доступные для тестирования или планируемые к реализации в PHP 8.2:
👍6
https://www.opennet.ru/opennews/art.shtml?num=57341
Сломался ceph + kuber у проекта freedesktop. #gitlab #infra #selfhost
Я бы тут хотел толкнуть мысль, что надежные распределенные решения - это нифига не дешево, и оно имеет смысл только на large scale.
Удивительный факт - сами по себе консенсусные распределенные решения довольно надежны, но, при этом, очень хрупки, требуют тонкой настройки окружения, и со взрывом ломаются без должного к себе отношения.
Если вы, вдруг, решили на 3 хоста взгромоздить кубер, а в него ceph, чтобы сэкономить на поддержке и администрировании, нужно понимать, что:
* скорее всего, вы не понимаете базовых требований к инфраструктуре, чтобы консенсусное решние было действительно надежным. Например, что нужно быть уверенным, что запись на диск - это реально запись на диск, а не в память контроллера. С ходу - в каких OS/FS какие нужны настройки, чтобы это гарантировать?
* скорее всего, у вас не будет админа или девопса 24/7, который будет решать проблемы вида "у нас на одном из 3 ssd заканчивается место, скоро все наши хитрые консенсусные алгоритмы перестанут гарантировать то, что они гарантируют".
Повторю, эти знания, и эти ресурсы имеют смысл только если вы большой провайдер облачной инфраструктуры.
Если вы думаете, "а, но у меня на домашнем сервере все работает" - ну, извините, вам пока просто везло, но статистика - штука неумолимая, у вас оно ебнет с гораздо более выской вероятностью. Однажды вы промахнетесь, и поставите на все свои 2 хоста кривое ядро, которое за две недели разнесет вам все к херам, до полной невозможности восстановления.
Поэтому, конечно, freedesktop - школота.
Почитать про развитие событий из первых рук можно, например, тут - https://people.freedesktop.org/~cbrill/dri-log/?channel=freedesktop&highlight_names=&date=2022-06-12&show_html=true
Сломался ceph + kuber у проекта freedesktop. #gitlab #infra #selfhost
Я бы тут хотел толкнуть мысль, что надежные распределенные решения - это нифига не дешево, и оно имеет смысл только на large scale.
Удивительный факт - сами по себе консенсусные распределенные решения довольно надежны, но, при этом, очень хрупки, требуют тонкой настройки окружения, и со взрывом ломаются без должного к себе отношения.
Если вы, вдруг, решили на 3 хоста взгромоздить кубер, а в него ceph, чтобы сэкономить на поддержке и администрировании, нужно понимать, что:
* скорее всего, вы не понимаете базовых требований к инфраструктуре, чтобы консенсусное решние было действительно надежным. Например, что нужно быть уверенным, что запись на диск - это реально запись на диск, а не в память контроллера. С ходу - в каких OS/FS какие нужны настройки, чтобы это гарантировать?
* скорее всего, у вас не будет админа или девопса 24/7, который будет решать проблемы вида "у нас на одном из 3 ssd заканчивается место, скоро все наши хитрые консенсусные алгоритмы перестанут гарантировать то, что они гарантируют".
Повторю, эти знания, и эти ресурсы имеют смысл только если вы большой провайдер облачной инфраструктуры.
Если вы думаете, "а, но у меня на домашнем сервере все работает" - ну, извините, вам пока просто везло, но статистика - штука неумолимая, у вас оно ебнет с гораздо более выской вероятностью. Однажды вы промахнетесь, и поставите на все свои 2 хоста кривое ядро, которое за две недели разнесет вам все к херам, до полной невозможности восстановления.
Поэтому, конечно, freedesktop - школота.
Почитать про развитие событий из первых рук можно, например, тут - https://people.freedesktop.org/~cbrill/dri-log/?channel=freedesktop&highlight_names=&date=2022-06-12&show_html=true
www.opennet.ru
Сбой в GitLab-инфраструктуре FreeDesktop, затронувший репозитории многих проектов
Поддерживаемая сообществом FreeDesktop инфраструктура разработки на основе платформы GitLab (gitlab.freedesktop.org) оказалась недоступна из-за выхода из строя сразу двух SSD-накопителей в распределённом хранилище на базе ФС Ceph. Пока не даётся никаких прогнозов…
👍10🤔3👎1
https://www.opennet.ru/opennews/art.shtml?num=57358 #cve #CVE
"It is all about probability"
Извините, что опять не про сборку, но у меня бугуртит, и я хочу поделиться.
Full disclosure - я не верю в безопасность. По крайней мере, в том виде, в котором ее нам "продают".
Я не верю в CVE.
Реальные взломы не происходят через публично доступные CVE. Ладно, на самом деле, раз в год бывают ситуации, когда в CVE пишут "ну вот тут у нас сломан chrome, и мы реально встречали взломы через этот баг in the wild". Раз в год, из всех CVE.
Во всем остальном база данных CVE:
* PR для тех или иных работников безопасности. Найти какую-нить дичь, которой присвоят CVE - это всегда полезно для CV.
* Удобная пугалка для RedHat, с помощью которой можно обосновать необходимость платной подписки на обновления софта.
* Удобный аргумент для сторонников динамической линковки. На самом деле, так себе аргумент, потому что пересобрать все зависимости не так уж и дорого(помните, я писал про скорость роста CPU мощностей, и про скорость роста сложности софта?), и скачать их через CDN - тоже.
Я, например, не согласен, что, когда случается баг в zlib, нужно бежать сломя голову, и обновлять всякое старое говно мамонта.
Когда нашли багу в zlib, нужно обновить nginx/envoy/etc, и не более того. Все остальное - в порядке очереди.
Есть один класс проблем, которые нужно чинить быстро - это проблемы в браузере.
(Я такую вещь еще скажу - если вы чувствуете странное успокоение, после того, как накатили все обновления безопасности - сходите, проверьте, нет ли у вас anxiety disorder, пилюльки от доброго врача помогают надежнее. Это, конечно, шутка, но в любой шутке, как известно...)
Так же я не верю в CVE, потому что bug bounty программы от вендоров - это смешные копейки.
Будьте уверены, что реальные zero days люди продают за десятки миллионов долларов, в даркнете.
Покупают их(или находят сами, если есть возможность), очевидно, государства. В своей юрисдикции государства могут с полпинка почти все, что угодно, а вот для работы на чужой юрисдикции им нужно пойти и купить zero day.
Поэтому CVE, и дыры, через которые реально хачат - это две большие разницы.
Так, введение закончилось, теперь про данный конкретный случай.
Что я про него могу сказать?
Статья на https://lwn.net/Articles/897914/ про него начинается так:
"Today's branded, logo-equipped vulnerability is known as Hertzbleed"
Что тут написано? Что авторы уже придумали красивое название, и завели сайт, посвященный уязвимости.
На самом деле, на этом можно было бы и закончить, и ежу понятно, на кого вся эта показуха рассчитана(не на нас с вами), добавлю только, что я очень хочу, чтобы облачные вендоры уже начали разделять локации с mitigations=off, и с mitigations=on.
Я вас уверяю, разница в цене в 2 раза сразу бы показала, что людям важно, а что - нет, и что делается исключительно для красивой статьи, заголовка в новостях, ну и бюджеты нужно обосновывать.
Чтобы уже перестали пугать всеми этими спектрами, мельтдаунами, и честно сказали - "современные процессоры - сложная штука, там миллиард кешей, поэтому там теперь всегда будет возможность утечки по сторонним каналам".
PS: текст довольно controversal, поэтому я тут явно напишу, что это исключительно мое, и только мое, мнение.
"It is all about probability"
Извините, что опять не про сборку, но у меня бугуртит, и я хочу поделиться.
Full disclosure - я не верю в безопасность. По крайней мере, в том виде, в котором ее нам "продают".
Я не верю в CVE.
Реальные взломы не происходят через публично доступные CVE. Ладно, на самом деле, раз в год бывают ситуации, когда в CVE пишут "ну вот тут у нас сломан chrome, и мы реально встречали взломы через этот баг in the wild". Раз в год, из всех CVE.
Во всем остальном база данных CVE:
* PR для тех или иных работников безопасности. Найти какую-нить дичь, которой присвоят CVE - это всегда полезно для CV.
* Удобная пугалка для RedHat, с помощью которой можно обосновать необходимость платной подписки на обновления софта.
* Удобный аргумент для сторонников динамической линковки. На самом деле, так себе аргумент, потому что пересобрать все зависимости не так уж и дорого(помните, я писал про скорость роста CPU мощностей, и про скорость роста сложности софта?), и скачать их через CDN - тоже.
Я, например, не согласен, что, когда случается баг в zlib, нужно бежать сломя голову, и обновлять всякое старое говно мамонта.
Когда нашли багу в zlib, нужно обновить nginx/envoy/etc, и не более того. Все остальное - в порядке очереди.
Есть один класс проблем, которые нужно чинить быстро - это проблемы в браузере.
(Я такую вещь еще скажу - если вы чувствуете странное успокоение, после того, как накатили все обновления безопасности - сходите, проверьте, нет ли у вас anxiety disorder, пилюльки от доброго врача помогают надежнее. Это, конечно, шутка, но в любой шутке, как известно...)
Так же я не верю в CVE, потому что bug bounty программы от вендоров - это смешные копейки.
Будьте уверены, что реальные zero days люди продают за десятки миллионов долларов, в даркнете.
Покупают их(или находят сами, если есть возможность), очевидно, государства. В своей юрисдикции государства могут с полпинка почти все, что угодно, а вот для работы на чужой юрисдикции им нужно пойти и купить zero day.
Поэтому CVE, и дыры, через которые реально хачат - это две большие разницы.
Так, введение закончилось, теперь про данный конкретный случай.
Что я про него могу сказать?
Статья на https://lwn.net/Articles/897914/ про него начинается так:
"Today's branded, logo-equipped vulnerability is known as Hertzbleed"
Что тут написано? Что авторы уже придумали красивое название, и завели сайт, посвященный уязвимости.
На самом деле, на этом можно было бы и закончить, и ежу понятно, на кого вся эта показуха рассчитана(не на нас с вами), добавлю только, что я очень хочу, чтобы облачные вендоры уже начали разделять локации с mitigations=off, и с mitigations=on.
Я вас уверяю, разница в цене в 2 раза сразу бы показала, что людям важно, а что - нет, и что делается исключительно для красивой статьи, заголовка в новостях, ну и бюджеты нужно обосновывать.
Чтобы уже перестали пугать всеми этими спектрами, мельтдаунами, и честно сказали - "современные процессоры - сложная штука, там миллиард кешей, поэтому там теперь всегда будет возможность утечки по сторонним каналам".
PS: текст довольно controversal, поэтому я тут явно напишу, что это исключительно мое, и только мое, мнение.
www.opennet.ru
Hertzbleed - новое семейство атак по сторонним каналам, затрагивающее современные CPU
Группа исследователей из Техасского, Иллинойсского и Вашингтонского университетов раскрыли сведения о новом семействе атак по сторонним каналам (CVE-2022-23823, CVE-2022-24436), получившим кодовое имя Hertzbleed. Предложенный метод атаки основан на особенностях…
👍7👎5❤2🔥1
#strong_ai
Слушайте, а что вы думаете про https://www.ixbt.com/news/2022/06/14/opublikovan-dialog-s-razumnym-ii-google-lamda-kotoryj-nazyvaet-sebja-chelovekom.html ?
Серьезный фактчекинг мне недоступен.
Это может быть как что-то действительно интересное, так и графомания пары человек. Лично мне кажется больше похожим на очередной AI фанфик.
В любом случае, напомню содержание предыдущей серии моего размышления про сильный AI:
* Мне достаточно очевидно, что в течении моей жизни я познакомлюсь с сильным AI, который для меня ничем не будет отличим от человека. Ну, кроме того, что он во всем будет лучше.
* Мне совершенно неочевидно, что это создание будет обладать таким качеством, как человеческое самоосознание. Кстати, в одной из прошлых серий мне рассказали про гипотетическую конструкцию, которая сможет про некоторый класс AI утверждать, что оно таким свойством обладает, до этого мне казалось, что это невозможно.
TL;DR; - зачем плодить големов?
Я, повторюсь, совершенно сформировавшийся AI луддит, я считаю, что нам уже пора бы поиграть в бутлерианский джихад, и ограничить strong AI вождением машин и работой на заводах.
И заняться улучшением работы человеческого мозга.
Возможно, однажды мы его проапгрейдим настолько, что он сможет понять, что делать с этой задачей(пониманием, есть ли у какой-то конструкции самоосознание, или нет) вообще, а пока это игры с огнем. Например, эти игры прекрасно объясняют парадокс Ферми.
Добавлю, что это совершенно не страх перед новым, я бы с удовольствием чему-нить поучился у кого-то сильно более умного, но мне совершенно не интересно передать эстафету развития машине, которая, на самом деле, не осознает себя.
UPD: я прекрасно понимаю, что, с точки зрения наблюдателя, вселенные, в которых X обладает человеческим самоосознанием, и не обладает, могут быть совершенно неразличимы. Для меня это не повод сказать "ну ок, тогда shut up and calc", а повод сказать "наш способ описания вселенной через взаимодействия несовершенен, потому что не позволяет мне сформулировать проверяемое утверждение "я обладаю самоосознанием"".
Слушайте, а что вы думаете про https://www.ixbt.com/news/2022/06/14/opublikovan-dialog-s-razumnym-ii-google-lamda-kotoryj-nazyvaet-sebja-chelovekom.html ?
Серьезный фактчекинг мне недоступен.
Это может быть как что-то действительно интересное, так и графомания пары человек. Лично мне кажется больше похожим на очередной AI фанфик.
В любом случае, напомню содержание предыдущей серии моего размышления про сильный AI:
* Мне достаточно очевидно, что в течении моей жизни я познакомлюсь с сильным AI, который для меня ничем не будет отличим от человека. Ну, кроме того, что он во всем будет лучше.
* Мне совершенно неочевидно, что это создание будет обладать таким качеством, как человеческое самоосознание. Кстати, в одной из прошлых серий мне рассказали про гипотетическую конструкцию, которая сможет про некоторый класс AI утверждать, что оно таким свойством обладает, до этого мне казалось, что это невозможно.
TL;DR; - зачем плодить големов?
Я, повторюсь, совершенно сформировавшийся AI луддит, я считаю, что нам уже пора бы поиграть в бутлерианский джихад, и ограничить strong AI вождением машин и работой на заводах.
И заняться улучшением работы человеческого мозга.
Возможно, однажды мы его проапгрейдим настолько, что он сможет понять, что делать с этой задачей(пониманием, есть ли у какой-то конструкции самоосознание, или нет) вообще, а пока это игры с огнем. Например, эти игры прекрасно объясняют парадокс Ферми.
Добавлю, что это совершенно не страх перед новым, я бы с удовольствием чему-нить поучился у кого-то сильно более умного, но мне совершенно не интересно передать эстафету развития машине, которая, на самом деле, не осознает себя.
UPD: я прекрасно понимаю, что, с точки зрения наблюдателя, вселенные, в которых X обладает человеческим самоосознанием, и не обладает, могут быть совершенно неразличимы. Для меня это не повод сказать "ну ок, тогда shut up and calc", а повод сказать "наш способ описания вселенной через взаимодействия несовершенен, потому что не позволяет мне сформулировать проверяемое утверждение "я обладаю самоосознанием"".
IXBT.com
Опубликован диалог с «разумным» ИИ Google LaMDA, который называет себя человеком
Его опубликовал один из специалистов проекта
🤔6👍1
https://www.opennet.ru/opennews/art.shtml?num=57364 #hare #ddv
Автор sway представил свою новую микроядерную OS.
Знаете, когда он, недавно, представил какой-то всратейший язык программирования, я смолчал.
Все же, автор #sway, #source_hut, и вообще, уважаемый человек.
Но тут он совсем кукухой двинулся - сначала запилил очень странный язык(примерно такой же низкоуровневый, как С, с чертами Go, но по стройности не дотягивает до того же zig), а теперь и новую OS на нем.
Я бы, конечно, предложил ему ix в качестве пакетного менеджера, но он же на неправославном python.
Кстати, все еще предлагаю кому-нить взять задачку про запил graph execution engine на православном С++/Rust.
———
Я, вдруг, понял, что последние пару недель не делаю ничего существенного ни в движке #IX, ни в пакетной базе #stal/IX. Так, рутина по обновлению версий.
Ну, положил вот mariadb, ну пидарасы они - написали своих заголовков для системных библиотек, типа zlib.h, lz4.h, etc, потому что хотят уметь загружать их в runtime. Но это так, не тянет на большую историю.
В связи с этим у меня вопрос к оунерам известных проектов - а чо дальше то?
Есть какой-то мануал?
У меня тут довольно примерное понимание - запилить сайт-визитку со ссылками, запилить документацию по установке, и на этом все.
Накидайте, короче, советов, на тему "как в первый раз выйти в свет"! На чем запилить сайт-визитку?
Автор sway представил свою новую микроядерную OS.
Знаете, когда он, недавно, представил какой-то всратейший язык программирования, я смолчал.
Все же, автор #sway, #source_hut, и вообще, уважаемый человек.
Но тут он совсем кукухой двинулся - сначала запилил очень странный язык(примерно такой же низкоуровневый, как С, с чертами Go, но по стройности не дотягивает до того же zig), а теперь и новую OS на нем.
Я бы, конечно, предложил ему ix в качестве пакетного менеджера, но он же на неправославном python.
Кстати, все еще предлагаю кому-нить взять задачку про запил graph execution engine на православном С++/Rust.
———
Я, вдруг, понял, что последние пару недель не делаю ничего существенного ни в движке #IX, ни в пакетной базе #stal/IX. Так, рутина по обновлению версий.
Ну, положил вот mariadb, ну пидарасы они - написали своих заголовков для системных библиотек, типа zlib.h, lz4.h, etc, потому что хотят уметь загружать их в runtime. Но это так, не тянет на большую историю.
В связи с этим у меня вопрос к оунерам известных проектов - а чо дальше то?
Есть какой-то мануал?
У меня тут довольно примерное понимание - запилить сайт-визитку со ссылками, запилить документацию по установке, и на этом все.
Накидайте, короче, советов, на тему "как в первый раз выйти в свет"! На чем запилить сайт-визитку?
www.opennet.ru
Автор оболочки Sway и языка Hare развивает новое микроядро Helios и OC Ares
Дрю ДеВолт (Drew DeVault) представил свой новый проект - микроядро Helios. В текущем виде проект находится на начальной стадии разработки и пока поддерживает только демонстрационную загрузку на системах с архитектурой x86_64. В дальнейшем планируют реализовать…
👍4
https://jmmv.dev/2022/06/autoconf-caching.html
Интересный текст про одну малоизвестную фичу #autohell, и про ее полезное применение.
TL;DR - для configure можно заранее приготовить список ответов на вопросы про систему, которое оно задает.
В тексте указывается специальный ключ для configure скрипта, но, на практике, этим никто не пользуется.
Все просто выставляют переменные среды, которые читает configure скрипт:
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/gdb/t/ix.sh#L33 - вот тут явыставляю, что у меня нет ada компилятора.
Все эти проверки написаны на shell, глючат от версии к версии, никто не полезет разбираться, почему эта конкретная проверка просто зависает, проверяя, что в clang нет поддержки Ada.
Все дистростроители про эту фичу знают, и активно ей пользуются. Почему? Потому что они работают, как говно, недавно писал про такой случай - #werror
Тут возникает резонный вопрос - а что, если посчитать все такие стандартные переменные, записать их в файлик для target platform, и применять перед каждым configure?
Мне, как proud owner своего дистрибутива, это:
* интересно
* довольно просто попробовать
Я однажды это и сделал, но почему-то не написал. Наверное, потому что это было еще до того, как я начал активно писать про #stal/IX, а потом просто забыл.
Статья мне про этот случай напомнила, вот, пишу.
Эксперимент я поставил довольно простой - сделал чистую пересборку всего дистрибутива, при этом сохранял все артефакты от всех запусков configure.
Далее все довольно просто - объединяем их, берем часто встречающиеся, и образовывающие непротиворечивое подмножество. Да, иногда разные скрипты выставляют одну и ту же переменную в разные значения - это может означать, что эта переменная используется по разному, или глюк в autodetect.
В целом, профит хороший, скрипты ускоряются кто в 2 раза, кто на 20% - зависит от числа кастомных проверок и от их сложности.
Внедрил ли я это? Нет, пока не внедрил - страшно.
Дебажить проблемы, связанные с неверным автодетектом фичей - сложно и муторно, у тебя потом в километре от сборки grep выдаст какую-то херню, которая повлияет на сборку третьего пакета.
Ну и, на самом-то деле, профит не такой уж и большой, autohell в дистрибутивах все меньше и меньше.
Мне эта фича, скорее, интересна в плане кросс-компиляции, когда configure скрипты работают херово, по понятным причинам(криворукие авторы пытаются по запуску host программы что-то узнать про target систему).
Интересный текст про одну малоизвестную фичу #autohell, и про ее полезное применение.
TL;DR - для configure можно заранее приготовить список ответов на вопросы про систему, которое оно задает.
В тексте указывается специальный ключ для configure скрипта, но, на практике, этим никто не пользуется.
Все просто выставляют переменные среды, которые читает configure скрипт:
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/gdb/t/ix.sh#L33 - вот тут явыставляю, что у меня нет ada компилятора.
Все эти проверки написаны на shell, глючат от версии к версии, никто не полезет разбираться, почему эта конкретная проверка просто зависает, проверяя, что в clang нет поддержки Ada.
Все дистростроители про эту фичу знают, и активно ей пользуются. Почему? Потому что они работают, как говно, недавно писал про такой случай - #werror
Тут возникает резонный вопрос - а что, если посчитать все такие стандартные переменные, записать их в файлик для target platform, и применять перед каждым configure?
Мне, как proud owner своего дистрибутива, это:
* интересно
* довольно просто попробовать
Я однажды это и сделал, но почему-то не написал. Наверное, потому что это было еще до того, как я начал активно писать про #stal/IX, а потом просто забыл.
Статья мне про этот случай напомнила, вот, пишу.
Эксперимент я поставил довольно простой - сделал чистую пересборку всего дистрибутива, при этом сохранял все артефакты от всех запусков configure.
Далее все довольно просто - объединяем их, берем часто встречающиеся, и образовывающие непротиворечивое подмножество. Да, иногда разные скрипты выставляют одну и ту же переменную в разные значения - это может означать, что эта переменная используется по разному, или глюк в autodetect.
В целом, профит хороший, скрипты ускоряются кто в 2 раза, кто на 20% - зависит от числа кастомных проверок и от их сложности.
Внедрил ли я это? Нет, пока не внедрил - страшно.
Дебажить проблемы, связанные с неверным автодетектом фичей - сложно и муторно, у тебя потом в километре от сборки grep выдаст какую-то херню, которая повлияет на сборку третьего пакета.
Ну и, на самом-то деле, профит не такой уж и большой, autohell в дистрибутивах все меньше и меньше.
Мне эта фича, скорее, интересна в плане кросс-компиляции, когда configure скрипты работают херово, по понятным причинам(криворукие авторы пытаются по запуску host программы что-то узнать про target систему).
Julio Merino (jmmv.dev)
Speeding up autoconf with caching - Julio Merino (jmmv.dev)
In the recent Remembering Buildtool post, I described how setting up a cache of configuration checks was an important step in Buildtool’s installation process. The goal was to avoid pointless …
🔥4👍1
Я пару раз писал про то, что совершенно не доверяю тестам от #phoronix.
Еще я писал про то, как люблю проекты, в которых поддержано 3 разных системы сборки, и непонятно, какую из них выбрать.
И, буквально вчера, про сложность отлабки проблем с configure скриптами(в общем, не только от #autohell).
Вот, пожалуйте, как в воду глядел - https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-Bizarre-Zstd
TL;DR - Михаил тестировал разные дистрибутивы Linux на perf, и у него оказалось, что zstd сильно медленнее в Arch, чем в остальных дистрибутивах.
Выяснилось:
* Что arch использует cmake сборку(я тоже), остальные - простой Makefile
* В cmake сборке используется не тот стандарт на C, что и в остальных сборках. В Makefile - default, в cmake, вроде, с99, в meson - gnu99(есть и такой, они там совсем кукухой поехали).
* Бага только в многопоточном тесте, бага в использовании тормозного таймера - https://github.com/facebook/zstd/pull/3165/commits/376b9a0be4cc2972f2d2c4074ae1b6dfbe381330
https://github.com/facebook/zstd/issues/3163#issuecomment-1159627324
Что я могу сказать?
* Сборка OSS программ - это очень subtle вещь. Поэтому я, например, так и не перешел на более быстрый shell для запуска configure, и использую всратые coreutils.
* Phoronix заинтересованы в сенсации, а не в корректном и скучном освещении событий. Поэтому, когда там где-то написано, что freebsd выигрывает у linux в 2 раза, или наоборот - то это не заслуга OS, блин, не могут OS реально настолько отличаться, особенно в CPU intensive, а степень кривизны рук авторов configure(которые могут включить ассемблерные вставки только под Linux, например), или Миши, которому насрать.
(Побугурчу про Мишу, его стиль письма очень доставляет. Найдете хоть один текст без слова "exciting" - киньте мне, помещу под стекло. Степень его экзальтированности зашкаливает)
Я ничо делать не стал, потому что, напомню, я плевал на особое мнение upstream, и у меня есть clang wrapper, который определяет оптимизации так, как я считаю правильным.
Ну и проблема только в тесте, а Makefile у них кривой донельзя, не зря я(и Arch) выбрал cmake.
Еще я писал про то, как люблю проекты, в которых поддержано 3 разных системы сборки, и непонятно, какую из них выбрать.
И, буквально вчера, про сложность отлабки проблем с configure скриптами(в общем, не только от #autohell).
Вот, пожалуйте, как в воду глядел - https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-Bizarre-Zstd
TL;DR - Михаил тестировал разные дистрибутивы Linux на perf, и у него оказалось, что zstd сильно медленнее в Arch, чем в остальных дистрибутивах.
Выяснилось:
* Что arch использует cmake сборку(я тоже), остальные - простой Makefile
* В cmake сборке используется не тот стандарт на C, что и в остальных сборках. В Makefile - default, в cmake, вроде, с99, в meson - gnu99(есть и такой, они там совсем кукухой поехали).
* Бага только в многопоточном тесте, бага в использовании тормозного таймера - https://github.com/facebook/zstd/pull/3165/commits/376b9a0be4cc2972f2d2c4074ae1b6dfbe381330
https://github.com/facebook/zstd/issues/3163#issuecomment-1159627324
Что я могу сказать?
* Сборка OSS программ - это очень subtle вещь. Поэтому я, например, так и не перешел на более быстрый shell для запуска configure, и использую всратые coreutils.
* Phoronix заинтересованы в сенсации, а не в корректном и скучном освещении событий. Поэтому, когда там где-то написано, что freebsd выигрывает у linux в 2 раза, или наоборот - то это не заслуга OS, блин, не могут OS реально настолько отличаться, особенно в CPU intensive, а степень кривизны рук авторов configure(которые могут включить ассемблерные вставки только под Linux, например), или Миши, которому насрать.
(Побугурчу про Мишу, его стиль письма очень доставляет. Найдете хоть один текст без слова "exciting" - киньте мне, помещу под стекло. Степень его экзальтированности зашкаливает)
Я ничо делать не стал, потому что, напомню, я плевал на особое мнение upstream, и у меня есть clang wrapper, который определяет оптимизации так, как я считаю правильным.
Ну и проблема только в тесте, а Makefile у них кривой донельзя, не зря я(и Arch) выбрал cmake.
Phoronix
The Bizarre Case Of Zstd's Very Slow Performance On Arch Linux
Yesterday I posted benchmarks of six Linux distributions on the HP Dev One, the exciting new Linux laptop launched by HP in collaboration with System76 that is using their Pop!_OS distribution
👍6👎1
#llvm weekly
https://reviews.llvm.org/rGf06abbb39380
Аааа, llvm busybox style binary приземлился! Пока в довольно ограниченном виде:
(1) the multicall binary cannot currently properly handle
multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver
will not properly result in llvm-ar's main being called.
(2) the multicall binary cannot be comprised of tools containing
conflicting cl::opt options as the global cl::opt option list cannot
contain duplicates.
Но лиха беда начало!
В прошлых сериях рассказывал, почему такой multicall хорошо и правильно, и что в llvm community есть сильное мнение против этой фичи. Очень переживал, что оно так и не будет внедрено, поэтому рад несказанно.
———
https://mawfig.github.io/2022/06/18/v-lang-in-2022.html
https://lobste.rs/s/hfjlba/v_language_review_2022
Давеча писал про #vlang, с прицелом на написание необходимых мне сборочных скриптов.
Python ужасно тормозной, например, мой clang wrapper замедляет сборку примерно в 2 раза, а его задача - просто переосмыслить cmd line для запуска настоящего компилятора.
Мне, конечно, тогданапихали за щеку рассказали, что vlang лучше не трогать, потому что его авторы рассказывают, но не показывают.
Вот, по ссылке - разбор современного состояния vlang.
TL;DR; - все плохо, бОльшая часть заявленных фичей не работает, да и корки в типа безопасном языке - ну такое.
———
Bootstrap story.
Собирал себе wireshark. Потому что в транк приземлили поддержку QT6, а QT5 у меня нет, и мне ее лень собирать.
Все прошло, как по маслу, разрабы wireshark молодцы, у них прямо есть опция для сборки wireshark без плагинов.
Но что-то сломалось в сумасшедших скриптах для cmake от QT, они начали писать, что, внезапно, у меня нет glib, хотя он, конечно, присутствовал.
Дебажить cmake скрипты - это дело совершенно безблагодатное, поэтому мне показалось, что проще убрать упоминание про glib в сгенеренных cmake скриптах от QT - https://github.com/pg83/ix/commit/7b46d6133b62f7b09cb37a57ba3817313e90ae7a#diff-19b6fefa6a33c75dfaedcd1b884a63a665b515b6c9894595aec999a951da530bR53
Лучше, конечно, было бы разобраться, но в cmake нет такой возможности.
Все, что оно умеет для отладки - это выдать дамп исполнения, со значениями переменных, которые были в IF(), FOR(), etc.
Я однажды пробовал раздебажить такой дамп, дело это не из приятных. Десятки мегабайт текста без какой-то внятной структуры.
https://reviews.llvm.org/rGf06abbb39380
Аааа, llvm busybox style binary приземлился! Пока в довольно ограниченном виде:
(1) the multicall binary cannot currently properly handle
multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver
will not properly result in llvm-ar's main being called.
(2) the multicall binary cannot be comprised of tools containing
conflicting cl::opt options as the global cl::opt option list cannot
contain duplicates.
Но лиха беда начало!
В прошлых сериях рассказывал, почему такой multicall хорошо и правильно, и что в llvm community есть сильное мнение против этой фичи. Очень переживал, что оно так и не будет внедрено, поэтому рад несказанно.
———
https://mawfig.github.io/2022/06/18/v-lang-in-2022.html
https://lobste.rs/s/hfjlba/v_language_review_2022
Давеча писал про #vlang, с прицелом на написание необходимых мне сборочных скриптов.
Python ужасно тормозной, например, мой clang wrapper замедляет сборку примерно в 2 раза, а его задача - просто переосмыслить cmd line для запуска настоящего компилятора.
Мне, конечно, тогда
Вот, по ссылке - разбор современного состояния vlang.
TL;DR; - все плохо, бОльшая часть заявленных фичей не работает, да и корки в типа безопасном языке - ну такое.
———
Bootstrap story.
Собирал себе wireshark. Потому что в транк приземлили поддержку QT6, а QT5 у меня нет, и мне ее лень собирать.
Все прошло, как по маслу, разрабы wireshark молодцы, у них прямо есть опция для сборки wireshark без плагинов.
Но что-то сломалось в сумасшедших скриптах для cmake от QT, они начали писать, что, внезапно, у меня нет glib, хотя он, конечно, присутствовал.
Дебажить cmake скрипты - это дело совершенно безблагодатное, поэтому мне показалось, что проще убрать упоминание про glib в сгенеренных cmake скриптах от QT - https://github.com/pg83/ix/commit/7b46d6133b62f7b09cb37a57ba3817313e90ae7a#diff-19b6fefa6a33c75dfaedcd1b884a63a665b515b6c9894595aec999a951da530bR53
Лучше, конечно, было бы разобраться, но в cmake нет такой возможности.
Все, что оно умеет для отладки - это выдать дамп исполнения, со значениями переменных, которые были в IF(), FOR(), etc.
Я однажды пробовал раздебажить такой дамп, дело это не из приятных. Десятки мегабайт текста без какой-то внятной структуры.
mawfig.github.io
V Language Review (2022)
V is a programming language promising to be “Simple, fast, safe, compiled. For developing maintainable software.” V has a controversial past but what is the state of V in 2022?
👍7
https://www.phoronix.com/scan.php?page=news_item&px=Rust-For-Linux-5.20-Possible
Big news!
Linus говорит, что, вполне вероятно, Rust в Linux будет уже в 5.20.
По #linux_rust_linux вы можете посмотреть, почему я эту новость считаю исключительно хорошей и лулзовой! :D
А я вот начал собирать 5.19-rc3, и оно не в очень хорошей форме - глючит подсветка экрана, и уже схлопотал зависание после выхода из сна.
———
Вышла новая телега, 4.0.0.
Видимо, такая смена версии обусловлена включением premium фичей, я почти ничего и не заметил, хотя, как только будет возможность, premium включу. Мне из него ничего не нужно, но я лично считаю, что возможность заплатить, и не видеть рекламу - это правильный подход.
Когда собирал, увидел, что телега написала нативную wayland интеграцию - из репозитория исчез враппер над kwayland - https://git.sr.ht/~pg/ix/commit/790b39736be2579587240f245a6d687f566d5de2#pkgs/bin/telegram/desktop/unwrap/t/ix.sh-1-5
Собственно, ровно оно у меня и сломалось.
Если отжать галку "use system decorations", теперь показывается старый темный window border от телеги. А если включить - то какое-то странное белое нечто, которое рисует явно не sway.
Старые декорации(темные) стали, к тому же, скругленными.
Blueeeh.
———
https://www.opennet.ru/opennews/art.shtml?num=57383
Facebook пишет swap под Linux, так, как он должен быть устроен. Ручки по настройке в ядре, сложная логика по управлению - в userspace.
Ну невозможно на C без граблей писать сложную логику.
Big news!
Linus говорит, что, вполне вероятно, Rust в Linux будет уже в 5.20.
По #linux_rust_linux вы можете посмотреть, почему я эту новость считаю исключительно хорошей и лулзовой! :D
А я вот начал собирать 5.19-rc3, и оно не в очень хорошей форме - глючит подсветка экрана, и уже схлопотал зависание после выхода из сна.
———
Вышла новая телега, 4.0.0.
Видимо, такая смена версии обусловлена включением premium фичей, я почти ничего и не заметил, хотя, как только будет возможность, premium включу. Мне из него ничего не нужно, но я лично считаю, что возможность заплатить, и не видеть рекламу - это правильный подход.
Когда собирал, увидел, что телега написала нативную wayland интеграцию - из репозитория исчез враппер над kwayland - https://git.sr.ht/~pg/ix/commit/790b39736be2579587240f245a6d687f566d5de2#pkgs/bin/telegram/desktop/unwrap/t/ix.sh-1-5
Собственно, ровно оно у меня и сломалось.
Если отжать галку "use system decorations", теперь показывается старый темный window border от телеги. А если включить - то какое-то странное белое нечто, которое рисует явно не sway.
Старые декорации(темные) стали, к тому же, скругленными.
Blueeeh.
———
https://www.opennet.ru/opennews/art.shtml?num=57383
Facebook пишет swap под Linux, так, как он должен быть устроен. Ручки по настройке в ядре, сложная логика по управлению - в userspace.
Ну невозможно на C без граблей писать сложную логику.
Phoronix
Linus Torvalds: Rust For The Kernel Could Possibly Be Merged For Linux 5.20
Speaking this morning at The Linux Foundation's Open-Source Summit, Linus Torvalds talked up the possibilities of Rust within the Linux kernel and that it could be landing quite soon -- possibly even for the next kernel cycle.
👍4👎1🐳1💯1