Про scheduler в Linux. #sched #gold
Я знал, что шедулер в Linux хуйовый(мат intended), но что на десктопе все сломано настолько, я не понимал. У меня во время компиляции тормозит браузер(любой). И я ничего не смог с этим сделать.
Вот команда запуска компиляции(IO я не трогаю, все в памяти):
chrt --idle 0 cpulimit -l 1400 -i nice -n 20 ./mix realm upgrade
Я ограничиваю число ядер для компиляции(14 из 16), я выставляю nice, я помечаю треды на idle, чтобы они вытеснялись любым более приоритетным кодом.
Команда запуска браузера примерно такая же, только - заменяем на +, —idle на —rr, etc. Команда запуска композитора тоже(все, что затрагивает user facing процессы, запущено с повышенными scheduling privileges).
И это не помогает. На минуточку, я для браузера оставил полноценное ядро(2 гипертреда), у меня число процессов в очереди на выполнение < CPU CORES, и все равно, шедулер как-то умудряется просрать(сука! ненавижу!) все полимеры. Почему так? Я вам расскажу!
Первое соображение - про процессы разработки.
Я уже много раз рассказывал, ядро Linux пишут красноглазые хакеры. Без нормального процесса разработки, тикетов, тестов, etc. Код соответствующего качества. Как нормальный разраб бы оформил шедулер? А вот так:
В ядре Linux это лапша без четкого интерфейса, что на входе, что на выходе, с кучей side effect по всему ядру, с доступом по всему ядру, полной невозможностью написать эмулятор и тесты.
Есть, типа, описание, как должен работать шедулер:
https://en.wikipedia.org/wiki/Completely_Fair_Scheduler
https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/
Господа, да если бы он работал по этому алгоритму, было бы счастье! Этот алгоритм by design не допускает лаги, когда у меня число выполняющихся процессов < CPU CORES! Так он уже давно по нему не работает.
Все люди, которых я знал, которые патчили шедулер, делали это примерно так - засучивали рукава, добавляли какую-то совершенно безумную ручку, которая позволяла снаружи крутить какой-то неочевидный параметр, а потом 5 лет внедряли это в mainline.
Шедулер в Linux пишут крупные корпорации - операторы облаков, или разработчики гипервизоров, вот по алгоритму, который я описал выше. Поэтому шедулер в Linux - это 100500 несвязанных(и конфликтующих! между собой) ручек, которые никто не умеет нормально крутить. Стройность CFS там уже давно и рядом не стояла.
Кстати, Con Kolivas отказался от идеи запилить нормальный scheduler для Linux. https://www.phoronix.com/scan.php?page=news_item&px=Con-Kolivas-EOL-MuQSS-CK Я бы, на его месте, послал всю эту пиздобратию еще раньше, когда Ingo Molnar, вместо того, чтобы признать, что Con лучше справился с работой, просто потырил его идеи в свою реализацию.
Второе соображение - пошедулить браузер существенно сложнее, чем пошедулить Apache. Прямо на порядок сложнее. Когда ты шедулишь Apache, тебе пофиг, что ты там где-то просрал квант времени. Когда ты шедулишь браузер, тебе надо выдавать стабильный RPS в 120, и просер одного кванта времени заметен. Тебе нужно реализовывать сложные алгоритмы, что, если ты отпустил lock, то твой квант времени доедает тот, кто этот lock получит(то же самое про запись в pipe). Почему это важно? Потому что тебе нужно, чтобы композитор моментально начал свою работу после того, как ты ему просигнализировал, что твой буфер с окном готов.
Под что тюнят облачные корпорации Linux scheduler? Вопрос риторический.
Итак.
* Шедулер в Linux сломан давно и навсегда(для десктопа, да и для серверов, если вы не большая корпорация со штатом крутильщиков ручек)
* Лучше всего(для десктопа) он работал в 2006 - 2008 году, пока его разработчики тюнили его под свои же workstation. Вот тогда реально все было плавненько.
* Чего там ищет Valve для гейминга в Linux - я не понимаю. https://www.opennet.ru/opennews/art.shtml?num=56390
Я знал, что шедулер в Linux хуйовый(мат intended), но что на десктопе все сломано настолько, я не понимал. У меня во время компиляции тормозит браузер(любой). И я ничего не смог с этим сделать.
Вот команда запуска компиляции(IO я не трогаю, все в памяти):
chrt --idle 0 cpulimit -l 1400 -i nice -n 20 ./mix realm upgrade
Я ограничиваю число ядер для компиляции(14 из 16), я выставляю nice, я помечаю треды на idle, чтобы они вытеснялись любым более приоритетным кодом.
Команда запуска браузера примерно такая же, только - заменяем на +, —idle на —rr, etc. Команда запуска композитора тоже(все, что затрагивает user facing процессы, запущено с повышенными scheduling privileges).
И это не помогает. На минуточку, я для браузера оставил полноценное ядро(2 гипертреда), у меня число процессов в очереди на выполнение < CPU CORES, и все равно, шедулер как-то умудряется просрать(сука! ненавижу!) все полимеры. Почему так? Я вам расскажу!
Первое соображение - про процессы разработки.
Я уже много раз рассказывал, ядро Linux пишут красноглазые хакеры. Без нормального процесса разработки, тикетов, тестов, etc. Код соответствующего качества. Как нормальный разраб бы оформил шедулер? А вот так:
IScheduler* scheduler = new WorkStealingScheduler(Отметим наличие интерфейсов, чтобы можно было мокать тесты, инкапсуляцию(шедулер имеет доступ только к тем частям ядра, что ему явно передали), etc.
some kernel interfaces)...
...
auto job = sheduler->nextWorkItem();
В ядре Linux это лапша без четкого интерфейса, что на входе, что на выходе, с кучей side effect по всему ядру, с доступом по всему ядру, полной невозможностью написать эмулятор и тесты.
Есть, типа, описание, как должен работать шедулер:
https://en.wikipedia.org/wiki/Completely_Fair_Scheduler
https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/
Господа, да если бы он работал по этому алгоритму, было бы счастье! Этот алгоритм by design не допускает лаги, когда у меня число выполняющихся процессов < CPU CORES! Так он уже давно по нему не работает.
Все люди, которых я знал, которые патчили шедулер, делали это примерно так - засучивали рукава, добавляли какую-то совершенно безумную ручку, которая позволяла снаружи крутить какой-то неочевидный параметр, а потом 5 лет внедряли это в mainline.
Шедулер в Linux пишут крупные корпорации - операторы облаков, или разработчики гипервизоров, вот по алгоритму, который я описал выше. Поэтому шедулер в Linux - это 100500 несвязанных(и конфликтующих! между собой) ручек, которые никто не умеет нормально крутить. Стройность CFS там уже давно и рядом не стояла.
Кстати, Con Kolivas отказался от идеи запилить нормальный scheduler для Linux. https://www.phoronix.com/scan.php?page=news_item&px=Con-Kolivas-EOL-MuQSS-CK Я бы, на его месте, послал всю эту пиздобратию еще раньше, когда Ingo Molnar, вместо того, чтобы признать, что Con лучше справился с работой, просто потырил его идеи в свою реализацию.
Второе соображение - пошедулить браузер существенно сложнее, чем пошедулить Apache. Прямо на порядок сложнее. Когда ты шедулишь Apache, тебе пофиг, что ты там где-то просрал квант времени. Когда ты шедулишь браузер, тебе надо выдавать стабильный RPS в 120, и просер одного кванта времени заметен. Тебе нужно реализовывать сложные алгоритмы, что, если ты отпустил lock, то твой квант времени доедает тот, кто этот lock получит(то же самое про запись в pipe). Почему это важно? Потому что тебе нужно, чтобы композитор моментально начал свою работу после того, как ты ему просигнализировал, что твой буфер с окном готов.
Под что тюнят облачные корпорации Linux scheduler? Вопрос риторический.
Итак.
* Шедулер в Linux сломан давно и навсегда(для десктопа, да и для серверов, если вы не большая корпорация со штатом крутильщиков ручек)
* Лучше всего(для десктопа) он работал в 2006 - 2008 году, пока его разработчики тюнили его под свои же workstation. Вот тогда реально все было плавненько.
* Чего там ищет Valve для гейминга в Linux - я не понимаю. https://www.opennet.ru/opennews/art.shtml?num=56390
👍5
https://www.phoronix.com/scan.php?page=news_item&px=Sway-1.7-rc1
Вышел новый rc Sway. Самое заметное нововведение - больше не нужно указывать для ./configure —my-next-gpu-wont-be-nvidia
По нынешним меркам хорошо, что не заставили извиняться(только вот кого, Sway или Nvidia?)
А чо, у меня вот шаблон для gnu-тых проектов называется autohell.sh, чего уж тут.
———
https://github.com/endrazine/wcc
Неделя линкера продолжается(я думаю, самые сообразительные мои читатели уже поняли, что в конце этой недели я просто расскажу, как линкер, собственно, работает, и не отговаривайте меня)!
Прекрасная, прекрасная вещь. Позволяет превратить .exe в .so, .so в .o, ну а то, что можно с помощью lua превратить любой .exe в shell с возможностью вызова любой функции - я уж вообще молчу.
Полагаю, мне это будет полезно, когда я захочу статически слинковаться с NVidia libGL.so
———
https://systemfolder.wordpress.com/2015/01/17/about-box/
А вот коллекция splash screen всякого старого софта. Prehistoric porn, все, как мы любим.
———
В свете поста про scheduler #sched нам пишут телезрители - оказывается, большие компании проблему понимают, и пытаются ее решить. Шедулер в user space - это прекрасно, у меня просто полно идей, как можно сделать хорошо.
https://lwn.net/Articles/869433/
https://dl.acm.org/doi/10.1145/3477132.3483542
———
Ну и выжимка текста про "починку" одного бага в шедулере(ссылка в прошлом сообщении, https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/):
"The original rationale for the behaviour was to maximise cache reuse – but for some applications waiting in the runqueue for the sake of better cache reuse does not pay off. The bug was triggered by a widely used commercial database configured with 64 worker threads.
To fix this bug, we alter the code that is executed when a thread wakes up. We wake up the thread on the local core – i.e. the core where the thread was scheduled last – if it is idle; otherwise if there are idle cores in the system, we wake up the thread on the core that has been idle for the longest amount of time. If there are no idle cores, we fall back to the original algorithm to find the core where the thread will wake up."
Вдумчивый читатель обнаружит, что починка добавляет еще 1 баг. Надо не longest amount, а shortest amount, потому что иначе возможна ситуация, когда будет 10 медленных ядер(напомним про тротлинг CPU) вместо 5 быстрых. Впрочем, возможно, нужно именно longest amount, просто я не понимаю, почему.
Вышел новый rc Sway. Самое заметное нововведение - больше не нужно указывать для ./configure —my-next-gpu-wont-be-nvidia
По нынешним меркам хорошо, что не заставили извиняться(только вот кого, Sway или Nvidia?)
А чо, у меня вот шаблон для gnu-тых проектов называется autohell.sh, чего уж тут.
———
https://github.com/endrazine/wcc
Неделя линкера продолжается(я думаю, самые сообразительные мои читатели уже поняли, что в конце этой недели я просто расскажу, как линкер, собственно, работает, и не отговаривайте меня)!
Прекрасная, прекрасная вещь. Позволяет превратить .exe в .so, .so в .o, ну а то, что можно с помощью lua превратить любой .exe в shell с возможностью вызова любой функции - я уж вообще молчу.
Полагаю, мне это будет полезно, когда я захочу статически слинковаться с NVidia libGL.so
———
https://systemfolder.wordpress.com/2015/01/17/about-box/
А вот коллекция splash screen всякого старого софта. Prehistoric porn, все, как мы любим.
———
В свете поста про scheduler #sched нам пишут телезрители - оказывается, большие компании проблему понимают, и пытаются ее решить. Шедулер в user space - это прекрасно, у меня просто полно идей, как можно сделать хорошо.
https://lwn.net/Articles/869433/
https://dl.acm.org/doi/10.1145/3477132.3483542
———
Ну и выжимка текста про "починку" одного бага в шедулере(ссылка в прошлом сообщении, https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/):
"The original rationale for the behaviour was to maximise cache reuse – but for some applications waiting in the runqueue for the sake of better cache reuse does not pay off. The bug was triggered by a widely used commercial database configured with 64 worker threads.
To fix this bug, we alter the code that is executed when a thread wakes up. We wake up the thread on the local core – i.e. the core where the thread was scheduled last – if it is idle; otherwise if there are idle cores in the system, we wake up the thread on the core that has been idle for the longest amount of time. If there are no idle cores, we fall back to the original algorithm to find the core where the thread will wake up."
Вдумчивый читатель обнаружит, что починка добавляет еще 1 баг. Надо не longest amount, а shortest amount, потому что иначе возможна ситуация, когда будет 10 медленных ядер(напомним про тротлинг CPU) вместо 5 быстрых. Впрочем, возможно, нужно именно longest amount, просто я не понимаю, почему.
Phoronix
Sway 1.7-rc1 Has Better Zero-Copy Direct Scanout, Drops "--my-next-gpu-wont-be-nvidia"
The first release candidate of the Sway 1.7 Wayland compositor is now available for testing.
https://pythoninsider.blogspot.com/2021/12/python-3110a3-is-available.html
Пишут, что Python 3.11 уже на 20% быстрее, чем 3.10. Не знаю, у меня, кажется, медленнее, будет время - проведу пару тестов.
———
https://habr.com/ru/post/596193/
Если убрать оригинальное исследование автора текста, то прямо очень годный текст про разные архитектуры процессоров, я даже узнал что-то новое. Пример отличного Хабра.
———
https://www.brian.jp/2021/12/24/exiled-from-the-metaverse-before-it-even-started-the-dangers-of-relying-on-facebook/
Писал, пишу, и буду писать, что это(отключение от услуги) не должно быть в компетенции провайдера услуги. #law #provider #yeswecan
———
https://lwn.net/Articles/879739/
Вышел юбилейный systemd.
https://www.opennet.ru/opennews/art.shtml?num=56393
И не столь юбилейный s6.
Из этих двух, я, конечно, выбрал бы s6, а так - ни тот, ни другой.
Я еще сильно не думал про систему инициализации в MixOS, мне, если честно, пофиг, или, как сейчас модно говорить, unopinionated. Скорее всего, это будет божественный runit, потому что он реализует ровно ту модель запуска сервисов, которую я считаю правильной.
Про #systemd:
* Он слишком сложный. Если я бы хотел не знать, как работает моя система, я бы взял систему с launchd, если вы понимаете, о чем я.
* Он слишком всеобъемлющий. Я не верю, что такой комбайн может работать хорошо, и это, простите, не unix-way. Я предпочту набор хорошо сопрягаемых независимых компонент(в каждом из которых можно разобраться по отдельности).
* Он не решает ни одной моей задачи. В облаках сервисами управляет, условно говоря, снаружи K*, внутри или ничего, или что-то очень простое, типа runit. На десктопе модель systemd слишком сложна. Redhat, скорее всего, пилит systemd для отдельно стоящего сервера с apache/mysql/1c, ну так я не целевая аудитория.
* Мне никто так и не сумел ответить, как systemd должен поднять систему, в которой написано, что B поднимается после A, и должен работать только если работает А, но A находится в состоянии "10 секунд работает, 10 секунд упал".
Я считаю, что зависимости в системе управления локальными сервисами - зло. Управлялка должна оперировать bag of services, и просто пытаться поднять их все, возможно, с exponential backoff(потому что сервисы, в момент запуска, часто жрут больше CPU, чем в процессе работы).
Если вы пытаетесь перенести часть логики по обеспечению надежности своего сервиса в systemd("апач не должен отвечать на запросы, если не поднят mysql"), то вы попали, и мне даже лень подробно объяснять, почему.
Собственно, поэтому это и будет runit, возможно, с несколькими кастомными скриптами(для обеспечения exponential backoff, для управления cgroup, etc).
Пишут, что Python 3.11 уже на 20% быстрее, чем 3.10. Не знаю, у меня, кажется, медленнее, будет время - проведу пару тестов.
———
https://habr.com/ru/post/596193/
Если убрать оригинальное исследование автора текста, то прямо очень годный текст про разные архитектуры процессоров, я даже узнал что-то новое. Пример отличного Хабра.
———
https://www.brian.jp/2021/12/24/exiled-from-the-metaverse-before-it-even-started-the-dangers-of-relying-on-facebook/
Писал, пишу, и буду писать, что это(отключение от услуги) не должно быть в компетенции провайдера услуги. #law #provider #yeswecan
———
https://lwn.net/Articles/879739/
Вышел юбилейный systemd.
https://www.opennet.ru/opennews/art.shtml?num=56393
И не столь юбилейный s6.
Из этих двух, я, конечно, выбрал бы s6, а так - ни тот, ни другой.
Я еще сильно не думал про систему инициализации в MixOS, мне, если честно, пофиг, или, как сейчас модно говорить, unopinionated. Скорее всего, это будет божественный runit, потому что он реализует ровно ту модель запуска сервисов, которую я считаю правильной.
Про #systemd:
* Он слишком сложный. Если я бы хотел не знать, как работает моя система, я бы взял систему с launchd, если вы понимаете, о чем я.
* Он слишком всеобъемлющий. Я не верю, что такой комбайн может работать хорошо, и это, простите, не unix-way. Я предпочту набор хорошо сопрягаемых независимых компонент(в каждом из которых можно разобраться по отдельности).
* Он не решает ни одной моей задачи. В облаках сервисами управляет, условно говоря, снаружи K*, внутри или ничего, или что-то очень простое, типа runit. На десктопе модель systemd слишком сложна. Redhat, скорее всего, пилит systemd для отдельно стоящего сервера с apache/mysql/1c, ну так я не целевая аудитория.
* Мне никто так и не сумел ответить, как systemd должен поднять систему, в которой написано, что B поднимается после A, и должен работать только если работает А, но A находится в состоянии "10 секунд работает, 10 секунд упал".
Я считаю, что зависимости в системе управления локальными сервисами - зло. Управлялка должна оперировать bag of services, и просто пытаться поднять их все, возможно, с exponential backoff(потому что сервисы, в момент запуска, часто жрут больше CPU, чем в процессе работы).
Если вы пытаетесь перенести часть логики по обеспечению надежности своего сервиса в systemd("апач не должен отвечать на запросы, если не поднят mysql"), то вы попали, и мне даже лень подробно объяснять, почему.
Собственно, поэтому это и будет runit, возможно, с несколькими кастомными скриптами(для обеспечения exponential backoff, для управления cgroup, etc).
Blogspot
Python Insider: Python 3.11.0a3 is available
commit -m "better"
https://pythoninsider.blogspot.com/2021/12/python-3110a3-is-available.html Пишут, что Python 3.11 уже на 20% быстрее, чем 3.10. Не знаю, у меня, кажется, медленнее, будет время - проведу пару тестов. ——— https://habr.com/ru/post/596193/ Если убрать оригинальное…
А, совсем забыл, за что глаз зацепился-то в релизе #systemd:
"Для долго запускаемых или останавливаемых unit-ов в дополнение к показу анимированного индикатора выполнения операции предоставлена возможность вывода сведений о состоянии, позволяющих понять, что именно происходит с сервисом в данный момент и завершения выполнения какого сервиса ожидает в данный момент системный менеджер."
То есть, "анимированный индикатор" запилили раньше, чем вывод сведений о состоянии. Такие дела.
"Для долго запускаемых или останавливаемых unit-ов в дополнение к показу анимированного индикатора выполнения операции предоставлена возможность вывода сведений о состоянии, позволяющих понять, что именно происходит с сервисом в данный момент и завершения выполнения какого сервиса ожидает в данный момент системный менеджер."
То есть, "анимированный индикатор" запилили раньше, чем вывод сведений о состоянии. Такие дела.
Небольшое продолжение про #systemd, конкретно, про #udev(который какого-то хера стал частью systemd).
https://github.com/illiliti/libudev-zero
"Another udev problem is non-portable home-grown language called "udev rules". Udev authors definitely don't know(or care) why it's better to avoid reinventing the wheel. Strictly speaking, I think they did that on purpose to overcomplicate udev as much as possible. Why? So that only authors(RedHat/IBM) can rule and dictate the future of udev. The recent eudev death only proves that it's really hard to support such unmaintainable mess."
Забавно, но я пришел к таким же выводам, весь этот ваш systemd - это классический vendor lock-in, со стороны IBM/RedHat.
———
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154371.html #loongson
В #LLVM приземляют поддержку loongarch. Это ОЧЕНЬ странно. LLVM, на моей памяти, отказали почти ВСЕМ, в их желании поддержать новую архитектуру в LLVM. Их позиция - лучше меньше, но лучше. Почему этот принцип не сработал в данном случае, и кому занесли китайские товарищи(или на кого собрали компромат, хотя какой в современном западном обществе возможен компромат, когда все можно и все, что можно, - хорошо)?
———
https://justine.lol/sectorlisp2/
Lisp, на этот раз с GC, за 436 байта.
Еще ссылок от #Justine:
https://justinetunney.com/dox/unicode.html
https://justinetunney.com/endian.html
Хотел на ее примере написать что-то типа "вот есть же нормальные тетки-программисты, и без всяких этих ваших SJW-конференций https://www.youtube.com/watch?v=xOmQFBirbOg", а потом передумал.
https://github.com/illiliti/libudev-zero
"Another udev problem is non-portable home-grown language called "udev rules". Udev authors definitely don't know(or care) why it's better to avoid reinventing the wheel. Strictly speaking, I think they did that on purpose to overcomplicate udev as much as possible. Why? So that only authors(RedHat/IBM) can rule and dictate the future of udev. The recent eudev death only proves that it's really hard to support such unmaintainable mess."
Забавно, но я пришел к таким же выводам, весь этот ваш systemd - это классический vendor lock-in, со стороны IBM/RedHat.
———
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154371.html #loongson
В #LLVM приземляют поддержку loongarch. Это ОЧЕНЬ странно. LLVM, на моей памяти, отказали почти ВСЕМ, в их желании поддержать новую архитектуру в LLVM. Их позиция - лучше меньше, но лучше. Почему этот принцип не сработал в данном случае, и кому занесли китайские товарищи(или на кого собрали компромат, хотя какой в современном западном обществе возможен компромат, когда все можно и все, что можно, - хорошо)?
———
https://justine.lol/sectorlisp2/
Lisp, на этот раз с GC, за 436 байта.
Еще ссылок от #Justine:
https://justinetunney.com/dox/unicode.html
https://justinetunney.com/endian.html
Хотел на ее примере написать что-то типа "вот есть же нормальные тетки-программисты, и без всяких этих ваших SJW-конференций https://www.youtube.com/watch?v=xOmQFBirbOg", а потом передумал.
GitHub
GitHub - illiliti/libudev-zero: Daemonless replacement for libudev
Daemonless replacement for libudev. Contribute to illiliti/libudev-zero development by creating an account on GitHub.
https://hellosystem.github.io/docs/developer/application-bundles.html#making-an-application-load-privately-bundled-libraries
Я тут решил посмотреть, как в helloSystem(писал про нее недавно) сделали поддержку бандлов. Свое исследование я прекратил вот на этом замечательном сниппете текста:
If an application is supposed to load privately bundled libraries, one must patch it so that it loads privately bundled libraries from a path relative to itself ($ORIGIN) rather than from /usr/local/lib:
Всегда было интересно, что у таких людей творится в голове.
———
Мне кажется, что, в последнее время, я вижу по 2 новости в день, что вышло обновление того или иного ответвления от Ubuntu/Debian.
За вчера:
https://www.opennet.ru/opennews/art.shtml?num=56413
https://www.opennet.ru/opennews/art.shtml?num=56415
https://www.opennet.ru/opennews/art.shtml?num=56414
Мне интересно, неужели вот это вот все находит своего пользователя, и зачем это кому-то может быть надо?
И отдельно вопрос про https://www.opennet.ru/opennews/art.shtml?num=56414
Товарищи пишут, что их GUI адаптируется к планшетам и телефонам. Мне интересно, доживу ли я до момента, когда размеры элементов в gui будут указываться в сантиметрах, а не пикселях?
20 лет этого жду, нет, серьезно.
———
https://marc.info/?l=git&m=124111702609723&w=2
Недавно писал про то, что JGit не умеет делать bitwise identical tgz со снепшотами кода.
Пока грепал интернеты про это, наткнулся на эту заметку. Как обычно, коллеги излагают свои идеи, почему БЫ оно могло БЫ быть медленнее, а не результаты прямых измерений.
Я тут решил посмотреть, как в helloSystem(писал про нее недавно) сделали поддержку бандлов. Свое исследование я прекратил вот на этом замечательном сниппете текста:
If an application is supposed to load privately bundled libraries, one must patch it so that it loads privately bundled libraries from a path relative to itself ($ORIGIN) rather than from /usr/local/lib:
sed -i -e 's|/usr/local/lib|$ORIGIN/../lib|g' usr/local/bin/falkonThis works because by coincidence the string /usr/local/lib has the exact same length as $ORIGIN/../lib. If this was not the case, one would need to either specify the rpath at compilation time, or use a tool such as patchelf.
ln -s usr/local/lib .
rm usr/local/bin/falkon-e
Всегда было интересно, что у таких людей творится в голове.
———
Мне кажется, что, в последнее время, я вижу по 2 новости в день, что вышло обновление того или иного ответвления от Ubuntu/Debian.
За вчера:
https://www.opennet.ru/opennews/art.shtml?num=56413
https://www.opennet.ru/opennews/art.shtml?num=56415
https://www.opennet.ru/opennews/art.shtml?num=56414
Мне интересно, неужели вот это вот все находит своего пользователя, и зачем это кому-то может быть надо?
И отдельно вопрос про https://www.opennet.ru/opennews/art.shtml?num=56414
Товарищи пишут, что их GUI адаптируется к планшетам и телефонам. Мне интересно, доживу ли я до момента, когда размеры элементов в gui будут указываться в сантиметрах, а не пикселях?
20 лет этого жду, нет, серьезно.
———
https://marc.info/?l=git&m=124111702609723&w=2
Недавно писал про то, что JGit не умеет делать bitwise identical tgz со снепшотами кода.
Пока грепал интернеты про это, наткнулся на эту заметку. Как обычно, коллеги излагают свои идеи, почему БЫ оно могло БЫ быть медленнее, а не результаты прямых измерений.
www.opennet.ru
Представлено новое открытое пользовательское окружение Maui Shell
Разработчики дистрибутива Nitrux, предлагающего собственный рабочий стол NX Desktop, объявили о создании нового пользовательского окружения Maui Shell, которое может применяться на настольных системах, мобильных устройствах и планшетах, автоматически адаптируясь…
🔥1
https://www.opennet.ru/opennews/art.shtml?num=56416
Вышла новая версия busybox. Почему-то очень часто, рядом с информацией про релиз busybox, пишут вот такую ересь:
"В то же время автор BusyBox всячески возражает против такой защиты - считая что она ломает ему бизнес."
Брюс Перенс, конечно, является автором закрывающих скобочек в коде, но вообще, он склочный мудак:
https://lists.busybox.net/pipermail/busybox/2006-September/058617.html
Это переписка тогдашнего мейнтейнера Busybox(он, после этого, стал автором Toybox), с Брюсом.
Мейнтейнер, конечно, тогда тоже был не прав, потому что удалил авторство Брюса вот над этими "закрывающими скобочками", но Брюс, конечно, очень плохой человек - он настаивает на том, что он является автором busybox, даже если там не осталось его кода. Очень интересная идея, конечно.
GNU, кстати, согласно с такой трактовкой - один раз автор - всегда автор. Поэтому GNU/Linux, даже если кода GNU у тебя сейчас уже нет(не верите? А попробуйте собрать какую-нибудь #autohell приблуду с gnu triplet, содержащим linux, но не содержащим gnu).
Зачем издания форсят этот унылый мем, что "автору busybox" там кто-то мешает вести бизнес, я не понимаю. Он уже давно не автор.
———
Busybox или Toybox?
Мне, конечно, ближе идея toybox(https://www.landley.net/toybox/faq.html#why_toybox).
Я не верю в деньги или славу от OSS, это примерно как рассчитывать на деньги и славу от профессионального спорта - ну вот сколько вы знаете известных программистов? 100? 1000? Наверное, примерно столько же, сколько и спортсменов.
Я верю в патчи и фидбек от OSS, а они достигаются широтой использования твоего кода. Даже если кто-то решит закрыть твой код, патчи ему будет выгоднее держать в upstream.
Поэтому toybox почти в каждом телефоне, а busybox на рутерах, и его оттуда постоянно выпиливают, потому что разработчики - склочные #GPL задроты.
Ну и на закуску - busybox про #systemd. https://busybox.net/kill_it_with_fire.txt
———
https://reviews.llvm.org/rG37e6bd8bc8da
К НГ новости совсем закончились, вот, llvm weekly предлагает, в качестве новости, вот такой вот коммит про очередной scope guard.
———
Пишут, что Линусу сегодня 52. Это, конечно, очень важно, и вот вам ссылка на запись одного из его самых первых выступлений на конференциях. Я не слушал, не фанат. https://www.facebook.com/maddoghall/posts/10159125354012025
Вышла новая версия busybox. Почему-то очень часто, рядом с информацией про релиз busybox, пишут вот такую ересь:
"В то же время автор BusyBox всячески возражает против такой защиты - считая что она ломает ему бизнес."
Брюс Перенс, конечно, является автором закрывающих скобочек в коде, но вообще, он склочный мудак:
https://lists.busybox.net/pipermail/busybox/2006-September/058617.html
Это переписка тогдашнего мейнтейнера Busybox(он, после этого, стал автором Toybox), с Брюсом.
Мейнтейнер, конечно, тогда тоже был не прав, потому что удалил авторство Брюса вот над этими "закрывающими скобочками", но Брюс, конечно, очень плохой человек - он настаивает на том, что он является автором busybox, даже если там не осталось его кода. Очень интересная идея, конечно.
GNU, кстати, согласно с такой трактовкой - один раз автор - всегда автор. Поэтому GNU/Linux, даже если кода GNU у тебя сейчас уже нет(не верите? А попробуйте собрать какую-нибудь #autohell приблуду с gnu triplet, содержащим linux, но не содержащим gnu).
Зачем издания форсят этот унылый мем, что "автору busybox" там кто-то мешает вести бизнес, я не понимаю. Он уже давно не автор.
———
Busybox или Toybox?
Мне, конечно, ближе идея toybox(https://www.landley.net/toybox/faq.html#why_toybox).
Я не верю в деньги или славу от OSS, это примерно как рассчитывать на деньги и славу от профессионального спорта - ну вот сколько вы знаете известных программистов? 100? 1000? Наверное, примерно столько же, сколько и спортсменов.
Я верю в патчи и фидбек от OSS, а они достигаются широтой использования твоего кода. Даже если кто-то решит закрыть твой код, патчи ему будет выгоднее держать в upstream.
Поэтому toybox почти в каждом телефоне, а busybox на рутерах, и его оттуда постоянно выпиливают, потому что разработчики - склочные #GPL задроты.
Ну и на закуску - busybox про #systemd. https://busybox.net/kill_it_with_fire.txt
———
https://reviews.llvm.org/rG37e6bd8bc8da
К НГ новости совсем закончились, вот, llvm weekly предлагает, в качестве новости, вот такой вот коммит про очередной scope guard.
———
Пишут, что Линусу сегодня 52. Это, конечно, очень важно, и вот вам ссылка на запись одного из его самых первых выступлений на конференциях. Я не слушал, не фанат. https://www.facebook.com/maddoghall/posts/10159125354012025
www.opennet.ru
Релиз минималистичного набора системных утилит BusyBox 1.35
Представлен релиз пакета BusyBox 1.35 с реализацией набора стандартных утилит UNIX, оформленных в виде единого исполняемого файла и оптимизированных для минимального потребления системных ресурсов при размере комплекта менее 1 Мб. Первый выпуск новой ветки…
👍1
Решил тут вечерочком собрать себе https://github.com/aristocratos/btop
Думал, задачка минут на 5, все зависимости уже в репе. Ага, конечно.
Судя по всему(в том числе, и по качеству кода, про которое в следующий раз), автор на этом проекте учил С++, и поэтому решил использовать все доступные фичи из C++20.
Например, библиотеку ranges, которой еще нет в clang-13(в полном объеме). Вообще, вопрос в сторону - какого хера авторы компиляторов не использовали готовый код от Эрика? У них там бесконечные ресурсы на перепиливание одного и того же говна? Про libc++ я точно знаю, что ее пилит полтора стажера. Вот какого, спрашивается, хера?
У меня было 2 пути:
* Заиспользовать оригинальные ranges-v3:
https://github.com/pg83/mix/blob/main/pkgs/sys/btop++/mix.sh#L22
Это оказалось достаточно просто, всего лишь фейкаем <ranges> на основе ranges-v3.
Разве что:
1) Релизные ranges-v3 несовместимы с clang-13, потому что лезут в потроха компилятора(https://github.com/ericniebler/range-v3/tree/master/include/std). Пришлось взять транковую версию.
2) Какой-то баг в clang, что он не дал подменить <ranges>, несмотря на корректную манипуляцию с -I, -isystem. Пришлось еще запатчить сами #include <ranges>
Но черт меня дернул, что негоже так хачить, и(второй путь)
* соберу-ка я libstdc++ для этого проекта. Дэээ, забыл, с кем имею дело(проект GNU), товарищи же всегда все делают самым ненатуральным образом. Я собрал, кажется, до меня это никто не делал, судя по объему правок и хаков:
1) Форсим кросс-компиляцию, обманываем насчет host платформы, так как авторы libstdc++ шибко умные(нет), и запрещают кросс-компиляцию если host == target. https://github.com/pg83/mix/blob/main/pkgs/lib/c++/std/mix.sh#L32
2) Небольшие хаки из-за несовпадения названия некоторых intrinsics:
https://github.com/pg83/mix/blob/main/pkgs/lib/c++/std/mix.sh#L37
3) https://github.com/pg83/mix/blob/main/pkgs/lib/c++/std/mix.sh#L42
Самая мякотка. GNU собирают свою библиотеку с разными настройками -std=, разные исходники с разной настройкой. И некоторые аспекты того, что компиляторостроители подразумевают под стандартами, отличается от компилятора к компилятору. Например, авторы g++ очень хотят constinit в c++17, но этого же не существует, поэтому они добавляют кличевое слово __constinit. Оно не работает в clang. В clang есть constinit в с++20, но для этого нужно для этого конкретного файла поменять стандарт, с которым мы его компилируем. Сделал я это через wrapper для clang.
4) В clang aligned new, sized deallocation под опциями. https://github.com/pg83/mix/blob/main/pkgs/lib/c++/std/mix.sh#L53 Включать для c++98 нельзя, что-то ломается в потрохах libstdc++
Короче, собрал, но бестолку, потому что clang не сумел прожевать ranges от libstdc++.
Думаю, собрать всю эту ветку дерева с g++, как того и хотел автор(но это уже в другой раз), потому что с libc++ btop неверно обрабатывает пользовательский ввод. long story про это в следующий раз, а нетерпеливые могут посмотреть на https://github.com/aristocratos/btop/pull/227
Чувак мой патч не хочет. Стандартная история - сам наговнокодил, от остальных требует конфетку.
Думал, задачка минут на 5, все зависимости уже в репе. Ага, конечно.
Судя по всему(в том числе, и по качеству кода, про которое в следующий раз), автор на этом проекте учил С++, и поэтому решил использовать все доступные фичи из C++20.
Например, библиотеку ranges, которой еще нет в clang-13(в полном объеме). Вообще, вопрос в сторону - какого хера авторы компиляторов не использовали готовый код от Эрика? У них там бесконечные ресурсы на перепиливание одного и того же говна? Про libc++ я точно знаю, что ее пилит полтора стажера. Вот какого, спрашивается, хера?
У меня было 2 пути:
* Заиспользовать оригинальные ranges-v3:
https://github.com/pg83/mix/blob/main/pkgs/sys/btop++/mix.sh#L22
Это оказалось достаточно просто, всего лишь фейкаем <ranges> на основе ranges-v3.
Разве что:
1) Релизные ranges-v3 несовместимы с clang-13, потому что лезут в потроха компилятора(https://github.com/ericniebler/range-v3/tree/master/include/std). Пришлось взять транковую версию.
2) Какой-то баг в clang, что он не дал подменить <ranges>, несмотря на корректную манипуляцию с -I, -isystem. Пришлось еще запатчить сами #include <ranges>
Но черт меня дернул, что негоже так хачить, и(второй путь)
* соберу-ка я libstdc++ для этого проекта. Дэээ, забыл, с кем имею дело(проект GNU), товарищи же всегда все делают самым ненатуральным образом. Я собрал, кажется, до меня это никто не делал, судя по объему правок и хаков:
1) Форсим кросс-компиляцию, обманываем насчет host платформы, так как авторы libstdc++ шибко умные(нет), и запрещают кросс-компиляцию если host == target. https://github.com/pg83/mix/blob/main/pkgs/lib/c++/std/mix.sh#L32
2) Небольшие хаки из-за несовпадения названия некоторых intrinsics:
https://github.com/pg83/mix/blob/main/pkgs/lib/c++/std/mix.sh#L37
3) https://github.com/pg83/mix/blob/main/pkgs/lib/c++/std/mix.sh#L42
Самая мякотка. GNU собирают свою библиотеку с разными настройками -std=, разные исходники с разной настройкой. И некоторые аспекты того, что компиляторостроители подразумевают под стандартами, отличается от компилятора к компилятору. Например, авторы g++ очень хотят constinit в c++17, но этого же не существует, поэтому они добавляют кличевое слово __constinit. Оно не работает в clang. В clang есть constinit в с++20, но для этого нужно для этого конкретного файла поменять стандарт, с которым мы его компилируем. Сделал я это через wrapper для clang.
4) В clang aligned new, sized deallocation под опциями. https://github.com/pg83/mix/blob/main/pkgs/lib/c++/std/mix.sh#L53 Включать для c++98 нельзя, что-то ломается в потрохах libstdc++
Короче, собрал, но бестолку, потому что clang не сумел прожевать ranges от libstdc++.
Думаю, собрать всю эту ветку дерева с g++, как того и хотел автор(но это уже в другой раз), потому что с libc++ btop неверно обрабатывает пользовательский ввод. long story про это в следующий раз, а нетерпеливые могут посмотреть на https://github.com/aristocratos/btop/pull/227
Чувак мой патч не хочет. Стандартная история - сам наговнокодил, от остальных требует конфетку.
GitHub
GitHub - aristocratos/btop: A monitor of resources
A monitor of resources. Contribute to aristocratos/btop development by creating an account on GitHub.
commit -m "better"
Решил тут вечерочком собрать себе https://github.com/aristocratos/btop Думал, задачка минут на 5, все зависимости уже в репе. Ага, конечно. Судя по всему(в том числе, и по качеству кода, про которое в следующий раз), автор на этом проекте учил С++, и поэтому…
>Чувак мой патч не хочет. Стандартная история - сам наговнокодил, от остальных требует конфетку.
Ну ладно, ладно, обознался. Чувак норм, я ему все объяснил по существу, патч он принял.
Код, конечно, выглядит так, как будто кто-то не справился с починкой сегфолтов от неопределенного порядка разрушения global static, я ему впилил _Exit(), чтобы голову себе не морочить.
Приятный чувак, давненько я в code review так не расшаркивался - "ой, я сделаю, как ты считаешь нужным - нет, делай сам, тебе виднее - ой, ну что ты, хорошо".
Вообще, кодовая база оставляет о себе впечатление "писал вменяемый чувак, просто местами не понимал, как оно внутри работает". Судя по треку bashtop -> bpytop -> btop++, так оно и есть.
https://github.com/aristocratos/btop/issues/5 - вот тут ему, конечно, уже предложили все на Rust переписать.
Ну ладно, ладно, обознался. Чувак норм, я ему все объяснил по существу, патч он принял.
Код, конечно, выглядит так, как будто кто-то не справился с починкой сегфолтов от неопределенного порядка разрушения global static, я ему впилил _Exit(), чтобы голову себе не морочить.
Приятный чувак, давненько я в code review так не расшаркивался - "ой, я сделаю, как ты считаешь нужным - нет, делай сам, тебе виднее - ой, ну что ты, хорошо".
Вообще, кодовая база оставляет о себе впечатление "писал вменяемый чувак, просто местами не понимал, как оно внутри работает". Судя по треку bashtop -> bpytop -> btop++, так оно и есть.
https://github.com/aristocratos/btop/issues/5 - вот тут ему, конечно, уже предложили все на Rust переписать.
GitHub
Rewrite in Rust · Issue #5 · aristocratos/btop
Hi, I think that the program needs just one more FINAL rewrite but this time in the powerful HolyC Rust. It would be the final solution to all of our problems. Could you explain why did you rewrote...
https://www.opennet.ru/opennews/art.shtml?num=56428
Уязвимости - это как ходить в лес, за грибами. Нашел один - поищи рядом, обязательно найдешь еще.
———
https://www.rogdham.net/2017/03/12/gif-md5-hashquine.en
Если вы думали, что мне подарить на НГ(ну или там на ДР), то вот, прекрасный вариант. Конечно, эту конкретную гифку дарить не нужно, нужно сделать такую же, но с моими инициалами!
———
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ad964f7eaef9c03ce68a01cfdd7fde9d56524868
На прошлой неделе(неделе линкера!) кидал текст про то, как авторы gcc восприняли предложение поддержать #mold в gcc. Но стоило прийти "правильному" человеку, c "правильным" патчем, как все вдруг заткнулись. Впрочем, этим страдают вообще все IT проекты, которые я знаю(и не только OSS), чего уж тут.
———
https://ariadne.space/2021/12/29/glibc-is-still-not-y2038-compliant-by-default/
Тут вот жалуются, что #glibc неправильно подошли к проблеме y38, а musl - правильно. Ну так я спешу огорчить товарищей, что "оба неправильно". Это они просто не видели, как к ABI подходят вменяемые люди, например, разработчики WinAPI(для тех, кто в танке - в каждую структуру с запросом в WinAPI пишут версию(например, размер структуры, который хорошая версия, если поля только добавлять)). А glibc, musl - это так, детские шалости.
Уязвимости - это как ходить в лес, за грибами. Нашел один - поищи рядом, обязательно найдешь еще.
———
https://www.rogdham.net/2017/03/12/gif-md5-hashquine.en
Если вы думали, что мне подарить на НГ(ну или там на ДР), то вот, прекрасный вариант. Конечно, эту конкретную гифку дарить не нужно, нужно сделать такую же, но с моими инициалами!
———
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ad964f7eaef9c03ce68a01cfdd7fde9d56524868
На прошлой неделе(неделе линкера!) кидал текст про то, как авторы gcc восприняли предложение поддержать #mold в gcc. Но стоило прийти "правильному" человеку, c "правильным" патчем, как все вдруг заткнулись. Впрочем, этим страдают вообще все IT проекты, которые я знаю(и не только OSS), чего уж тут.
———
https://ariadne.space/2021/12/29/glibc-is-still-not-y2038-compliant-by-default/
Тут вот жалуются, что #glibc неправильно подошли к проблеме y38, а musl - правильно. Ну так я спешу огорчить товарищей, что "оба неправильно". Это они просто не видели, как к ABI подходят вменяемые люди, например, разработчики WinAPI(для тех, кто в танке - в каждую структуру с запросом в WinAPI пишут версию(например, размер структуры, который хорошая версия, если поля только добавлять)). А glibc, musl - это так, детские шалости.
www.opennet.ru
Обновление Log4j 2.17.1 с устранением ещё одной уязвимости
Опубликованы корректирующие выпуски библиотеки Log4j 2.17.1, 2.3.2-rc1 и 2.12.4-rc1, в которых устранена ещё одна уязвимость (CVE-2021-44832). Упоминается, что проблема позволяет организовать удалённое выполнение кода (RCE), но при этом помечена как неопасная…
Я ничо не понял, но, кажется, это, наконец, про porno + Deep Learning. 30 лет жду.
https://github.com/liaoxiong3x/DeepCreamPy (божечки, название просто огонь)
———
https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20211227/992076.html
С моим подходом к разработке запилить новый таргет в LLVM я не смогу никогда. Ну и вообще, документ какой-то "запретительный". Как-то это не круто - типа, сделайте всю работу, а мы подумаем, нужна ли нам такая архитектура, или нет.
———
https://devblogs.microsoft.com/oldnewthing/20211229-00/?p=106061
Старость - это когда по заголовку статьи сразу понимаешь, о чем она(в данном случае было понятно, что речь или про процессорные кеши(как в Alpha, например), или про PIC).
Узнал красивое:
"Indeed, there’s no requirement that the code bytes for the RemoteThreadProc function be contiguous at all! Profile-Guided Optimization will rearrange basic blocks, and the code for a single function may end up scattered across different parts of the program, depending on their usage patterns."
Оказывается, PGO умеет не только функции переставлять, но и отдельные блоки так, что код функции перестает быть непрерывным. Интересно, много ли это дает, и умеет ли #LLVM так.
———
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-2021-Tops
https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-D3D12-Mesa-SSBO
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-22.0-Build-macOS-Zink
У #Mesa все хорошо. Microsoft коммитит в Mesa, Valve коммитит в Mesa. Впрочем, Microsoft не забывает и про альтернативу - https://github.com/microsoft/angle (ссылку я привел, чтобы показать, что MS контрибутит в #ANGLE, сама репа deprecated) Я так понимаю, Microsoft думает, как же у нее в дальнейшем будет устроен OpenGL over DirectX. #zink
———
https://www.opennet.ru/opennews/art.shtml?num=56429
https://www.phoronix.com/scan.php?page=article&item=kde-gnome-wayland21&num=1
Ни на грош не верю тестам от Phoronix, да и сравнение это, скорее, композиторов, а не технологий.
It is a shame, что, для того, чтобы игры не тормозили, в Wayland композиторе надо написать кучу кода.
https://github.com/liaoxiong3x/DeepCreamPy (божечки, название просто огонь)
———
https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20211227/992076.html
С моим подходом к разработке запилить новый таргет в LLVM я не смогу никогда. Ну и вообще, документ какой-то "запретительный". Как-то это не круто - типа, сделайте всю работу, а мы подумаем, нужна ли нам такая архитектура, или нет.
———
https://devblogs.microsoft.com/oldnewthing/20211229-00/?p=106061
Старость - это когда по заголовку статьи сразу понимаешь, о чем она(в данном случае было понятно, что речь или про процессорные кеши(как в Alpha, например), или про PIC).
Узнал красивое:
"Indeed, there’s no requirement that the code bytes for the RemoteThreadProc function be contiguous at all! Profile-Guided Optimization will rearrange basic blocks, and the code for a single function may end up scattered across different parts of the program, depending on their usage patterns."
Оказывается, PGO умеет не только функции переставлять, но и отдельные блоки так, что код функции перестает быть непрерывным. Интересно, много ли это дает, и умеет ли #LLVM так.
———
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-2021-Tops
https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-D3D12-Mesa-SSBO
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-22.0-Build-macOS-Zink
У #Mesa все хорошо. Microsoft коммитит в Mesa, Valve коммитит в Mesa. Впрочем, Microsoft не забывает и про альтернативу - https://github.com/microsoft/angle (ссылку я привел, чтобы показать, что MS контрибутит в #ANGLE, сама репа deprecated) Я так понимаю, Microsoft думает, как же у нее в дальнейшем будет устроен OpenGL over DirectX. #zink
———
https://www.opennet.ru/opennews/art.shtml?num=56429
https://www.phoronix.com/scan.php?page=article&item=kde-gnome-wayland21&num=1
Ни на грош не верю тестам от Phoronix, да и сравнение это, скорее, композиторов, а не технологий.
It is a shame, что, для того, чтобы игры не тормозили, в Wayland композиторе надо написать кучу кода.
GitHub
GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.
Что я имею сказать по поводу НГ?
Скажу, что, пожалуй, лучший новогодний фильм это Love Actually, и он есть на КиноПоиске!
Ну и кусочек фильма(правда, больше это похоже на backstage, но не суть) со снегурками в ленту!
https://www.youtube.com/watch?v=eJGqWXSW49I
Скажу, что, пожалуй, лучший новогодний фильм это Love Actually, и он есть на КиноПоиске!
Ну и кусочек фильма(правда, больше это похоже на backstage, но не суть) со снегурками в ленту!
https://www.youtube.com/watch?v=eJGqWXSW49I
YouTube
Billy Mack / Bill Nighy ► Christmas Is All Around / Love Actually
Artist: Billy Mack
Album: Love Actually
Released: 2003
Album: Love Actually
Released: 2003
https://github.com/rswinkle/PortableGL
Софтверная реализация чего-то, похожего на OpenGL.
https://github.com/h0MER247/swGL
Или вот еще одна.
https://docs.mesa3d.org/relnotes/21.3.3.html
Bugfix релиз #Mesa. Классный changelog, коротко и по делу:
"Mesa 21.3.3 is a bug fix release which fixes bugs found since the 21.3.2 release."
———
https://garrit.xyz/posts/2021-12-31-btrfs-on-alpine
Про то, как автомонтировать разделы с btrfs на Alpine Linux. Новость довольно бессмысленная, но она меня заставила задуматься, не ломает ли такое использование init мою концепцию "мешка сервисов". IMHO нет, не ломает.
В заметке описан хак вида "как бы нам запустить произвольную команду перед командой mount all, а, у нас же есть зависимости в сервисах, сделаем для этого фейковый сервис".
Решение плохое, оно теперь прорастет в документацию, и все будут им пользоваться, вместо того, чтобы корректно подправить "mount all".
С учетом того, что люди предпочитают идти по пути наименьшего сопротивления сейчас, не учитывая последствия, некоторые возможности лучше не давать.
———
https://nullprogram.com/
Классный блог про вещи, которые вам вряд ли когда-то понадобятся. "как ускорить ненужно в 4 раза", "как запустить ненужное в ненужном", и так далее. Но написано с огоньком.
———
Продолжаю рассказывать про свой перфекционизм, бессмысленный и беспощадный.
Например, вот стандартная MIT Licence, от github:
https://github.com/pg83/testrepo/blob/main/LICENSE
А вот моя редакция:
https://github.com/pg83/mix/blob/main/LICENSE
(Нет, я не сумасшедший, я скрипт написал. Хороший, кстати, скрипт, он учитывает, что лучше поставить лишний пробел между AB CDE, чем между A BC).
Софтверная реализация чего-то, похожего на OpenGL.
https://github.com/h0MER247/swGL
Или вот еще одна.
https://docs.mesa3d.org/relnotes/21.3.3.html
Bugfix релиз #Mesa. Классный changelog, коротко и по делу:
"Mesa 21.3.3 is a bug fix release which fixes bugs found since the 21.3.2 release."
———
https://garrit.xyz/posts/2021-12-31-btrfs-on-alpine
Про то, как автомонтировать разделы с btrfs на Alpine Linux. Новость довольно бессмысленная, но она меня заставила задуматься, не ломает ли такое использование init мою концепцию "мешка сервисов". IMHO нет, не ломает.
В заметке описан хак вида "как бы нам запустить произвольную команду перед командой mount all, а, у нас же есть зависимости в сервисах, сделаем для этого фейковый сервис".
Решение плохое, оно теперь прорастет в документацию, и все будут им пользоваться, вместо того, чтобы корректно подправить "mount all".
С учетом того, что люди предпочитают идти по пути наименьшего сопротивления сейчас, не учитывая последствия, некоторые возможности лучше не давать.
———
https://nullprogram.com/
Классный блог про вещи, которые вам вряд ли когда-то понадобятся. "как ускорить ненужно в 4 раза", "как запустить ненужное в ненужном", и так далее. Но написано с огоньком.
———
Продолжаю рассказывать про свой перфекционизм, бессмысленный и беспощадный.
Например, вот стандартная MIT Licence, от github:
https://github.com/pg83/testrepo/blob/main/LICENSE
А вот моя редакция:
https://github.com/pg83/mix/blob/main/LICENSE
(Нет, я не сумасшедший, я скрипт написал. Хороший, кстати, скрипт, он учитывает, что лучше поставить лишний пробел между AB CDE, чем между A BC).
GitHub
GitHub - rswinkle/PortableGL: An implementation of OpenGL 3.x-ish in clean C
An implementation of OpenGL 3.x-ish in clean C. Contribute to rswinkle/PortableGL development by creating an account on GitHub.
https://robert.ocallahan.org/2021/12/do-we-really-need-link-step.html, пишет нам какой-то городской сумасшедший, и тут же переизобретает косой и кривой линкер.
"An obvious problem is how to handle symbol resolution, i.e. what happens when the compiler emits code for a translation unit that uses symbol A from some other unit --- especially if that other unit hasn't been compiled yet? Here's an option for function symbols: when A is used for the first time, write a stub for A to the final binary and call that. When a definition for A is seen, patch the stub to jump to the definition. Internally this will mean maintaining a parallel hashtable of all undefined symbols that all compiler instances can share efficiently."
———
https://tjournal.ru/news/500911-mincifry-nachalo-peregovory-s-hp-acer-i-lenovo-o-predustanovke-rossiyskih-operacionnyh-sistem-na-kompyutery #altlinux
ALT, ASP изжили себя после внедрения UTF-8(кстати, задачка вам в ленту - https://elementy.ru/problems/2689/Yunikod_na_Novyy_god) и быстрых и дешевых сетей.
* Настроить русский язык в Linux до повсеместного перехода на UTF-8 было очень сложно.
* Скачать пару компакт-дисков по рублю за мегабайт(это мой реальный первый тариф, причем рубли 2000-го года) - очень дорого. Я, помнится, тогда жил на 1000 в месяц, и горя не знал.
ASP честно сдох, ALT решил выжить любой ценой. Как в России выживают нерыночным способом - мы все знаем, не маленькие.
Результат, конечно, немного предсказуем.
———
#fontconfig
Программисты не любят договариваться. Ну, ладно, люди вообще не любят договариваться.
Поэтому мы, например, имеем https://www.freedesktop.org/wiki/Software/fontconfig/
Это такая библиотечка, которая по строчке "Arial;size=22" должна вернуть "/usr/share/fonts/arial.ttf". Не, реально, вот это она и делает, и все. Каталогизирует доступные шрифты в системе.
Кажется очень разумным, чтобы это был простенький демон, а библиотечка просто бы делала запрос к нему. 5 строк кода, весит 0кб.
Но нет, программисты же не умеют договариваться. Это же бы значило, что нужно прийти в 100500 дистрибутивов, договориться со 100500 совершенно диких и невменяемых людей(со своим бесценным мнением).
Поэтому мы имеем:
* библиотеку, которая принудительно влинковывает в себя полный рендер шрифтов(а как же еще узнать свойства шрифта в файле?), xml parser(потому что правила матчинга написаны на xml), и еще говна самовар. Конечно, даже и в этом случае этих зависимостей можно было бы избежать, но библиотека же ДОЛЖНА уметь классифицировать любой подвернувшийся файл!
* Библиотека из каждого приложения регулярно ходит в fs, чтобы посмотреть, не появились ли там новые шрифты. Сука, ИЗ КАЖДОГО.
* В качестве оптимизации - библиотека ходит не по всей fs, а только в несколько файликов, куда утилита fc-cache складывает результат грепа шрифтов по FS. fc-cache, конечно, тоже не запускается регулярно, потому что это же договариваться пришлось бы.
"An obvious problem is how to handle symbol resolution, i.e. what happens when the compiler emits code for a translation unit that uses symbol A from some other unit --- especially if that other unit hasn't been compiled yet? Here's an option for function symbols: when A is used for the first time, write a stub for A to the final binary and call that. When a definition for A is seen, patch the stub to jump to the definition. Internally this will mean maintaining a parallel hashtable of all undefined symbols that all compiler instances can share efficiently."
———
https://tjournal.ru/news/500911-mincifry-nachalo-peregovory-s-hp-acer-i-lenovo-o-predustanovke-rossiyskih-operacionnyh-sistem-na-kompyutery #altlinux
ALT, ASP изжили себя после внедрения UTF-8(кстати, задачка вам в ленту - https://elementy.ru/problems/2689/Yunikod_na_Novyy_god) и быстрых и дешевых сетей.
* Настроить русский язык в Linux до повсеместного перехода на UTF-8 было очень сложно.
* Скачать пару компакт-дисков по рублю за мегабайт(это мой реальный первый тариф, причем рубли 2000-го года) - очень дорого. Я, помнится, тогда жил на 1000 в месяц, и горя не знал.
ASP честно сдох, ALT решил выжить любой ценой. Как в России выживают нерыночным способом - мы все знаем, не маленькие.
Результат, конечно, немного предсказуем.
———
#fontconfig
Программисты не любят договариваться. Ну, ладно, люди вообще не любят договариваться.
Поэтому мы, например, имеем https://www.freedesktop.org/wiki/Software/fontconfig/
Это такая библиотечка, которая по строчке "Arial;size=22" должна вернуть "/usr/share/fonts/arial.ttf". Не, реально, вот это она и делает, и все. Каталогизирует доступные шрифты в системе.
Кажется очень разумным, чтобы это был простенький демон, а библиотечка просто бы делала запрос к нему. 5 строк кода, весит 0кб.
Но нет, программисты же не умеют договариваться. Это же бы значило, что нужно прийти в 100500 дистрибутивов, договориться со 100500 совершенно диких и невменяемых людей(со своим бесценным мнением).
Поэтому мы имеем:
* библиотеку, которая принудительно влинковывает в себя полный рендер шрифтов(а как же еще узнать свойства шрифта в файле?), xml parser(потому что правила матчинга написаны на xml), и еще говна самовар. Конечно, даже и в этом случае этих зависимостей можно было бы избежать, но библиотека же ДОЛЖНА уметь классифицировать любой подвернувшийся файл!
* Библиотека из каждого приложения регулярно ходит в fs, чтобы посмотреть, не появились ли там новые шрифты. Сука, ИЗ КАЖДОГО.
* В качестве оптимизации - библиотека ходит не по всей fs, а только в несколько файликов, куда утилита fc-cache складывает результат грепа шрифтов по FS. fc-cache, конечно, тоже не запускается регулярно, потому что это же договариваться пришлось бы.
robert.ocallahan.org
Do We Really Need A Link Step?
mold looks pretty cool, and a faster drop-in ld replacement is obviously extremely useful. But having no link step at all would be even fa...
https://lkml.org/lkml/2022/1/2/187
Титаническая работа, чего тут еще сказать.
Добавлю:
* Признаться, я удивлен, что проект на C довел себя до такого состояния. Все же, это больше свойственно проектам на С++, когда 1 маленький шаблон генерит мегабайты кода(ну, AST, разница невелика).
* Какой автоматикой он пользовался, чтобы понять, что лишнее включено в конкретный .h? Для clang мы ее все знаем.
* "I also improved build speed by
consolidating .c files into roughly equal size build units. Instead of 20+
separate .o's, there's now just 4 .o's being built."
Ахаха, #JOIN_SRCS()
* Интересно, есть цифры про сборку ядра с clang?
———
https://izzys.casa/2021/12/wrapping-up-2021/
Хороший текст про С++, Rust, Zig, и, в меньшей мере, про Swift.
Swift мне из этих языков кажется самым интересным, а то, что он плохо поддерживает Windows - ну так, знаете, сами MS и виноваты.
Пока они были сильные, их политика "сделать все по другому" приносила плоды со знаком +, а теперь приносит плоды со знаком -.
Человечеству IMHO пора уже определиться с тем, сколько корней у root fs, и отменить fork(), как обязательное требование к POSIX, и будет всем счастье.
(Про Zig там волшебно - "Zig also is not an option for me as its clearly written by someone who hates the idea of destructors and implicit behavior, of abstracting your thoughts away in a “set it and forget it” kind of manner. Zig somehow manages to go a step further and feel like I’m writing LLVM bitcode but with control flow constructs. I’d rather just not touch it.")
———
https://graphitemaster.github.io/aau/ #unsigned
Хороший текст про то, почему signed int плохо, а unsigned - хорошо.
Хотел было написать по этой теме много текста, но, КМК, индустрия уже рассудила меня и "3 выходцев из NIVAL"(да, вы все знаете, о ком я), которые топили за signed int.
* Типы должны описывать только те значения, которые валидны для переменных этих типов, не больше, и не меньше.
* Возможность вернуть sentinel в любом месте - зло. Гениальные авторы оригинального кода уходят, приходят новые люди, которые не знают, может ли конкретная int f() вернуть число < 0, == -1, или только >= 0, и начинаются проверки на пустом месте, и забытое протаскивание ошибок наверх. А потом в биллинге регулярно вычитаем -1 с чьего-нибудь счета. Плавали, знаем.
* Главный аргумент - reverse iterator по массиву. А часто ли его приходится использовать? Ну и, кстати, в статье очень норм техника для обхода массива в обратном порядке с unsigned индексом, я про такую и не знал.
Титаническая работа, чего тут еще сказать.
Добавлю:
* Признаться, я удивлен, что проект на C довел себя до такого состояния. Все же, это больше свойственно проектам на С++, когда 1 маленький шаблон генерит мегабайты кода(ну, AST, разница невелика).
* Какой автоматикой он пользовался, чтобы понять, что лишнее включено в конкретный .h? Для clang мы ее все знаем.
* "I also improved build speed by
consolidating .c files into roughly equal size build units. Instead of 20+
separate .o's, there's now just 4 .o's being built."
Ахаха, #JOIN_SRCS()
* Интересно, есть цифры про сборку ядра с clang?
———
https://izzys.casa/2021/12/wrapping-up-2021/
Хороший текст про С++, Rust, Zig, и, в меньшей мере, про Swift.
Swift мне из этих языков кажется самым интересным, а то, что он плохо поддерживает Windows - ну так, знаете, сами MS и виноваты.
Пока они были сильные, их политика "сделать все по другому" приносила плоды со знаком +, а теперь приносит плоды со знаком -.
Человечеству IMHO пора уже определиться с тем, сколько корней у root fs, и отменить fork(), как обязательное требование к POSIX, и будет всем счастье.
(Про Zig там волшебно - "Zig also is not an option for me as its clearly written by someone who hates the idea of destructors and implicit behavior, of abstracting your thoughts away in a “set it and forget it” kind of manner. Zig somehow manages to go a step further and feel like I’m writing LLVM bitcode but with control flow constructs. I’d rather just not touch it.")
———
https://graphitemaster.github.io/aau/ #unsigned
Хороший текст про то, почему signed int плохо, а unsigned - хорошо.
Хотел было написать по этой теме много текста, но, КМК, индустрия уже рассудила меня и "3 выходцев из NIVAL"(да, вы все знаете, о ком я), которые топили за signed int.
* Типы должны описывать только те значения, которые валидны для переменных этих типов, не больше, и не меньше.
* Возможность вернуть sentinel в любом месте - зло. Гениальные авторы оригинального кода уходят, приходят новые люди, которые не знают, может ли конкретная int f() вернуть число < 0, == -1, или только >= 0, и начинаются проверки на пустом месте, и забытое протаскивание ошибок наверх. А потом в биллинге регулярно вычитаем -1 с чьего-нибудь счета. Плавали, знаем.
* Главный аргумент - reverse iterator по массиву. А часто ли его приходится использовать? Ну и, кстати, в статье очень норм техника для обхода массива в обратном порядке с unsigned индексом, я про такую и не знал.
https://ryanhileman.info/posts/lib43
https://gist.github.com/jboner/2841832
Специально поместил эти две ссылки рядом, чтобы желающие смогли на пальцах прикинуть, сколько времени должен исполняться типичный #autohell ./configure script. По моим прикидкам, если бы не sleep-ы в ядре Linux, секунд 5. А не 1 - 2 минуты, как сейчас.
———
https://www.mattkeeter.com/projects/synthesis/
Классный текст про использование SAT solver. Я в своей карьере использовал SAT solver 1 раз, для какой-то задачки с Эйлера, но знать про такую возможность, конечно, полезно.
———
https://www.opennet.ru/opennews/art.shtml?num=56422
Очень хорошая подборка материалов - что важного и интересного произошло в 21 году. Заметьте, что в тексте очень много ссылок, и почти все они ведут на новости с opennet.
Opennet - мой любимый новостной канал, там все появляется достаточно быстро, и новости хорошо пролинкованы между собой.
При этом, opennet, по современным меркам, очень странная площадка:
* Там есть Анонимус
* Все посылают друг друга нахуй
* Один из модераторов - фашист(не в смысле "плохой человек", а в смысле Википедии).
При этом:
* Там полное ощущение свободы и вольнодумия
* Даже этого модератора-фашиста все кроют хуями, а он в ответ не раздает банхаммер направо и налево(вот его лог модерирования - https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi?az=list&forum=vsluhforumID3&open=moderator&n=Michael+Shigorin)(а на большом числе ресурсов модераторы не ссат показать такой лог?)
* Встречаются прямо очень интересные комментаторы.
И вот это слабо почищенное говно читать приятнее, чем эти ваши выхолощенные HN, и прочую левацкую поебень.
На самом деле, сравнивая opennet и HN, лично я прихожу к выводу, что свобода слова таки должна быть абсолютной, а желающие что-то запретить мне читать пускай настроят фильтр себе(а не мне).
Вот как предлагают бороться с троллингом на opennet - https://www.opennet.ru/tips/3195_ublock_filter.shtml
Это очень здоровая вещь, если подумать. Если что-то мешает лично тебе - то скрой это себе, и не пытайся скрыть для всех остальных.
https://gist.github.com/jboner/2841832
Специально поместил эти две ссылки рядом, чтобы желающие смогли на пальцах прикинуть, сколько времени должен исполняться типичный #autohell ./configure script. По моим прикидкам, если бы не sleep-ы в ядре Linux, секунд 5. А не 1 - 2 минуты, как сейчас.
———
https://www.mattkeeter.com/projects/synthesis/
Классный текст про использование SAT solver. Я в своей карьере использовал SAT solver 1 раз, для какой-то задачки с Эйлера, но знать про такую возможность, конечно, полезно.
———
https://www.opennet.ru/opennews/art.shtml?num=56422
Очень хорошая подборка материалов - что важного и интересного произошло в 21 году. Заметьте, что в тексте очень много ссылок, и почти все они ведут на новости с opennet.
Opennet - мой любимый новостной канал, там все появляется достаточно быстро, и новости хорошо пролинкованы между собой.
При этом, opennet, по современным меркам, очень странная площадка:
* Там есть Анонимус
* Все посылают друг друга нахуй
* Один из модераторов - фашист(не в смысле "плохой человек", а в смысле Википедии).
При этом:
* Там полное ощущение свободы и вольнодумия
* Даже этого модератора-фашиста все кроют хуями, а он в ответ не раздает банхаммер направо и налево(вот его лог модерирования - https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi?az=list&forum=vsluhforumID3&open=moderator&n=Michael+Shigorin)(а на большом числе ресурсов модераторы не ссат показать такой лог?)
* Встречаются прямо очень интересные комментаторы.
И вот это слабо почищенное говно читать приятнее, чем эти ваши выхолощенные HN, и прочую левацкую поебень.
На самом деле, сравнивая opennet и HN, лично я прихожу к выводу, что свобода слова таки должна быть абсолютной, а желающие что-то запретить мне читать пускай настроят фильтр себе(а не мне).
Вот как предлагают бороться с троллингом на opennet - https://www.opennet.ru/tips/3195_ublock_filter.shtml
Это очень здоровая вещь, если подумать. Если что-то мешает лично тебе - то скрой это себе, и не пытайся скрыть для всех остальных.
Gist
Latency Numbers Every Programmer Should Know
Latency Numbers Every Programmer Should Know. GitHub Gist: instantly share code, notes, and snippets.
❤1
Я же уже рассказывал про свой новый ноут, и почему он просто офигенный?
На самом деле, была одна вещь, которая меня сильно раздражала, и, наконец-то, я нашел время ее победить.
Выглядело это так - если на каком-то очень светлом фоне появлялся большой очень темный участок(например, контекстное меню в браузере), то экран резко, по всей плоскости, менял яркость.
Я, пожалуй, не буду расписывать, как я это дебажил(вполне стандартные техники по рассечению пространства возможных проблем), вот настройка ядра драйвера amdgpu:
"abmlevel (uint)
Override the default ABM (Adaptive Backlight Management) level used for DC enabled hardware. Requires DMCU to be supported and loaded. Valid levels are 0-4. A value of 0 indicates that ABM should be disabled by default. Values 1-4 control the maximum allowable brightness reduction via the ABM algorithm, with 1 being the least reduction and 4 being the most reduction.
Defaults to 0, or disabled. Userspace can still override this level later after boot."
Почему она у меня была не 0, я разбираться не стал.
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-ABM-Linux-Backlight
Джобс бы, конечно, за эту дичьрасстрелял уволил на месте, что подсветка меняется одномоментно, а не растянуто на пару секунд, чтобы не мерцало.
———
Вчера писал про то, как сосет ядро Linux при выполнении configure скриптов. Сегодня немного цифр, время выполнения configure для coreutils, с разными там инструментами:
Думаю, погонять все это дело с strace.
———
https://blog.sunfishcode.online/port-std-to-rustix/
С нетерпением жду, когдашколота хипстеры коллеги разберутся с простыми вещами, и приступят к сложным(треды в Linux(https://ewontfix.com/17/), загрузчик для .so)
На самом деле, была одна вещь, которая меня сильно раздражала, и, наконец-то, я нашел время ее победить.
Выглядело это так - если на каком-то очень светлом фоне появлялся большой очень темный участок(например, контекстное меню в браузере), то экран резко, по всей плоскости, менял яркость.
Я, пожалуй, не буду расписывать, как я это дебажил(вполне стандартные техники по рассечению пространства возможных проблем), вот настройка ядра драйвера amdgpu:
"abmlevel (uint)
Override the default ABM (Adaptive Backlight Management) level used for DC enabled hardware. Requires DMCU to be supported and loaded. Valid levels are 0-4. A value of 0 indicates that ABM should be disabled by default. Values 1-4 control the maximum allowable brightness reduction via the ABM algorithm, with 1 being the least reduction and 4 being the most reduction.
Defaults to 0, or disabled. Userspace can still override this level later after boot."
Почему она у меня была не 0, я разбираться не стал.
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-ABM-Linux-Backlight
Джобс бы, конечно, за эту дичь
———
Вчера писал про то, как сосет ядро Linux при выполнении configure скриптов. Сегодня немного цифр, время выполнения configure для coreutils, с разными там инструментами:
dash + coreutils: 35sВсе собрано с LTO, для достижения максимальной производительности.
dash + busybox: 35s
bash + busybox: 40s
Думаю, погонять все это дело с strace.
———
https://blog.sunfishcode.online/port-std-to-rustix/
С нетерпением жду, когда
Phoronix
Radeon Linux Driver Preparing Adaptive Backlight Management (ABM)
The 'AMDGPU' Radeon Linux kernel graphics driver is preparing support for 'Adaptive Backlight Management' as a backlight power-savings feature for laptops.
https://www.ttauri-project.org/2021/03/30/the-trouble-with-anti-aliasing.html
https://medium.com/@evanwallace/easy-scalable-text-rendering-on-the-gpu-c3f4d782c5ac
Два классных текста про рендеринг шрифтов. К счастью, разрешения наших экранов уже позволяют про все про это не думать - например, у меня на глаз не заметна разница между AA и не AA рендерингом уже.
———
https://www.gnu.org/software/libunistring/#downloading
У меня есть привычка - по вечерам обновлять версии софта, чтобы не залеживался. Вчера пришла очередь libunistring, это такая безумная библиотека от GNU, по обработке юникодных строк(вот, кстати, что про нее думают мои любимые suckless - https://libs.suckless.org/libgrapheme/).
Сборка библиотеки падала с cryptic сообщением, мол, не могу найти команду "@sed". Полез разбираться, оказывается, GNU сломали сборку своей же либы в своем же режиме в #autohell Makefile V=0, когда вместо команд печатаются их сокращения. С V=1 все отлично собралось.
———
https://lkml.org/lkml/2022/1/2/187
Я не пойму, в этом вашем ядре энтузиасты своего дела, кроме Ingo, остались? 3 коммента на классную инициативу по ускорению сборки за несколько дней.
Или все уже старые, сытые, и пьют пиво на праздниках?
———
https://habr.com/ru/news/t/599409/ #wot
Хорошо, конечно, что идут в суд, а не занимаются противоправной херней, как это стало модно.
Но, как бывший последовательный левый, потом неубедительно болтающийся у центра центрист, а теперь не менее последовательный правый, я, конечно, на стороне тех, кто выпускает хаки.
"Представитель Wargaming заявил, что компания считает создание и продажу программ, нарушающих правила игр и их внутреннюю экономику, таким же преступлением, как кража или мошенничество. "
Знаете, давайте уже сажать за высокочастотный трейдинг, или применение ML на фондовых рынках, а то как же так?
———
#server_push
https://www.opennet.ru/opennews/art.shtml?num=54069
Я, оказывается, проспал красивое. Если бы не проспал, то, конечно бы потребовал от всех, кто мне годами ел мозг чайной ложечкой насчет server push, немедленно извиниться за весь мой съеденный мозг.
https://medium.com/@evanwallace/easy-scalable-text-rendering-on-the-gpu-c3f4d782c5ac
Два классных текста про рендеринг шрифтов. К счастью, разрешения наших экранов уже позволяют про все про это не думать - например, у меня на глаз не заметна разница между AA и не AA рендерингом уже.
———
https://www.gnu.org/software/libunistring/#downloading
У меня есть привычка - по вечерам обновлять версии софта, чтобы не залеживался. Вчера пришла очередь libunistring, это такая безумная библиотека от GNU, по обработке юникодных строк(вот, кстати, что про нее думают мои любимые suckless - https://libs.suckless.org/libgrapheme/).
Сборка библиотеки падала с cryptic сообщением, мол, не могу найти команду "@sed". Полез разбираться, оказывается, GNU сломали сборку своей же либы в своем же режиме в #autohell Makefile V=0, когда вместо команд печатаются их сокращения. С V=1 все отлично собралось.
———
https://lkml.org/lkml/2022/1/2/187
Я не пойму, в этом вашем ядре энтузиасты своего дела, кроме Ingo, остались? 3 коммента на классную инициативу по ускорению сборки за несколько дней.
Или все уже старые, сытые, и пьют пиво на праздниках?
———
https://habr.com/ru/news/t/599409/ #wot
Хорошо, конечно, что идут в суд, а не занимаются противоправной херней, как это стало модно.
Но, как бывший последовательный левый, потом неубедительно болтающийся у центра центрист, а теперь не менее последовательный правый, я, конечно, на стороне тех, кто выпускает хаки.
"Представитель Wargaming заявил, что компания считает создание и продажу программ, нарушающих правила игр и их внутреннюю экономику, таким же преступлением, как кража или мошенничество. "
Знаете, давайте уже сажать за высокочастотный трейдинг, или применение ML на фондовых рынках, а то как же так?
———
#server_push
https://www.opennet.ru/opennews/art.shtml?num=54069
Я, оказывается, проспал красивое. Если бы не проспал, то, конечно бы потребовал от всех, кто мне годами ел мозг чайной ложечкой насчет server push, немедленно извиниться за весь мой съеденный мозг.
https://hardcoresoftware.learningbyshipping.com/p/061-bsod-to-watson-the-reliability
Забавно. Товарищ (из Microsoft?) считает, что качество софта улучшилось, когда ввели телеметрию. Плохая статья.
На пути к хорошему софту было 3 этапа:
1) Перестали писать системный софт на ассемблере, и стали на C. Microsoft тут явно не была впереди планеты всей, потому что Unix.
2) Повсеместная защита памяти в OS. Microsoft, опять же, процессу не помогала, а мешала. Напомню, что Windows NT(которая работала, как часы), позиционировалась ею как система для профессионалов, и стоила, как космолет. Ситуация поменялась только после выхода провальной Windows ME, когда уже даже идиотам стало понятно, что методом грубой силы линейку Win95 до ума не довести.
Кстати, немного в сторону - вопреки некоторым мифам, Windows NT и памяти не сильно больше жрала, чем Win95/98, и с совместимостью программ у нее было неплохо. Например, более-менее все нерукожопые игры, которые работали через dos4/gw, прекрасно работали в NT, благодаря https://en.wikipedia.org/wiki/DOS_Protected_Mode_Interface - это такая технология, когда OS в себе содержит свой dos extender, и условный dos4/gw просто передает управление ему.
Windows NT 3.51(https://winworldpc.com/product/windows-nt-3x/351) - моя любимая винда. Красивый GUI, еще до-чикаго эпохи, микроядро, быстрое, и безопасное(она могла перезапустить упавший драйвер видюхи на ходу, например).
3) Санитайзеры. После их повсеместного внедрения я лично перестал бояться катить в прод. Казалось бы, при чем тут Microsoft? В Microsoft с этим всегда было туго, до-sanitizer технологии(valgrind) вообще никак не были представлены в Windows. #asan
4*) Переход на "безопасные" языки. Господа, давайте этот пункт обсудим лет через 5 - 10, когда impact уже будет очевиден :)
Короче, плохая, негодная статья, которая пытается представить, что MS была впереди планеты всей в борьбе с багами. Нет, это не так.
———
dash + coreutils: 35s
dash + busybox: 35s
bash + busybox: 40s
And the winner is..... Yash! https://yash.osdn.jp/index.html.en
yash + coreutils: 30s
Кстати, хороший, годный shell, я им периодически пользуюсь. В принципе, у него похожие плюсы(strict POSIX, fast, работает везде) и минусы(пишет 1 человек, непонятно будущее проекта), как и у dash, так что я пробую заменить.
———
https://browsix.org/
(тут должна быть картинка про hey dawg)
Мы сделали браузер для того, чтобы gui стоил дешево, и чтобы не нужно было разрабатывать десктопное приложение на каждый чих.
Но, вот, теперь запустили там Unix CLI. А что дальше? Qt/GTK, и потом опять браузер? Божечки, зачем.
Забавно. Товарищ (из Microsoft?) считает, что качество софта улучшилось, когда ввели телеметрию. Плохая статья.
На пути к хорошему софту было 3 этапа:
1) Перестали писать системный софт на ассемблере, и стали на C. Microsoft тут явно не была впереди планеты всей, потому что Unix.
2) Повсеместная защита памяти в OS. Microsoft, опять же, процессу не помогала, а мешала. Напомню, что Windows NT(которая работала, как часы), позиционировалась ею как система для профессионалов, и стоила, как космолет. Ситуация поменялась только после выхода провальной Windows ME, когда уже даже идиотам стало понятно, что методом грубой силы линейку Win95 до ума не довести.
Кстати, немного в сторону - вопреки некоторым мифам, Windows NT и памяти не сильно больше жрала, чем Win95/98, и с совместимостью программ у нее было неплохо. Например, более-менее все нерукожопые игры, которые работали через dos4/gw, прекрасно работали в NT, благодаря https://en.wikipedia.org/wiki/DOS_Protected_Mode_Interface - это такая технология, когда OS в себе содержит свой dos extender, и условный dos4/gw просто передает управление ему.
Windows NT 3.51(https://winworldpc.com/product/windows-nt-3x/351) - моя любимая винда. Красивый GUI, еще до-чикаго эпохи, микроядро, быстрое, и безопасное(она могла перезапустить упавший драйвер видюхи на ходу, например).
3) Санитайзеры. После их повсеместного внедрения я лично перестал бояться катить в прод. Казалось бы, при чем тут Microsoft? В Microsoft с этим всегда было туго, до-sanitizer технологии(valgrind) вообще никак не были представлены в Windows. #asan
4*) Переход на "безопасные" языки. Господа, давайте этот пункт обсудим лет через 5 - 10, когда impact уже будет очевиден :)
Короче, плохая, негодная статья, которая пытается представить, что MS была впереди планеты всей в борьбе с багами. Нет, это не так.
———
dash + coreutils: 35s
dash + busybox: 35s
bash + busybox: 40s
And the winner is..... Yash! https://yash.osdn.jp/index.html.en
yash + coreutils: 30s
Кстати, хороший, годный shell, я им периодически пользуюсь. В принципе, у него похожие плюсы(strict POSIX, fast, работает везде) и минусы(пишет 1 человек, непонятно будущее проекта), как и у dash, так что я пробую заменить.
———
https://browsix.org/
(тут должна быть картинка про hey dawg)
Мы сделали браузер для того, чтобы gui стоил дешево, и чтобы не нужно было разрабатывать десктопное приложение на каждый чих.
Но, вот, теперь запустили там Unix CLI. А что дальше? Qt/GTK, и потом опять браузер? Божечки, зачем.
Hardcore Software by Steven Sinofsky
061. BSoD to Watson: The Reliability Journey
"20 percent or so of most frequently occurring crashes accounted for more than 80 percent of all crashes"—our discovery of the distribution of bugs and crashes
https://www.youtube.com/watch?time_continue=203&v=Zh3Yz3PiXZw&feature=emb_logo
Прекрасный видос, я, как обычно прослоупочил.
———
https://twitter.com/proffeynman/status/1038833676962869249?lang=en
Классный алгоритм, всегда им пользовался, теперь знаю, кто автор, и как называется.
———
Факир был пьян, фокус не удался.
yash отлично справляется с configure скриптами, но валится на каком-то bash-изме в libtool.
eval 'f ( X "" )' - что это? по мне так yash прав, что missing ), потому что f( - начало определения функции.
Видимо, автор dash это закостылял, потому что dash какое-то время был дефолтным shell в ubuntu(про сейчас не знаю). Без этого костыля #autohell проекты не собираются.
На закуску - автор yash упоролся, и переписывает его на Rust. https://github.com/magicant/yash-rs/issues
Вот зачем, зачем переписывать то, что уже написано и работает? Я там понимаю, если бы он фич хотел досыпать, но он же опять пишет posix shell.
———
https://botondballo.wordpress.com/2022/01/03/2021-c-standardization-highlights/
range-based for-loop аккуратно обошли стороной. C++ doomed.
———
Intel отчаялась победить шедулер #sched в Linux, и теперь CPU просто сам говорит - "пошедули чего-нить на меня", или "я перегрет" https://www.tomshardware.com/news/intel-alder-lake-thread-director-support-coming-to-linux
А чо, норм тема, производитель процов явно же лучше знает, как нагрузить его поделие полезной работой.
Прекрасный видос, я, как обычно прослоупочил.
———
https://twitter.com/proffeynman/status/1038833676962869249?lang=en
Классный алгоритм, всегда им пользовался, теперь знаю, кто автор, и как называется.
———
Факир был пьян, фокус не удался.
yash отлично справляется с configure скриптами, но валится на каком-то bash-изме в libtool.
eval 'f ( X "" )' - что это? по мне так yash прав, что missing ), потому что f( - начало определения функции.
Видимо, автор dash это закостылял, потому что dash какое-то время был дефолтным shell в ubuntu(про сейчас не знаю). Без этого костыля #autohell проекты не собираются.
На закуску - автор yash упоролся, и переписывает его на Rust. https://github.com/magicant/yash-rs/issues
Вот зачем, зачем переписывать то, что уже написано и работает? Я там понимаю, если бы он фич хотел досыпать, но он же опять пишет posix shell.
———
https://botondballo.wordpress.com/2022/01/03/2021-c-standardization-highlights/
range-based for-loop аккуратно обошли стороной. C++ doomed.
———
Intel отчаялась победить шедулер #sched в Linux, и теперь CPU просто сам говорит - "пошедули чего-нить на меня", или "я перегрет" https://www.tomshardware.com/news/intel-alder-lake-thread-director-support-coming-to-linux
А чо, норм тема, производитель процов явно же лучше знает, как нагрузить его поделие полезной работой.
YouTube
Alternative Math | Short Film
A well meaning math teacher finds herself trumped by a post-fact America.