#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!

Today, I implemented the #async / #await pattern (as known from #csharp and meanwhile quite some other languages) ...

... in good old #C!

Well, at least sort of.

* It requires some standard library support, namely #POSIX user context switching with #getcontext and friends, which was deprecated in POSIX-1.2008. But it's still available on many systems, including #FreeBSD, #NetBSD, #Linux (with #glibc). It's NOT available e.g. on #OpenBSD, or Linux with some alternative libc.

* I can't do anything about the basic language syntax, so some boilerplate comes with using it.

* It has some overhead (room for extra stacks, even extra syscalls as getcontext unfortunately also always saves/restores the signal mask)

But then ... async/await in C!

Here are the docs:
https://zirias.github.io/poser/api/latest/class_p_s_c___async_task.html

I finally eliminated the need for a dedicated #thread controlling the pam helper #process in #swad.

The building block that was still missing from #poser was a way to await some async I/O task performed on the main thread from a worker thread. So I added a class to allow exactly that. The naive implementation just signals the main thread to carry out the requested task and then waits on a #semaphore for completion, which of course blocks the worker thread.

Turns out we can actually do better, reaching similar functionality like e.g. #async / #await in C#: Release the worker thread to do other jobs while waiting. The key to this is user context switching support like offered by #POSIX-1.2001 #getcontext and friends. Unfortunately it was deprecated in POSIX-1.2008 without an obvious replacement (the docs basically say "use threads", which doesn't work for my scenario), but still lots of systems provide it, e.g. #FreeBSD, #NetBSD, #Linux (with #glibc) ...

The posercore lib now offers both implementations, prefering to use user context switching if available. It comes at a price: Every thread job now needs its private stack space (I allocated 64kiB there for now), and of course the switching takes some time as well, but that's very likely better than leaving a task idle waiting. And there's a restriction, resuming must still happen on the same thread that called the "await", so if this thread is currently busy, we have to wait a little bit longer. I still think it's a very nice solution.

In any case, the code for the PAM credential checker module looks much cleaner now (the await "magic" happens on line 174):
https://github.com/Zirias/swad/blob/57eefe93cdad0df55ebede4bd877d22e7be1a7f8/src/bin/swad/cred/pamchecker.c

I was reading this part of kab_DZ collate on glibc and something is not correct :

Link glibc 2.41-6 : https://sources.debian.org/src/glibc/2.41-6/localedata/locales/kab_DZ/

1/…

C++Now 2025 SESSION ANNOUNCEMENT: Using TLA+ to Fix a Very Difficult glibc Bug by Malte Skarupke

https://schedule.cppnow.org/session/2025/using-tla-to-fix-a-very-difficult-glibc-bug/

Register now at https://cppnow.org/registration/

The #Maneage #reproducibility system for scientific research papers that starts from a minimal POSIX-like host OS does not yet build [1] the #GNUCLibrary = #GLibC . We have a draft implementation building glibc *after* #GCC [2]; and an alternative proposal arguing that building glibc *first* and gcc second would be more long-term sustainable [[1] comment18].

Should GLibC be built first? Why (or why not)?

[1] https://savannah.nongnu.org/task/?15390
[2] https://gitlab.com/maneage/project-dev/-/blob/glibc/reproduce/software/make/core-gnu.mk#L718

@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.

• Not that I like the status-quo, but we'd rather see businesses steer clear of anything GPLv2+ or GPLv3 or worse.

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...

• I think #Linux being #GPLv2only is a good compromise and my personal gripes with #FSF & #GNUtils as well as #GlibC are something different...

Making a #Linux #Distro from the #LFN guide by MapleCircuit. (Great guy, search up the series #LinuxfromNothing and go follow him!!!)

I’m using #Musl instead of #Glibc for funsies.

I’m #Nerdy as shit, and that’s pretty cool.

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/

Most people appreciate the fact that Go programs compile statically, as it makes deploying #Go programs a lot easier. Unfortunately, they aren’t always statically compiled.

Using cgo, either in a 3rd party package or in the standard library, usually requires linking to a libc. Both net and os/user are two packages known for using cgo and requiring a libc. On most Linux systems, that leaves us with programs dynamically linking against the glibc. Usually, that’s not a problem in itself, if we deploy our programs to machines that have a glibc of a matching version. If they don’t have a matching #glibc , however, things tend to go south.
https://honnef.co/articles/statically-compiled-go-programs-always-even-with-cgo-using-musl/

The Year 2038 Problem and glibc: A Comprehensive Overview

The Year 2038 Problem, often referred to as the "Unix Y2K Problem," is a critical issue affecting software and systems that rely on 32-bit signed integers to represent time.

Read More: https://machaddr.substack.com/p/the-year-2038-problem-and-glibc-a

The GNU C Library, often referred to as "glibc," is one of the most critical components of the GNU system and Linux operating systems. It provides the fundamental system interface for C programs, offering essential services such as process control, memory allocation, and I/O handling, which enable applications to interact with the underlying operating system.

Read More: https://machaddr.substack.com/p/the-evolution-of-the-gnu-c-library

Fun project: a #memory manager for multi-lang applications (#c, #cplusplus #assembly #fortran) in which workflow management is done by #Perl. Currently allocates using either #perl strings or #glibc malloc/calloc. Other allocators #jemalloc coming soon.
https://github.com/chrisarg/task-memmanager

regreSSHion: Remote Unauthenticated Code Execution Vulnerability in OpenSSH server

https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server