when #openbsd 7.7 comes out, i hope my many packages doesn't blow up when i pkg_add -u on the shared pc that me and my partner use. I don't usually have many packages installed on my #openbsd boxes, so I'm worried pkg_add will complain. I've no reason to assume things will go wrong other than a personal history of maintaining complex #linux deployments. i've done release upgrades smoothly in the past, just not with as many pkgs. I hope this upgrade goes well, even if theres lots of packages

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

#OpenSSH 10.0 has been released (#SSH / #SecureShell / #OpenBSD) https://openssh.com/

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.

wait cos smtp technically shouldn't need the internet to work, I wonder if I could create an offline flat mesh of smtp relays using #openbsd's #opensmtpd that all share a nfs with a mbox in it to store a record of all sent messages and their metadata to implement an offline, self-hostable, blockchain-like-distributed-database-thingy over smtp.

lets re-implement #arpanet for the 21st century using...email

brb gonna repurpose a bunch of old #thinkpads for this stupid idea...maybe

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/

I started porting a game server to #OpenBSD then realized that OpenBSD doesn't have MySQL 9.1 in ports, so I'm going to see if I can get it working in #FreeBSD. At least I'll be able to jail it.

Two things I've learned about my UX preferences while playing around with #openbsd and #fvwm and watching a few videos on the #CosmicDesktopEnvironment

1. I prefer full screen apps on smaller displays. (Including laptops) I blame cell phones for this preference.

2. When having more than one window on a screen I prefer the way fvwm or cosmic handle it by changing the color on the window pane or frame. This eliminates the need for often hard to make out visually window shadows or having to tint the non active window slightly. Like Gnome is currently doing.

I wish there was a way to do the same thing in Gnome with accessibility features or even an extension for gnome shell.