https://lkml.org/lkml/2022/9/19/840
Очень controversial переписка между Линусом и фанатами Rust.
Суть довольно простая - товарищи из Rust хотят притащить к себе знание, в каком контексте вызвал аллокатор, чтобы не корячить интерфейс аллокатора заради "странных" хотелок ядра, а Линус совершенно корректно объясняет им, что так делать нельзя:
"And that is FUNDAMENTALLY BROKEN.
If you want to allocate memory, and you don't want to care about what context you are in, or whether you are holding spinlocks etc, then you damn well shouldn't be doing kernel programming. Not in C, and not in Rust"
Потому что пул аллокаций, который можно распределить так, очень мал:
"But it needs to be explicit, because that GFP_ATOMIC pool of allocations really is very limited, and you as the allocator need to make it *explicit* that yeah, now you're not just doing a random allocation, you are doing one of these *special* allocations that will eat into that very limited global pool of allocations."
Я тут испытываю очень противоречивые эмоции.
С одной стороны, ядро сейчас написанно именно так, как рассказывает Линус, и, очевидно, аллокатор надо звать так, как нужно в этом ядре.
С другой - я лично считаю, что ядро надо писать так, чтобы там могло работать 99% любого случайно выбранного кода на соответствующем языке. Вот это вот знание контекста, понимание, что мы сейчас в асинхронном хендлере прерывания - это жесть, надо сделать так, чтобы программисту ядра не нужно было про это думать.
По классике, можно, например, так - https://stackoverflow.com/questions/45095735/top-halves-and-bottom-halves-concept-clarification (попрошу отметить, что в Linux так можно) - в interrupt handler просто сериализуешь данные в область памяти, и кидаешь ее в пул тредов на обработку. Конечно, бывают ситуации, когда надо "ответить" прямо здесь и сейчас, но их можно пересчитать по пальцам одной руки(ладно, я просто больше не вспомнил).
Если посмотреть на какое-нить современное ядро, типа Zircon, то там вообще хрен найдешь это место, которое выполняется асинхронно.
Очень controversial переписка между Линусом и фанатами Rust.
Суть довольно простая - товарищи из Rust хотят притащить к себе знание, в каком контексте вызвал аллокатор, чтобы не корячить интерфейс аллокатора заради "странных" хотелок ядра, а Линус совершенно корректно объясняет им, что так делать нельзя:
"And that is FUNDAMENTALLY BROKEN.
If you want to allocate memory, and you don't want to care about what context you are in, or whether you are holding spinlocks etc, then you damn well shouldn't be doing kernel programming. Not in C, and not in Rust"
Потому что пул аллокаций, который можно распределить так, очень мал:
"But it needs to be explicit, because that GFP_ATOMIC pool of allocations really is very limited, and you as the allocator need to make it *explicit* that yeah, now you're not just doing a random allocation, you are doing one of these *special* allocations that will eat into that very limited global pool of allocations."
Я тут испытываю очень противоречивые эмоции.
С одной стороны, ядро сейчас написанно именно так, как рассказывает Линус, и, очевидно, аллокатор надо звать так, как нужно в этом ядре.
С другой - я лично считаю, что ядро надо писать так, чтобы там могло работать 99% любого случайно выбранного кода на соответствующем языке. Вот это вот знание контекста, понимание, что мы сейчас в асинхронном хендлере прерывания - это жесть, надо сделать так, чтобы программисту ядра не нужно было про это думать.
По классике, можно, например, так - https://stackoverflow.com/questions/45095735/top-halves-and-bottom-halves-concept-clarification (попрошу отметить, что в Linux так можно) - в interrupt handler просто сериализуешь данные в область памяти, и кидаешь ее в пул тредов на обработку. Конечно, бывают ситуации, когда надо "ответить" прямо здесь и сейчас, но их можно пересчитать по пальцам одной руки(ладно, я просто больше не вспомнил).
Если посмотреть на какое-нить современное ядро, типа Zircon, то там вообще хрен найдешь это место, которое выполняется асинхронно.
Stack Overflow
Top halves and bottom halves concept clarification
As per the guide lines of Top halves and Bottom halves, When any interrupt comes it is handled by two halves. The so-called top half is the routine that actually responds to the interrupt—the one you
👍7🔥2
https://www.business-gazeta.ru/article/566137
У меня впервые в жизни ощущение, что профильный министр "за тебя", и "делает все возможное". В ситуации, когда в стране Министерство Войны входит везде с пинка в дверь, это, конечно, очень круто, что у Шадаева вообще что-то получается сделать, и получается хорошо.
У меня впервые в жизни ощущение, что профильный министр "за тебя", и "делает все возможное". В ситуации, когда в стране Министерство Войны входит везде с пинка в дверь, это, конечно, очень круто, что у Шадаева вообще что-то получается сделать, и получается хорошо.
👍20😁3🔥2
commit -m "better"
В clang15 появилось некоторое количество реально полезных ошибок: Making all in doc CC src/tramp.lo ../src/tramp.c:262:22: error: call to undeclared function 'open_temp_exec_file'; ISO C99 and later do not support implicit function declarations…
https://discourse.llvm.org/t/clang-16-notice-of-potentially-breaking-changes/65562
llvm начали заранее публиковать о грядущих изменениях, которые что-то ломают.
"The community is trying out a new way to alert interested parties about potentially disruptive changes in pre-release versions of our tools, and this post is the first such attempt at that. We expect to post these announcements to this channel and mark the posts with potentially-breaking so people can more easily be alerted without having to track development progress as closely. We’ve also added a potentially breaking changes section to our release notes to highlight concerns"
"нутром чую, что литра, но доказать не могу"
Я нутром чую, что это как-то связано с жопой при релизе clang15, про которые я пару раз писал, но доказательств этому найти не сумел.
llvm начали заранее публиковать о грядущих изменениях, которые что-то ломают.
"The community is trying out a new way to alert interested parties about potentially disruptive changes in pre-release versions of our tools, and this post is the first such attempt at that. We expect to post these announcements to this channel and mark the posts with potentially-breaking so people can more easily be alerted without having to track development progress as closely. We’ve also added a potentially breaking changes section to our release notes to highlight concerns"
LLVM Discussion Forums
[Clang 16] Notice of potentially breaking changes
The community is trying out a new way to alert interested parties about potentially disruptive changes in pre-release versions of our tools, and this post is the first such attempt at that. We expect to post these announcements to this channel and mark the…
👍7😁3🍌2
https://www.opennet.ru/opennews/art.shtml?num=57883
Совсем забыл написать про фееричный баг от Intel:
"Ошибка в ядре Linux 5.19.12, потенциально способная повредить экраны на ноутбуках с GPU Intel"
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c
Заслуживает тут внимания, конечно, тот факт, что "уважаемым людям" можно и в минорный релизнасрать закоммитить что-то, сильно сложнее багфикса.
Совсем забыл написать про фееричный баг от Intel:
"Ошибка в ядре Linux 5.19.12, потенциально способная повредить экраны на ноутбуках с GPU Intel"
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c
Заслуживает тут внимания, конечно, тот факт, что "уважаемым людям" можно и в минорный релиз
www.opennet.ru
Ошибка в ядре Linux 5.19.12, потенциально способная повредить экраны на ноутбуках с GPU Intel
В наборе исправлений к графическому драйверу i915, включённому в состав ядра Linux 5.19.12, выявлена критическая ошибка, потенциально способная привести к повреждению жидкокристаллических экранов (случаи повреждений, произошедшие из-за рассматриваемой проблемы…
👍4🐳4🍌3🤯2
https://www.kommersant.ru/doc/5605730
"Вооруженные силы Украины заявили, что в работе спутниковой сети Starlink наблюдаются перебои, сообщает Financial Times со ссылкой на украинских чиновников. По их словам, проблемы со связью особенно усилились на территориях, которые присоединены к России — в ДНР, ЛНР, а также в Херсонской и Запорожской областях. Основатель SpaceX Илон Маск написал в Twitter, что не может комментировать ситуацию на поле боя"
https://3dnews.ru/1012993/komanda-spacex-starlink-soznalas-chto-otpravila-na-orbitu-30-tisyach-kompyuterov-na-linux
А все потому, что нехрен дырявое решето отправлять на орбиту.
Писал, пишу, и буду писать, что security by obscurity, как один из компонентов обеспечения безопасности - хорошо!
А так - пошел на чёрный рынок, купил пару дыр задорого, и вперед.
"Вооруженные силы Украины заявили, что в работе спутниковой сети Starlink наблюдаются перебои, сообщает Financial Times со ссылкой на украинских чиновников. По их словам, проблемы со связью особенно усилились на территориях, которые присоединены к России — в ДНР, ЛНР, а также в Херсонской и Запорожской областях. Основатель SpaceX Илон Маск написал в Twitter, что не может комментировать ситуацию на поле боя"
https://3dnews.ru/1012993/komanda-spacex-starlink-soznalas-chto-otpravila-na-orbitu-30-tisyach-kompyuterov-na-linux
А все потому, что нехрен дырявое решето отправлять на орбиту.
Писал, пишу, и буду писать, что security by obscurity, как один из компонентов обеспечения безопасности - хорошо!
А так - пошел на чёрный рынок, купил пару дыр задорого, и вперед.
Коммерсантъ
FT: Украина сообщила о перебоях в работе Starlink
Подробнее на сайте
😁3🤔3🤡3🍌1
https://www.ixbt.com/news/2022/10/08/intel-horse-creek-risc-v-intel-4.html
Интересная тема, Intel дает возможность делать чужие процы на своих мощностях, причем, насколько я понял, этот техпроцесс сама Intel еще не использует в своих решениях. Такая отладка "на кошках".
Интересная тема, Intel дает возможность делать чужие процы на своих мощностях, причем, насколько я понял, этот техпроцесс сама Intel еще не использует в своих решениях. Такая отладка "на кошках".
iXBT.com
Intel показала платформу Horse Creek с процессором RISC-V на основе техпроцесса Intel 4
Компания Intel показала платформу Horse Creek с процессором на архитектуре RISC-V, который произведён по техпроцессу Intel 4. Данное решение не является разработкой Intel.
👍6🔥3🐳2❤1🍌1
https://www.phoronix.com/news/Zink-Evolve-OpenGL-API
Я уже примерно год рассказываю про то, что #zink + vulkan - это будещее графических API под Linux, но вот тут товарищи заходят даже несколько дальше - пишут, "берите vulkan, zink над ним, и дотачивайте его под свои нужды, как более простое графическое API".
В каком-то смысле это смещает восприятие opengl как "еще один (игровой?) движок поверх vulkan", наравне с тем же unity, unreal, etc.
Я уже примерно год рассказываю про то, что #zink + vulkan - это будещее графических API под Linux, но вот тут товарищи заходят даже несколько дальше - пишут, "берите vulkan, zink над ним, и дотачивайте его под свои нужды, как более простое графическое API".
В каком-то смысле это смещает восприятие opengl как "еще один (игровой?) движок поверх vulkan", наравне с тем же unity, unreal, etc.
Phoronix
Zink Could Prove An Interesting Solution For Evolving OpenGL
Erik Faye-Lund of Collabora raised an interesting discussion this past week at XDC 2022 about leveraging Zink for post-OpenGL graphics development
👍5🔥1
https://www.phoronix.com/news/Wayland-Protocols-1.27
"The content type hint notification is used for enabling clients to provide hints to the Wayland compositor around the type of visual content provided by the app. In turn the content type hint notifications can be used for the compositor to adapt its behavior. This content-type-v1 protocol was originally written last year and initially supported "content types" are photo, video, or game content. If hinted to be game content, the compositor may optimize for reduced latency, if video it may be optimized for reduced stuttering and better scaling, or photo type for minimal extra processing by the compositor. With this content-type protocol still being in staging, it's possible other content types will still be added but ultimately is left up to the compositor if/what to optimize based upon the various content types"
У нас тут очередной #wayland moment, если вы понимаете, о чем я.
Давайте я быстренько расскажу, какую оптимизационную задачу вынужден решать wayland compositor, как ее решать правильно, и что предлагают эти наглухо упоротые люди.
(это упрощенная схема, как оно устроено "на самом деле" я представляю, но для объяснения сойдет)
Аппаратная начинка вашего монитора и видеокарты должна выдавать какой-то фиксированный RPS. Давайте для простоты вычислений скажем "20 RPS".
То есть, каждые 50ms композитор должен выдавать буфер, откуда аппаратная начинка нарисует нам следующий кадр. Если этот буфер будет меняться в момент отрисовки(например, кто-то продолжит в него писать уже после того, как отдали буфер на отрисовку, или кто-то будет генерить новый буфер быстрее, чем надо), то у нас случится тиринг, BTW.
Как это можно сделать?
(здесь и далее я намеренно не рассказываю, как это все взаимодействует с вводом, потому что это усложнит все в 10 раз)
Самый простой вариант - раз в 50ms делать gather от всех клиентов композитора, блендить их в результирующий буфер, сделать usleep(50 - X), где X - время выполнения gather + blend, и отдать готовый буффер.
С этим решением есть следующая проблема - картинка на мониторе будет отставать от логики приложения на сколько-то времени. Потому что после того, как сделан gather, логика приложения продолжает "тикать".
Это будет ощущаться как постоянный лаг(курсора мышки, нажатия на элементы интерфейса, a/v desync, лаги в играх).
Самый простой способ "пофиксить" это - это сделать usleep() на какую-то константу перед началом всей этой процедуры, так, чтобыи рыбку съесть и окна успели отрисовать себя, но и так, чтобы мы не вывалились за deadline на рисование этого кадра.
(кстати, теперь вы знаете, что делает опция max_render_time в sway, как ее тюнить, и почему она плохо работает)
Одно из правильных решений этой задачи - отдать ее на откуп приложению. Например, делать gather с самого начала кванта в 50ms, и передавать в приложение deadline(скажем, если blend занимает 10ms, то можно передать в качестве deadline now() + 40ms).
Тогда приложение, зная, сколько оно будет рисовать кадр, сможет предпринять нужные действия(например, межкадровую интерполяцию для видеоплеера, или usleep в игре).
Конец рассказа про compositor internals.
Но эти говнюки, конечно, решили сделать по другому - они будут передавать хинты для окна(игра, видео, и так далее), а композитор будет принимать какое-то решение.
И, к гадалке не ходи, GNOME media player будет знать, как работает GNOME compositor(какая там логика), и в GNOME shell оно будет работать прилично, и лагать под другими композиторами.
"The content type hint notification is used for enabling clients to provide hints to the Wayland compositor around the type of visual content provided by the app. In turn the content type hint notifications can be used for the compositor to adapt its behavior. This content-type-v1 protocol was originally written last year and initially supported "content types" are photo, video, or game content. If hinted to be game content, the compositor may optimize for reduced latency, if video it may be optimized for reduced stuttering and better scaling, or photo type for minimal extra processing by the compositor. With this content-type protocol still being in staging, it's possible other content types will still be added but ultimately is left up to the compositor if/what to optimize based upon the various content types"
У нас тут очередной #wayland moment, если вы понимаете, о чем я.
Давайте я быстренько расскажу, какую оптимизационную задачу вынужден решать wayland compositor, как ее решать правильно, и что предлагают эти наглухо упоротые люди.
(это упрощенная схема, как оно устроено "на самом деле" я представляю, но для объяснения сойдет)
Аппаратная начинка вашего монитора и видеокарты должна выдавать какой-то фиксированный RPS. Давайте для простоты вычислений скажем "20 RPS".
То есть, каждые 50ms композитор должен выдавать буфер, откуда аппаратная начинка нарисует нам следующий кадр. Если этот буфер будет меняться в момент отрисовки(например, кто-то продолжит в него писать уже после того, как отдали буфер на отрисовку, или кто-то будет генерить новый буфер быстрее, чем надо), то у нас случится тиринг, BTW.
Как это можно сделать?
(здесь и далее я намеренно не рассказываю, как это все взаимодействует с вводом, потому что это усложнит все в 10 раз)
Самый простой вариант - раз в 50ms делать gather от всех клиентов композитора, блендить их в результирующий буфер, сделать usleep(50 - X), где X - время выполнения gather + blend, и отдать готовый буффер.
С этим решением есть следующая проблема - картинка на мониторе будет отставать от логики приложения на сколько-то времени. Потому что после того, как сделан gather, логика приложения продолжает "тикать".
Это будет ощущаться как постоянный лаг(курсора мышки, нажатия на элементы интерфейса, a/v desync, лаги в играх).
Самый простой способ "пофиксить" это - это сделать usleep() на какую-то константу перед началом всей этой процедуры, так, чтобы
(кстати, теперь вы знаете, что делает опция max_render_time в sway, как ее тюнить, и почему она плохо работает)
Одно из правильных решений этой задачи - отдать ее на откуп приложению. Например, делать gather с самого начала кванта в 50ms, и передавать в приложение deadline(скажем, если blend занимает 10ms, то можно передать в качестве deadline now() + 40ms).
Тогда приложение, зная, сколько оно будет рисовать кадр, сможет предпринять нужные действия(например, межкадровую интерполяцию для видеоплеера, или usleep в игре).
Конец рассказа про compositor internals.
Но эти говнюки, конечно, решили сделать по другому - они будут передавать хинты для окна(игра, видео, и так далее), а композитор будет принимать какое-то решение.
И, к гадалке не ходи, GNOME media player будет знать, как работает GNOME compositor(какая там логика), и в GNOME shell оно будет работать прилично, и лагать под другими композиторами.
Phoronix
Wayland Protocols 1.27 Brings Content Type Hinting, Idle Notification
Wayland-Protocols 1.27 was released this morning by Jonas Ådahl in pushing out two new protocols under the staging umbrella.
👍3🤔3🔥2😱1🍌1
#llvmweekly
У нас сегоднярыбный день новостей про LLVM, потому что там случилось много чего интересного.
https://discourse.llvm.org/t/macro-performance-lexer-and-sourcemanager/65713/2
Например, простыня про скорость clang.
TL;DR:
* clang собирает ядро Linux значимо медленнее, чем gcc. Это, наверное, ожидаемо, потому что clang всегда был больше про С++, а gcc, по историческим причинам, про С.
* clang больше времени проводит в самом себе(парсер, семантика, etc), чем в оптимизаторе, и это, конечно, очень неожиданно.
У нас сегодня
https://discourse.llvm.org/t/macro-performance-lexer-and-sourcemanager/65713/2
Например, простыня про скорость clang.
TL;DR:
* clang собирает ядро Linux значимо медленнее, чем gcc. Это, наверное, ожидаемо, потому что clang всегда был больше про С++, а gcc, по историческим причинам, про С.
* clang больше времени проводит в самом себе(парсер, семантика, etc), чем в оптимизаторе, и это, конечно, очень неожиданно.
LLVM Discussion Forums
Macro performance: Lexer and SourceManager
Continuing a thread started on phabricator: https://reviews.llvm.org/D20401, summoning @nickdesaulniers @hokein. Summary so far: SourceManager optimizes to produce compact SourceLocations The tradeoff is getFileID() is relatively expensive, and needed…
👍9🤔4
https://www.phoronix.com/news/LLVM-Clang-15-Benchmarks
А вот бенчмарк кода, собранного clang15 vs clang14.
Примерно 1% в среднем по больнице, что приятно.
Миша с phoronix жалуется, что не как в "старые добрые" времена, когда clang только-только появился, но, блин, отрасль уже "заматерела", все низковисящие фрукты съедены, и никаких прорывов в науке оптимизации не предвидится.
А вот бенчмарк кода, собранного clang15 vs clang14.
Примерно 1% в среднем по больнице, что приятно.
Миша с phoronix жалуется, что не как в "старые добрые" времена, когда clang только-только появился, но, блин, отрасль уже "заматерела", все низковисящие фрукты съедены, и никаких прорывов в науке оптимизации не предвидится.
Phoronix
LLVM Clang 15 Delivers Some Small x86_64 Performance Improvements But Mostly Flat
Released last month was LLVM/Clang 15 and since then a number of Phoronix readers have been inquiring about Clang 15 compiler benchmarks or there the lack of on Phoronix
👍5👌2
commit -m "better"
#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…
https://reviews.llvm.org/rGd5090cd94a8f
Продолжает приземляться поддержка сборки llvm/clang в один большой бинарник, #busybox-style
На первый взгляд, поддержаны все бинарники, которые я использую, а, значит, в clang16 я попробую использовать такой режим.
Ожидаю, что размер пакета с clang упадет в 2 - 3 раза. В перфе роста не ожидаю, потому что 99% времени все равно жрет компиляция, и факт того, что всякие ar/lld/etc будут использовать те же кеши, что и бинарник clang, особой роли играть не будут.
Продолжает приземляться поддержка сборки llvm/clang в один большой бинарник, #busybox-style
На первый взгляд, поддержаны все бинарники, которые я использую, а, значит, в clang16 я попробую использовать такой режим.
Ожидаю, что размер пакета с clang упадет в 2 - 3 раза. В перфе роста не ожидаю, потому что 99% времени все равно жрет компиляция, и факт того, что всякие ar/lld/etc будут использовать те же кеши, что и бинарник clang, особой роли играть не будут.
👍5
И последняя новость из мира LLVM на сегодня.
https://llvmweekly.org/issue/458
"LLVM’s libc gained implementations of fork, rand, srand, waitpid, wait4, execv, execve, kill, strerror_r, and strsignal functions. e3638e8, 38b6f58, 995105d, 3f96581, 9015810, a9f95b7, 07793f9"
Коллеги прямо очень быстро пишут libc от LLVM.
Я осторожно скажу, что не ожидаю ее готовность к концу 2022, но вот в первой половине 23 надеюсь уже "пощупать" (ЕБЖ, конечно).
Лично для меня это самый ожидаемый проект от экосистемы LLVM(после, собственно, самой llvm/clang/lld), потому что, писал и буду писать, авторы что #glibc, что #musl - негодяи с завышенным ЧСВ, и появление еще одного конкурента на этой делянке - это very appropriate.
https://llvmweekly.org/issue/458
"LLVM’s libc gained implementations of fork, rand, srand, waitpid, wait4, execv, execve, kill, strerror_r, and strsignal functions. e3638e8, 38b6f58, 995105d, 3f96581, 9015810, a9f95b7, 07793f9"
Коллеги прямо очень быстро пишут libc от LLVM.
Я осторожно скажу, что не ожидаю ее готовность к концу 2022, но вот в первой половине 23 надеюсь уже "пощупать" (ЕБЖ, конечно).
Лично для меня это самый ожидаемый проект от экосистемы LLVM(после, собственно, самой llvm/clang/lld), потому что, писал и буду писать, авторы что #glibc, что #musl - негодяи с завышенным ЧСВ, и появление еще одного конкурента на этой делянке - это very appropriate.
👍8
https://www.opennet.ru/opennews/art.shtml?num=57909
"Постановление предписывает:
Создание национального репозитория ПО с открытым кодом;
Размещение в репозитории программного обеспечения, созданного, в том числе, за бюджетные средства, для повторного использования в других проектах;
Формирование нормативной базы для публикации ПО с открытым кодом"
Звучит это все интересно, но несколько туманно, не очень понятно, какой софт, в итоге, откроют.
Код госуслуг откроют? Или вот код, который определяет номера оштрофаванных за превышение скорости машин? Или код поиска уклонистов от мобилизации?
UPD: в комментариях предложили назвать это "ГИТЛАГ", звучит хорошо!
"Постановление предписывает:
Создание национального репозитория ПО с открытым кодом;
Размещение в репозитории программного обеспечения, созданного, в том числе, за бюджетные средства, для повторного использования в других проектах;
Формирование нормативной базы для публикации ПО с открытым кодом"
Звучит это все интересно, но несколько туманно, не очень понятно, какой софт, в итоге, откроют.
Код госуслуг откроют? Или вот код, который определяет номера оштрофаванных за превышение скорости машин? Или код поиска уклонистов от мобилизации?
UPD: в комментариях предложили назвать это "ГИТЛАГ", звучит хорошо!
www.opennet.ru
В РФ утверждено создание национального репозитория открытого кода
Правительство РФ приняло постановление "О проведении эксперимента по предоставлению права использования программ для электронных вычислительных машин, алгоритмов, баз данных и документации к ним, в том числе исключительное право на которые принадлежит Российской…
👍7🤡3
https://lwn.net/Articles/910848/
Совершенно прекрасная новость - какой-то патентный тролль собирает патентный пул, чтобы доить пользователей Opus, кодека, специально созданного для того, чтобы быть свободным от разных там патентных претензий.
Насколько я понимаю, кодек - лучший в своем классе, широко ли применяется - не знаю.
Совершенно прекрасная новость - какой-то патентный тролль собирает патентный пул, чтобы доить пользователей Opus, кодека, специально созданного для того, чтобы быть свободным от разных там патентных претензий.
Насколько я понимаю, кодек - лучший в своем классе, широко ли применяется - не знаю.
🤡7🍌3
https://determinate.systems/posts/qemu-fix
https://www.phoronix.com/news/Linux-6.1-Faster-9P
Не хотел писать, но тема просочилась в кучу мест, в том числе, в блог Линуса, и я, конечно, не могу удержаться.
Этот текст - не про то, как "мы все сделали хорошо", а про то, как "все на самом деле плохо".
Плохо, потому что С, потому что использовать контейнеры сложнее, чем односвязный список или массив фиксированного размера - сложно.
Поэтому и возникают вот такие вот высеры, "как я героически добавил куда-то хештаблицу".
Буде qemu и Linux написаны на нормальных языках, где использование контейнеров не доставляет боль, там или с самого начала была бы хеш-таблица, или чувак, заметивший и пофиксивший это не попал бы к Линусу в блог и на главную страницу phoronix.
Плохо, очень плохо, что, из-за использования неподходящего языка, в очень важном для мира проекте столько низковисящих фруктов.
https://www.phoronix.com/news/Linux-6.1-Faster-9P
Не хотел писать, но тема просочилась в кучу мест, в том числе, в блог Линуса, и я, конечно, не могу удержаться.
Этот текст - не про то, как "мы все сделали хорошо", а про то, как "все на самом деле плохо".
Плохо, потому что С, потому что использовать контейнеры сложнее, чем односвязный список или массив фиксированного размера - сложно.
Поэтому и возникают вот такие вот высеры, "как я героически добавил куда-то хештаблицу".
Буде qemu и Linux написаны на нормальных языках, где использование контейнеров не доставляет боль, там или с самого начала была бы хеш-таблица, или чувак, заметивший и пофиксивший это не попал бы к Линусу в блог и на главную страницу phoronix.
Плохо, очень плохо, что, из-за использования неподходящего языка, в очень важном для мира проекте столько низковисящих фруктов.
determinate.systems
Make your QEMU 10 times faster with this one weird trick
NixOS uses virtual machines based on QEMU extensively for running its test
suite. In order to avoid generating a disk image for every test, the test
driver usually boots using a Plan 9 File Protocol (9p) share (server
implemented by QEMU) for the Nix store…
suite. In order to avoid generating a disk image for every test, the test
driver usually boots using a Plan 9 File Protocol (9p) share (server
implemented by QEMU) for the Nix store…
👍5🤯4👎2🔥2🐳2🍌1
https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
https://lwn.net/ml/fedora-devel/CACBV9Zgr_wpM2vkTL=7Mtn+u+8vTHHELfUdnVtavgXhxrwv5dQ@mail.gmail.com/
Федора перестала поддерживать аппаратные кодеки "из коробки".
Я, признаться, не понимаю, зачем эти кодеки вообще нужны, кроме как если вы хотите показывать 4k видео с raspberrypi, но это в любом случае грязное извращение.
Наверное, это имеет смысл во всяких телефонах и планшетах, но не на десктопе.
По мне так все эти аппаратные vdpau/vaapi больше похожи на пузомерку у фанатов Linux - постоянно вижу на всяких форумах срачи про "а у меня не работает va* в firefox/etc", с предложением вправить руки.
Ну и, наверняка же, они дают разный результат у разных вендоров железки, да?
Я собираю #mesa без их поддержки.
https://lwn.net/ml/fedora-devel/CACBV9Zgr_wpM2vkTL=7Mtn+u+8vTHHELfUdnVtavgXhxrwv5dQ@mail.gmail.com/
Федора перестала поддерживать аппаратные кодеки "из коробки".
Я, признаться, не понимаю, зачем эти кодеки вообще нужны, кроме как если вы хотите показывать 4k видео с raspberrypi, но это в любом случае грязное извращение.
Наверное, это имеет смысл во всяких телефонах и планшетах, но не на десктопе.
По мне так все эти аппаратные vdpau/vaapi больше похожи на пузомерку у фанатов Linux - постоянно вижу на всяких форумах срачи про "а у меня не работает va* в firefox/etc", с предложением вправить руки.
Ну и, наверняка же, они дают разный результат у разных вендоров железки, да?
Я собираю #mesa без их поддержки.
👎10👍3🔥1🤔1🍌1
https://osgameclones.com/
Набрел вот на каталог open source клонов древних и не очень игр.
Их там неожиданно много, правда, 90% - нерабочее и заброшенное УГ, но поковыряться в этом интересно.
Набрел вот на каталог open source клонов древних и не очень игр.
Их там неожиданно много, правда, 90% - нерабочее и заброшенное УГ, но поковыряться в этом интересно.
Osgameclones
Open Source Game Clones
List of open source clones and remakes of popular old-school games.
🤩5🔥4🐳4🍌1
Тут вот у меня(шутка, хе-хе) взяли интервью, https://onebite.dev/a-fake-conversation-between-the-best-programmer-in-the-world-with-a-junior/, но там осталась нераскрытой тема code review, решил ее раскрыть. #gold
Про code review есть много заблуждений:
* "CR нужен, чтобы искать баги". Нет, он нужен не для этого. За все мои несчетные CR найденные баги можно пересчитать по пальцам рук. Баги ищут тесты, прогоны с фаззерами, санитайзерами, в тестовой и canary средах, и так далее.
* "CR нужен, чтобы на выходе был лучший возможный код". У всех ревьюеров свои представления о прекрасном. Если вы на CR занимаетесь тем, что навязываете их кому-то, то в этом нет ничего хорошего. На выходе у вас все равно будет код, не дотягивающий до высоких стандартов, но все участники будут сильно недовольны процессом. А на следующем CR тот, кого ты заставил переписывать свой код, заставит переписать твой. Наверняка у вас в окрестности есть ревьюер, который заставляет переписывать вызов usleep() на вызов std::chrono? Обращусь к таким ревьюерам - поумерьте свой пыл. Код не становится объективно лучше, он просто больше удовлетворяет ваше чувство прекрасного(про него ниже). (С точки зрения best programmer in the world - один человек все равно не может написать весь код во всем мире, поэтому бОльшую часть времени придется иметь дело с говнокодом, и тут ничего не поделать)
* "CR нужен, чтобы разобраться и пофиксить ошибки дизайна системы, ее архитектуры". "А давай ты мне расскажешь, что тут происходит, а я тебе расскажу, как все переделать". В корне неверное представление. Если вы на CR начали обсуждать дизайн, то у вас неверно построена постановка задач. Архитектуру надо обсуждать ДО того, как получена первая итерация кода, а не после.
А зачем тогда нужен CR?
* Для общения людей. Чтобы упыри, которые пишут код в своих подвалах, иногда вылезали на свет, и разговаривали про систему, которую они совместно пишут.
* Важная тема. CR позволяет получить бумагу с печатью, что я не приду и не откоммичу твой коммит, если ты его сделал без CR. Согласие есть полное непротивление сторон. (если есть уверенность, что принимающая сторона не откатит PR, то можно и без ревью, для экономии времени)
* Выравнивание привычек кодирования в команде, чтобы чужой код в проекте ты мог читать примерно так же легко, как свой.
Как делать хорошие ревью?
* На ревью проверяем только формально верифицируемые и записанные договоренности. Лучше всего, конечно, когда они формализованы настолько, что их может проверить скрипт. Тогда нам остается только проверить зеленые галки, и нажать "ship it".
* Перед ревью умножаем свое чувство прекрасного на 0. Не тешим ЧСВ, придумывая новые и новые проблемы в коде, и отправляя на следующие итерации. Ревью - не экзамен, когда надо найти дыры в знаниях, а разговор равных.
* плохой naming - последнее пристанище негодяя. В том смысле, что никогда не докапываемся до названий, потому что, очевидно, идеальный naming у всех будет разный. А в некоторых VCS поменять путь к файлу в рамках одного PR - боль.
* Стремимся уменьшать число итераций ревью. Я, например, часто пишу так "мне все ОК, но перед коммитом поправь пару мелочей и сделай себе ship it сам на новую итерацию". Дополнительные итерации - это просто потраченное зря время нескольких человек, и машинного времени на проверку. И вы все равно не получите свой "идеальный код", его не бывает.
Идеальное ревью:
* Занимает ровно одну итерацию. Посмотрел на код, на зеленые галки, прикрыл глаза, зажал нос, нажал "ship it". Если часто приходится писать комментарии и отправлять на следующую итерацию - или вы включили свое чувство прекрасного, или у вас слишком мало формализовано правил, которые нужно соблюдать на ревью. Не поленитесь, формализуйте.
Да, в этом тексте я описал CR "от равных равному". Если это CR нубского кода(стажер, джун, и так далее), то CR - это часть обучения, и оно должно быть устроено не так.
Про code review есть много заблуждений:
* "CR нужен, чтобы искать баги". Нет, он нужен не для этого. За все мои несчетные CR найденные баги можно пересчитать по пальцам рук. Баги ищут тесты, прогоны с фаззерами, санитайзерами, в тестовой и canary средах, и так далее.
* "CR нужен, чтобы на выходе был лучший возможный код". У всех ревьюеров свои представления о прекрасном. Если вы на CR занимаетесь тем, что навязываете их кому-то, то в этом нет ничего хорошего. На выходе у вас все равно будет код, не дотягивающий до высоких стандартов, но все участники будут сильно недовольны процессом. А на следующем CR тот, кого ты заставил переписывать свой код, заставит переписать твой. Наверняка у вас в окрестности есть ревьюер, который заставляет переписывать вызов usleep() на вызов std::chrono? Обращусь к таким ревьюерам - поумерьте свой пыл. Код не становится объективно лучше, он просто больше удовлетворяет ваше чувство прекрасного(про него ниже). (С точки зрения best programmer in the world - один человек все равно не может написать весь код во всем мире, поэтому бОльшую часть времени придется иметь дело с говнокодом, и тут ничего не поделать)
* "CR нужен, чтобы разобраться и пофиксить ошибки дизайна системы, ее архитектуры". "А давай ты мне расскажешь, что тут происходит, а я тебе расскажу, как все переделать". В корне неверное представление. Если вы на CR начали обсуждать дизайн, то у вас неверно построена постановка задач. Архитектуру надо обсуждать ДО того, как получена первая итерация кода, а не после.
А зачем тогда нужен CR?
* Для общения людей. Чтобы упыри, которые пишут код в своих подвалах, иногда вылезали на свет, и разговаривали про систему, которую они совместно пишут.
* Важная тема. CR позволяет получить бумагу с печатью, что я не приду и не откоммичу твой коммит, если ты его сделал без CR. Согласие есть полное непротивление сторон. (если есть уверенность, что принимающая сторона не откатит PR, то можно и без ревью, для экономии времени)
* Выравнивание привычек кодирования в команде, чтобы чужой код в проекте ты мог читать примерно так же легко, как свой.
Как делать хорошие ревью?
* На ревью проверяем только формально верифицируемые и записанные договоренности. Лучше всего, конечно, когда они формализованы настолько, что их может проверить скрипт. Тогда нам остается только проверить зеленые галки, и нажать "ship it".
* Перед ревью умножаем свое чувство прекрасного на 0. Не тешим ЧСВ, придумывая новые и новые проблемы в коде, и отправляя на следующие итерации. Ревью - не экзамен, когда надо найти дыры в знаниях, а разговор равных.
* плохой naming - последнее пристанище негодяя. В том смысле, что никогда не докапываемся до названий, потому что, очевидно, идеальный naming у всех будет разный. А в некоторых VCS поменять путь к файлу в рамках одного PR - боль.
* Стремимся уменьшать число итераций ревью. Я, например, часто пишу так "мне все ОК, но перед коммитом поправь пару мелочей и сделай себе ship it сам на новую итерацию". Дополнительные итерации - это просто потраченное зря время нескольких человек, и машинного времени на проверку. И вы все равно не получите свой "идеальный код", его не бывает.
Идеальное ревью:
* Занимает ровно одну итерацию. Посмотрел на код, на зеленые галки, прикрыл глаза, зажал нос, нажал "ship it". Если часто приходится писать комментарии и отправлять на следующую итерацию - или вы включили свое чувство прекрасного, или у вас слишком мало формализовано правил, которые нужно соблюдать на ревью. Не поленитесь, формализуйте.
Да, в этом тексте я описал CR "от равных равному". Если это CR нубского кода(стажер, джун, и так далее), то CR - это часть обучения, и оно должно быть устроено не так.
onebite.dev
A (fake) conversation between the best programmer in the world with a junior
This is a fake conversation between the best programmer in the world with a junior generated with Artificial intelligence (AI)
👍26❤4🔥3👎1🍌1