I'm not saying OpenBSD is a modern-day miracle, but I'm not saying it's not

Ok, this is confusing...

When I run #NeoVim from any terminal, it has a white background, just like my terminal.

When I run neovim from a terminal started by launcher like #rofi or #fuzzel, it has a gray background.

This is both in #Debian linux + #Swaywm and #OpenBSD + #i3wm.

So confuzzled.

So, there we are: #swad has its second credentials checker module, using #password #files, partially #apache #htpasswd compatible (only #bcrypt, using #OpenBSD's code).

https://github.com/Zirias/swad/commit/385bc5286c607c7220067844c37bc5eb6cb6c18c

Graphed and measured: running TCP input in parallel #openbsd
https://undeadly.org/cgi?action=article;sid=20250418114827

Graphed and measured: running TCP input in parallel https://www.undeadly.org/cgi?action=article;sid=20250418114827 #openbsd #tcp #networking #parallel #fasterpackets #freesoftware #unixlike #libresoftware

Our plan for the long Easter break is to take another step towards owning our own data by setting up a NextCloud server at home. At this point, it's a proof of concept, and my plan is to run the server on OpenBSD as I have done experience with the OS. I see there's an unofficial install guide on the NextCloud website but the BSD's are not officially supported.

Just wondering if anyone has any real world experience of NextCloud on OpenBSD that could share their experience.

I need some advise: Is there a good portable and free (really free, not GPL!) #implementation of #bcrypt in #C around?

There's #OpenBSD source I could use, but integrating that would probably be quite a hassle...

Background: I want to start creating a second credential checker for #swad using files. And it probably makes sense to support a sane subset of #Apache's #htpasswd format here. Looking at the docs:
https://httpd.apache.org/docs/current/misc/password_encryptions.html
... the "sane subset" seems to be just bcrypt. *MAYBE* also this apache-specific flavor of "iterated" MD5, although that sounds a bit fishy ...

Next #swad improvement: Make sure to #wipe #passwords from RAM directly after used. That's more of a #security precaution, because there *should* be no way how an attacker can access a running process' memory, but you never know which bugs surface .

Unexpectedly, that posed #portability issues. #C11 has #memset_s ... a pretty weird function, but suitable for wiping. It's there on #FreeBSD and on #OpenBSD. Not on #NetBSD though. But NetBSD offers the much saner #C23 function #memset_explicit. Looking at #Linux, there's neither. But there is the (non-standard!) #explicit_bzero .. and with glibc, it requires _DEFAULT_SOURCE to be defined as soon as you compile with a C standard version given to the compiler. This function exists on some other systems as well, but there's confusion whether it should be declared in string.h or strings.h.

Here's the full set of compile-tests I'm now doing, only to find the best way to really erase memory:
https://github.com/Zirias/swad/blob/master/src/bin/swad/swad.mk#L6

And if none of these functions is found, swad uses the "hacky" way that most likely works as well: Access the normal memset function via a volatile pointer.

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

With this spring's (or autumn's) #OpenBSD release creeping ever closer (see https://www.openbsd.org/77.html filling out in near real time), you can prepare for the event by by reading "You Have Installed OpenBSD. Now For The Daily Tasks." https://nxdomain.no/~peter/openbsd_installed_now_for_the_daily_tasks.html.

Enjoy #OpenBSD!

One of my (very few) annoyances with #OpenBSD is that, in the event of total power failure, the filesystem can be left in an inconsistent state and require manual intervention to fix it before the machine will boot.

I'd find it more annoying, apart from the fact that I have to use the command `fsck_ffs` which perfectly mirrors my own sentiments when it occurs :-D

IO performance benchmarking on #openbsd by @sizeofvoid

Also features a comparison with #linux IO performance

https://rsadowski.de/posts/2025/fio_simple_benckmarking/

#OpenBSD IO benchmarking: How Many Jobs Are Worth It?

https://rsadowski.de/posts/2025/fio_simple_benckmarking/

#LispyGopherClimate #lisp #ai #peertube
https://communitymedia.video/w/7KpDL8dmSMN7zH6TxEgQbb

@kentpitman #haiku

Resurrected Sandewall's #softwareIndividuals from 2014.

This episode is dedicated to general purpose interaction in the software individual / #CAISOR paradigm.

Next will be porting the dynamicwindows zetalisp zwei to McCLIM #commonlisp.

@prahou #unix_surrealism next #openbsd release art??

Also @pesco and @dougmerritt on IPE '84

co guest and join in on #lambdaMOO as always!

@mdhughes @nosrednayduj @sacha