@icedquinn @tknarr @navi sadly you are correct to the point that @fuchsiii jokingly says that:

#Win32 / #Win64 is the most stable #ABI on #Linux.

Personally, I am so frustrated about this situation that I mandate all applications for @OS1337 to ship their dependencies with themselves statically linked.

• Making it the problem of the Softwares' Maintainers!
  • If they use some stuff that doesn't allow that, then that's their problem…
• But then again I also statically compile against #musl because #GlibC is notorious for bricking shit with minor updates and anything #GNU seems to be run by folks who think: 'Just recompile it with the new version!' is a valid answer for their bullshit.

How is it possible that ubuntu 22.04 use an older glibc version than the Debian version it's based on? #2204 #c++ #glibc

https://askubuntu.com/q/1564816/612

This Week In Security: Getting Back Up to Speed

https://fed.brid.gy/r/https://hackaday.com/2026/03/06/this-week-in-security-getting-back-up-to-speed/

Почему функции rand и lrand48 из glibc годятся только для Тетриса: о случайных числах всерьёз

Функцию rand из стандартной библиотеки языка Си для генерации псевдослучайных чисел, наверное, не ругал только ленивый. В довольно известном докладе Rand considered harmful рассказывалось о проблемах с переносимостью, ограниченным диапазоном, многопоточностью, качеством и т.п. Иногда в учебниках упоминают о том, что алгоритм в rand может быть не очень качественным, иметь проблемы с младшими битами, периодом, прохождением статистических тестов. Но крайне редко можно увидеть разбор конкретных критериев, выявляющих дефекты генераторов. В этой статье я постараюсь наглядно показать не просто отдельные недостатки rand , lrand48 и random из glibc, но их полную непригодность для каких-либо вычислений в принципе. Также вы увидите превосходство поточных шифров над minstd , линейным конгруэнтным генератором из 1980-х, не только в качестве, но и в производительности.

https://habr.com/ru/articles/1005118/

#Генераторы_псевдослучайных_чисел #glibc #си #c++ #математическая_статистика #математическое_моделирование #тестирование_по

#linuxfromscratch installation completed

Yes #UEFI is still in BLFS.
That's very very BAD in 2026

The only "big" problem in Chi's run was https://www.linuxfromscratch.org/blfs/view/systemd/postlfs/efivar.html

the patch that's needed so it builds clean with glibc 2.43 can be found here

https://github.com/rhboot/efivar/pull/292.patch

all in all https://linuxfromscratch.org/lfs/view/13.0-systemd-rc1/ seems to be in good shape

#linux #efivar #glibc

GNU Toolchain Office Hours starting soon!

Europe/Americas: Thursday, Feb 19 at 8:00 AM PST / 11:00 AM EST / 16:00 CET

https://gcc.gnu.org/wiki/OfficeHours

#GNUToolchain #OpenSource #GCC #GDB #GLIBC

#TIL: #glibc's resolv.conf has an option, single-request, which disables parallel DNS requests for IPv4/6 and makes them sequential. This is a fix for "DNS servers [that] cannot handle these queries properly".

But, after a bit of digging w/ #wireshark, the issue seems to be that by default glibc makes those parallel requests USING THE SAME UDP SOURCE PORT. 🤦‍♂️ So buggy or overzealous NAT/firewall rules are likely causing the 2nd response to get dropped.

+1 port >> +1 network round trip latency.

#ilovefs #ilovefs26 #ilovefreesoftwareday

Thank you to these Free Software projects I use every day (and to those I know I'm forgetting):
#bash #btrfs #glibc #gnucoreutils #guile #htop #keyd #kitty #labwc #librewolf #man #mvp #python #sudo #tmux #tty-clock #vim #voidlinux #waybar #zathura