@hellomiakoda nodds in agreement
I think #Flatpak, #Snap & even #AppImage suffer from the "good idea, pain and suffering in practise" problem...
@hellomiakoda nodds in agreement
I think #Flatpak, #Snap & even #AppImage suffer from the "good idea, pain and suffering in practise" problem...
@static @Noisecolor personally I think that every package should come statically compiled with it's own dependencies since #GlibC tends to constantly brick shit with minor.version updates and nonchalantly tell people to "just recompile"...
That's why I want statically-linked binaries for @OS1337 because that removes headaches...
The next GNU Tools Cauldron, taking place in Porto, Portugal, on September 26-28, 2025.
https://inbox.sourceware.org/gcc/87o6ubhn4j.fsf@oracle.com/
https://gcc.gnu.org/wiki/cauldron2025
https://gnu-tools-cauldron.org/
Some #Sourceware Project Leadership Committee members and @conservancy staff should also be there.
@ULTROS_PROFESSIONAL @mos_8502 yeah. #GlibC randomly bricks shit at minor version updates.
Their response: "JuSt ReCoMpIlE!"
@mrmasterkeyboard @landley exactly that is literally the Problem with #native #Linux games:
@mrmasterkeyboard @landley My choice of @musl for @OS1337 is because I want my stuff to be statically linked and not every minor update to have the risk to brick shit, because #GlibC is notorious for that since the #GNU project are nonchalantly thinking "just recompile it" is a valid excuse.
I mean, we all 'loved' to live in a world where this wasn't the case but if I were to like deal with a vocoder for MELP, AMBE or TWELP I'm pretty shure I'd never ever be allowed to distribute it's source code, even for "clients exempted from the need to obtain licensing"...
@lmemsm basically the Idea behind it is to be a brutally simple #toybox + #musl / #linux distro that grew out of the necessity for me to actually think about #firmware for some projects.
Basically I want something that is so simple and auditable that it's practical to make it pass any #verification demands for #SecureTerminal|s in #CriticalInfrastructure and #Communications.
Not to mention a #GNUfree - #Linux distro is the way to go if I want that thing to not get bricked constantly by minor #GlibC-changes...
I hope that answers your question...
All I want is just a collection of #binutils, #GCC, #llvm+#clang, #glibc and #musl that are "free standing" / relocatable, which I can pack into a #squashfs image to carry around to my various development machines.
You'd think that for something as fundamental as compiler infrastructure with over 60 years of knowledge, the whole bootstrapping and bringup process would have been super streamlined, or at least mostly pain free by now.
Yeah, about that. IYKYK
Solved!
This was a pretty "interesting" bug. Remember when I invented a way to implement #async / #await in #C, for jobs running on a threadpool. Back then I said it only works when completion of the task resumes execution on the *same* pool thread.
Trying to improve overall performance, I found the complex logic to identify the thread job to put on a pool thread a real deal-breaker. Just having one single MPMC queue with a single semaphore for all pool threads to wait on is a lot more efficient. But then, a job continued after an awaited task will resume on a "random" thread.
It theoretically works by making sure to restore the CORRECT context (the original one of the pool thread) every time after executing a job, whether partially (up to the next await) or completely.
Only it didn't, at least here on #FreeBSD, and I finally understood the reason for this was that I was using #TLS (thread-local storage) to find the context to restore.
Well, most architectures store a pointer to the current thread metadata in a register. #POSIX user #context #switching saves and restores registers. I found a source claiming that the #Linux (#glibc) implementation explicitly does NOT include the register holding a thread pointer. Obviously, #FreeBSD's implementation DOES include it. POSIX doesn't have to say anything about that.
In short, avoiding TLS accesses when running with a custom context solved the crash.
@MichaelRoss something I have been trying to look for is a #Linux #ls that isn't depending on #glibc or another #libc implementation, the reason is there was some malware that attached itself to glibc and prevented you to see the directories and files it used and also the process directory in /proc
Had you a ls that wasn't built with glibc, then all the files and directories would be listed.
Debian LTS contributors released 46 Debian LTS Advisories about security updates for various packages in April 2025.
These include critical security bug fixes for jetty9, zabbix and glibc and more. Also several LTS contributors prepared packages for the recent point release of current stable Debian 12, with many prepared in conjunction with related LTS updates of the same packages.
Read more about this in our monthly report for April here: https://www.freexian.com/blog/debian-lts-report-2025-04/
This work is funded by Freexian's Debian LTS offering.
Your organization too can sponsor the Debian LTS (https://www.freexian.com/lts/debian/) and join the esteemed list of sponsors in the monthly report.
Steam Will Stop Working on Outdated Linux Systems This August | Linuxiac
「 According to a recent announcement, the Steam client will no longer run on any distribution with a GNU C Library (glibc) version older than 2.31 starting August 15, 2025.
Users who stay on an outdated toolchain will find not only Steam but also any purchased games unable to launch until the underlying operating system is upgraded 」
https://linuxiac.com/steam-will-stop-working-on-outdated-linux-systems-this-august/
@cleverboi
Boi, I'm not knowledgeable about glibc, but I do use and like Pop!_Os, so I'm boosting your twt in an effort to secure you an answer.
I don't know your use case, so I have no clue why you'd be having this software issue with Pop!_Os!
Hope someone else can be of actual assistance.
#Linux #GLIBC #Pop!_Os #PopOs
#tek 0.2.0 out now: https://codeberg.org/unspeaker/tek/releases/tag/0.2.0
it's buggy as hell, and about half the features i've showcased previously are disabled for now. but, more importantly, i've managed to build it as a single binary that you should be able to run on any #linux with #glibc and #jack... let me know what happens!
@landley @burnoutqueen Yeah...
#GPLv3 is a desaster as it's 99% ideology and 1% license text and alongside #AGPLv3 completely ignores the reality of how #licensing and #patents and #IP works.
And on the flipside we basically get "source available" stuff like #SSPL which only serves as a means to commit #AssetDenial and monopolize commercial offerings...
@Jessica @BrodieOnLinux +9001%
The reason I don't use #GlibC on @OS1337 is because it's constantly breaking userspace…
The glibc 2.41 update has been causing problems for Linux gaming https://www.gamingonlinux.com/2025/02/the-glibc-2-41-update-has-been-causing-problems-for-linux-gaming/
@krishean that's not how #systemd works.
SystemD was created because #SysVinit was shit and noone fixed it or made something better.
#Wayland is the future as #Xorg is being #EoL'd.
For the shitty #GlibC we have alternatives like #bionic and espechally #musl!
@mgorny that's because #GlibC is garbage and maintained by #Stallmanist|is assholes that proudly brick userspace with minor version updates and tell people to "just recompile from source" as a valid strategy...
@dalias @owen @aphyr nodds in agreement
I want stuff to be portable and reproduceable!
The whole #PainAndFrustration with #LinuxFromScratch, bloated #GNUtils and #GlibC constantly breaking shit (among other things) is why I started @OS1337 …