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

Вышла новая версия самого лучшего frontend к LaTeX.

Я в нем писал курсачи, и диплом тоже писал в нем. Мне нравится его подход - ты видишь на экране очень примерное представление того, что ты хочешь получить "на самом деле", удобное для редактирования. А потом, когда ты затеешь финальный рендеринг через latex, ты получишь очень достойный результат "из коробки".

Думал, оно умерно, а вот нет, не умерло.

Годная вещь.

https://gitlab.freedesktop.org/1

gitlab от freedesktop лежит проходит техосмотр уже второй день. А я даже и не заметил, потому что распределенный кеш исходников.

Судя по сайту, обновить gitlab - это какая-то дико сложная ручная задача.

Проклятый #ddv написал пост про то, как в sr.ht все было плохо, но теперь, просто обязательно, будет хорошо!

https://sourcehut.org/blog/2024-06-04-status-and-plans/

Почему хорошо?

* Kubernetes (self managed, ага)

* Ceph (self managed, AFAIK)

* GraphQL

Есть какие-то интересные цифры про текущую инфраструткуру (10 EOL серверов общей стоимостью 50к, очень странно и дорого, за EOL сервера. Может, дисков туда напихали много)

В общем, хорошо, что у меня на этом васянском хостинге больше ничего нет.

Подумываю о том, чтобы поднять свой git, потому что тащить конфигурацию с github, когда прилегла сеть, и тебе нужно обновить конфиг, чтобы починить сеть, то еще удовольствие.

Витриной, конечно, останется github.

Коду #Kent веры нет.

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

Иначе я не могу объяснить, что у меня bache (не путать с bcachefs) cli падает в кору:

Jun  4 09:56:33 lab1 user.notice dmesg: [   36.169640] bcache[1182]: segfault a
t 8 ip 00000000002ab8ea sp 00007ffefda1a460 error 4 in bcache[236000+94000] lik
ely on CPU 5 (core 5, socket 0)
Jun  4 09:56:33 lab1 user.notice dmesg: [   36.170440] Code: b6 80 10 81 21 00
41 21 c0 41 83 f8 01 b8 02 00 00 00 83 d8 00 5d c3 cc cc cc cc cc cc cc cc cc 5
5 48 89 e5 41 56 53 48 89 fb <8b> 7f 08 e8 8e bb 01 00 41 89 c6 48 89 df e8 c3
d2 01 00 44 89 f0

Полез смотреть, а там полный разброд и шатание - Кент забросил эту тулзу, и ее теперь пишет какой-то левый чувак.

Ну такое.

#lab #home_lab

https://t.me/itpgchannel/1827
https://t.me/itpgchannel/1887

(по ссылкам - определение того, что я называю своими "датацентрами")

Тополиный пух, жара, и вот это вот все.

Первый датацентр приходится отключать, так как не выдерживает кондиционирование. Дело дошло ажно до того, что слетел контроллер SATA (правда, после охлаждения и парочки ребутов снова поднялся).

С другой стороны, два других датацентра справляются с CI на ура, #minio/etcd, вроде, тоже работают, но уже без запаса.

Принудительные учения, ага.

От следующей новости у меня глаза полезли на затылок, потому что как такое вообще может быть?

https://www.phoronix.com/news/STF-GNU-libmicrohttpd

300к на развитие libmicrohttpd.

Слышали про такую библиотеку?

Правильно, и никто не слышал, потому что клиентов у нее всего ничего - https://archlinux.org/packages/core/x86_64/libmicrohttpd/ И это несмотря на 15+ лет разработки.

Клиентов у нее нет, потому что:

* это встраиваемый http server
* под лицензией LGPL
* мало фич (http/2, http/3 - не, не слышали)

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

Но фонд, который выдал грант, пишет, что пользователей довольно дофига:

https://www.sovereigntechfund.de/tech/libmicrohttpd

"Thousands of projects and businesses use libmicrohttpd, including NASA (Earth Observation satellite data distribution), Sony televisions, security cameras, medical testing laboratories, and numerous Free Software projects. To name just a few: GNUnet, Kodi, GNU Taler, Retroshare, P4P Portal, Gnome Music Player Client CallHome, Open Lighting Architecture, and systemd (journal gatewayd)" (ого какие проекты! про некоторые я даже слышал!)

Я не знаю, есть большое количество встраиваемых http серверов, написанных на более безопасных языках, чем C (Rust/C++). Вот, надо брать сишный биндинг к такой библиотеке (желательно, идущей под MIT/Apache2), и не связываться с поделием от GNU никогда.

Наверное, распил какой-то, или я ничего не понимаю в этой жизни.

Про acme.sh, эксплойты и костыли

Случайно наткнулся на
https://github.com/acmesh-official/acme.sh/issues/4659
(кстати, этот issue открыли ровно год назад 🎉)

История очень эпичная:
- какая-то китайская компания занимается перепродажей сертификатов и захотела сделать бесплатную автоматическую выдачу сертификатов через ACME, как Let's Encrypt
- но увы, сама компания не являются CA и не может выписывать сертификаты, поэтому полностью протокол ACME реализовать не может
- вместо этого китайцы используют RCE-эксплойт (оно же — удаленное выполнение произвольного кода) в acme.sh, который позволяет им вставить костыль в процесс выдачи сертификата. При этом они никакого вредоносного кода у клиентов не исполняют (скорее всего), но варварски эксплуатируют страшную дыру в безопасности
- клиентов, конечно же, просят юзать только acme.sh для выписывания сертификатов
- через некоторое время эта вся история с эксплойтом вскрывается, и появляется issue на гитхабе (ссылку на который я уже давал в самом начале поста)
- далее китайскую компанию, по всей видимости, жестко DDoS'ят (что можно узнать из комментов к issue)
- потом в issue приходит представитель этой самой компании и жалуется, что (далее прямая цитата, орфография сохранена)

we provides HiCA for non profit purpose, to provide ssl for free (RSA). We even donated 1000 USD to acme.sh last year to support the community developers, Except us any CA or reseller did this?

и сообщает, что

finally, we closed HiCA project and keep this before the community investigation finished.

- дыру с RCE, конечно же, в конце концов поправили

Мораль всей этой истории мне придумывать лень, оставлю это в качестве упражнения читателям 🐳 Могу лишь сказать, что использовать уязвимости для того, чтобы что-то закостылить или обойти — не самая удачная идея :)

#llvmweekly

http://msinilo.pl/blog2/post/compilers-are-too-smart/

Текст про то, что чувак дизассемблировал какую-то простую функцию, состоящую из какого-то довольно простого вызова в libc++, и охуел удивился увиденному.

Как выяснилось, авторы libc++ заложились на то, что clang проведет определенную оптимизацию вот такого блока кода:

inline _LIBCPP_HIDE_FROM_ABI size_t __constrain_hash(size_t __h, size_t __bc) {
  return !(__bc & (__bc - 1)) ? __h & (__bc - 1) : (__h < __bc ? __h : __h % __bc);
}

И заменит его на popcount (что не произошло в случае автора этого текста).

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

Ну вот нужен тебе popcount, проверь, что он есть, и позови напрямую, даже через какой-нить builtin/intrinsic, чтобы у людей опыт использования либы был более-менее консистентным.

UPD: меня вот тут поправляют, что я неверно все понял - https://t.me/c/1469934025/27643

https://www.phoronix.com/review/intel-meteorlake-epp-perf

TL;DR - разработчики из Intel потюнили три константы в своем драйвере intel_pstate, что привело к ускорению вообще всего, суммарно процентов на 7, без ухудшения в потреблении энергии.

Интересно конечно, как выбирали начальные параметры.

Кстати, раз уж речь зашла про энергопотребление, то я какое-то время назад перешел на amd_pstate, c автоматической подстройкой (как это делается можно подсмотреть в https://wiki.archlinux.org/title/CPU_frequency_scaling), и всем советую попробовать сделать так же, потому что ноутбук живет дольше, греется меньше, да и вообще, умеет уходить в довольно низкие скорости CPU:

cpu MHz: 400.000

До этого был то ли acpi, то ли ccpc, (+ schedutil в качестве governor) и ниже 1200MHz они мой CPU не замедляли.

#scheduler

Расширяемый шедулер едет в ядро - https://www.phoronix.com/news/Linux-6.11-Extensible-Scheduler https://lwn.net/Articles/978007/
https://www.opennet.ru/opennews/art.shtml?num=61354

День, когда у меня перестанет тормозить браузер, все ближе и ближе, what a day to be alive!

Оказывается, swift умеет в статическую линковку, поверх musl - https://www.swift.org/documentation/articles/static-linux-getting-started.html

Pros of static linking:

No runtime overhead.
Only include code from libraries that is actually needed.
No need for separately installed dynamic libraries.
No versioning issues at runtime.

Cons of static linking:

Programs cannot share code (higher overall memory usage).
No way to update dependencies without rebuilding program.
Larger executables (though this can be offset by not having to install separate dynamic libraries).


Это несомненно хорошо, пора попробовать запилить его поддержку.

США запрещают предоставление услуг в сфере программного обеспечения и IT любому лицу на территории России.

https://3dnews.ru/1106385/arm-potrebovala-unichtogit-vse-noutbuki-na-chipah-qualcomm-snapdragon-x
https://habr.com/ru/news/696198/ - история вопроса

Совершенно потрясная новость, одни жадные капиталисты наехали на других жадных капиталистов.

Разные комментаторы пишут разные мнения на этот счет.

Кто-то считает, что ARM в своем праве, потому что после покупки IP Qualcomm (у Nuvia) использует этот IP не в соответствии тем лицензиям, которые были даны при разработке этого IP, а кто-то - что у Qualcomm и так своя "жирная" лицензия есть, поэтому они в своем праве использовать этот IP так, как используют.

Я же просто запасся попкорном, и слежу за этой историей.