This is specifically for the command-line and system tools stuff, including #nosh and #djbwares.
For anything else, including general computer programming, the non-politics account is @JdeBP and the politics account is @JdeBP. #senryu and #SlowLife tasks are at @JdeBP.
| WWW | http://jdebp.info/ |
| GitHub | https://github.com/jdebp |
| Hacker News | https://news.ycombinator.com/user?id=JdeBP |
| INSTA | @JdeBP@PixelFedApp.UK |
I knew that there was #HJKL navigation and #WASD navigation, and some of the full-screen utilities in the #nosh toolset support both.
I read that there's also QAOP, which alas contradicts the conventional use of 'q' that those utilities already have, and ESDF which alas overlaps WASD.
One cannot be all things to all people, and it seems excessive to make this configurable somehow when they're only limited-use bonuses over just using the normal arrow keys.
#Illumos has another #wordexp implementation (originating with Mortice-Kern, no less!) that expects a Korn (93) shell and uses its printf (and set -o), which might be tweakable to function with #OpenBSD's PD Korn shell; but like the GNU C library licence the Sun CDDL would likely be a problem.
So if one is looking for "easily", where one just imports a compatibly-licenced and #KornShell-compatible existing implementation, the answer seems to be "No.".
Could #OpenBSD easily be improved to provide the standard #wordexp? It's a tricky one.
The FreeBSD and NetBSD implementations rely on sh being the Almquist shell with an undocumented wordexp builtin, but sh is a Korn shell variant on OpenBSD.
The GNU C library is not compatibly licensed. So its other problems are skippable.
The musl C library is MIT licensed and hands over to sh's printf. But OpenBSD has not taken anything from #musl before, as far as I can see.
Examples of sound(4) on #FreeBSD are merged: https://github.com/freebsd/freebsd-src/commit/6a569666868b36f5f436eea9d66789b6df191b8a
Examples are:
- simple (just read/write in a loop)
- select
- poll
- kqueue
The hardest and most flexible way of handling sound device remans: memory mapped. That's what I'm working on, next.
Also, there are existing examples in the same directory for listing sound devices and handling midi. I really hope that next generation of audio developers on FreeBSD will find it extremely easy to get started. I started learning about OSS in 2018, and this last remaining example will put an end to my research. After that, I want to finally work on what actually started all this endeavor: my own DAW.
I'm sure I've done this before....
I have four devices: 2x 2TB and 2x 1TB
I could concatenate a 1TB and a 2TB together, then mirror over both.
It can survive one device dying. However, it seems like an ugly risky hack.
But it's not. It's the same risk level, is it not, as 4x 2TB drives in the same configuration. Right?
I have just made a couple of adjustments to my #Unscii fork.
Line drawing should now line up when using the PET8 and PET16 fonts. And some arrows that were mis-mapped in a couple of the others, because of 1963 ASCII, have been fixed.
Just for fun I created a Shavian QWERTY keyboard map for #FreeBSD.
The hard part turned out to be that I had to work from pictures of layout diagrams, and tiny ones at that, cross-referencing them by eye against a Unicode chart. No-one has a text list of what Shavian alphabet characters go with what keys.
I named it gb-shaw, of course.
Dear 21st century new GOPHER client writers:
It has been 32 years. You can assume that some people speak GOPHER+ now.
https://github.com/gopher-protocol/gopher-plus/blob/main/gopherplus.md
Send those TABs.
meka
Dan Langille
Chris Siebenmann