Would appreciate if someone could help me test a port of Pony programming language to NetBSD. So far there are some weird app segfaults that might or might not be related to a rumored bug with Ryzen support (as hinted in #netbsd channel on IRC). I do have only Ryzen, and thus, to test the hypothesis, I need someone who has NetBSD installed on bare metal (not in VM) with Intel CPU (x86_64).

Not just release announcements this week.

• NYCBUG is down today for a significant hardware move.
• FOSDEM 2022 is going to have a BSD Devroom.  It’s online, so you can submit prerecorded talks – submissions due December 31.
• Valuable News – 2021/11/29.
• GhostBSD 21.11.24 ISO is now available.
• mfs: sometimes useful?
• Exploring NetBSD’s msgs(1).  (via)
• Review: Netgate 6100.
• FreeBSD article writers needed.  I’ve linked to Klara Systems before.
• Speaking of which, UNIX Wars – The Battle for Standards.
• New Test System.  OpenBSD storage book is next apparently.
• HardenedBSD November 2021 Status Report.
• doas insults.  This is a gem.  (via)
• The previous link led me to 9front’s theo.
• Simple network dashboard with vnstat.
• The state of Steam on OpenBSD.
• Logitech MX Keys and MX Master on OpenBSD using Logi Bolt.
• OpenBSD Webzine #5.

[ About my public-facing work ]

Starting now, I’m moving my monthly posts from Patreon to my own website here. Why?

1. I prefer to own my data
2. There are many ways (Patreon merely one among them) in which people can fund my public-facing work

My corporate work focuses on learning together, experientially. My public-facing work is similar: I’m creating learning experiences, Open Source code, and combinations thereof — at present, like so:

• Packaging third-party software for a cross-platform Unix package manager
• Developing an email server
• Fixing bugs and adding features to a (mostly) static site generator
• Facilitating ensemble/mob programming sessions
• Streaming solo programming sessions
• Organizing meetups about programming and Agile

For more, see crowdfunding. I’m grateful for your support.

Experiences

Held our final Legacy Open Source Fridays ensemble session of 2021. Started back up with streaming my solo programming sessions on Twitch, mostly pkgsrc-related so far. Improving my stream a bit each time.

For Jersey City Java, experimented with having a vendor present their product: a brief introduction to the tool, followed by programming together with Pejman Ghorbanzade. Glad we tried it. If we do another vendor session sometime, this’ll be how.

Building momentum with Southern Connecticut Agile, our second meetup was an extremely well liked conversation with Esther Derby and Matthew Carlson. We’ll skip December (too much holiday stuff), though JC-JUG’s session will be of interest. I’m excited for our January SoCTAgile speaker.

Build farm

VirtualBox 6.1.30 fixed the macOS Monterey troubles I encountered last month.

Upgrading Devuan 3.1 to 4.0 was straightforward, as was updating Ubuntu aarch64 to 21.10.

After much reading and trying stuff, bringing up a 2007 MacBook (64-bit system, 32-bit EFI) with Lubuntu 21.10 was ultimately uneventful. It’s no speed demon. I doubt I’ll keep it running. But the tricks I’ve just learned should apply to my original 2006 Mac Pro, boosted many years ago with SSD and lots of RAM and needing only an OS that can be kept current. In the meantime, a cursory build of my usual packages turned up a build failure in libspf2.

pkgsrc fixes

• Doing cross-platform testing of an Ubuntu 21.10 fix for libspf2 (works nearly everywhere else, but needs more fixing on OpenBSD and Void)
• Reviewed a fix needed in my cross-platform build environment, now awaiting commit by the author
• lighttpd: upstream patch for use-after-free
• libhighlight: bump required API version to fix runtime errors seen on wiki.netbsd.org
• ikiwiki: provide pkgsrc-compatible default values for configurable paths to fix runtime errors seen on wiki.netbsd.org
• Linux with non-executable glibc (such as Ubuntu/aarch64 21.10): fall back to detecting GLIBC_VERSION another way
• qmail and djbdns: catch up to pkgsrc’s switch from RMD160 to BLAKE2s hashes
• gdk-pixbuf2: fix macOS build
• ucspi-tools: fix Linux build
• bootstrap: note that Solaris 11 works

pkgsrc updates

• mob to 2.1.0
• texttest to 4.0.8
• p5-App-Sqitch to 1.2.0
• py-approvaltests to 3.1.0
• getmail to 5.16

pkgsrc additions

• ucspi-udp
• tcpexec
• fd-proxy
• pikchr
• AusweisApp2 (to pkgsrc-wip for further attention)
• dstp (also to pkgsrc-wip)

notqmail

Legacy Open Source Fridays has produced a few pull requests which we’re still working through. I made some progress on getting Add tests for qmail-send:job_*() functions past the Solaris autobuilds.

Legacy Open Source Fridays has also produced a few people with motivation to continue programming notqmail. I had not imagined this possibility, and am gratified that it’s happened.

ikiwiki

My motivation for packaging pikchr was to be able to integrate it into ikiwiki. Ikiwiki already has a graphviz plugin which I’ve been using to generate somewhat explanatory diagrams of acceptutils — but I’m not thrilled with my diagrams, pikchr appears designed to run in precisely this kind of context, and maybe I’ll like it better. When I write the pikchr plugin for ikiwiki, it’ll be streamed (subscribe to my Twitch). In the meantime, you can watch me create the pikchr package.

Interesting post appeared on the Usenet.

can you help me with my compile error ? ;p

Relatively quiet this week for BSD items, but it’s a holiday week in the US.

• Valuable News – 2021/11/22.
• Project Report: Add support for chdir(2) support in posix_spawn(3).
• Why V7 Unix matters so much.
• Wired XBox 360 Controller minor issue.
• Torn between getting a used thinkpad vs a new Chromebook.
• OpenZFS 3.0 Introduced at Developer Summit.
• OctoPkg: A Great GUI Package Manager In FreeBSD.  (via)
• How to Access Your Modem’s Web Interface with OPNsense.  (via)
• Where in the Stack?
• OpenBSD on the VIA Eden X2 powered HP t510 Thin Client.

This post was written by Piyush Sachdeva:

Abstract

The primary goal of the project was to extend posix_spawn(3) to include chdir(2) for the newly created child process. Two functions were supposed to be implemented, namely posix_spawn_file_actions_addchdir() and posix_spawn_file_actions_addfchdir(), to support both chdir(2) and fchdir(2) respectively. posix_spawn() is a POSIX standard method responsible for creating and executing new child processes.

Implementation

The original code can be found at my github tree.

The implementation plan was discussed and made with the guidance of both my mentors Martin Husemann and Joerg Sonnenberger. The plan was divided into three phases each corresponding to the specific part of The NetBSD code-base which is supposed to be touched:

User-Land

The following actions were performed in the user-land to set things up for the kernel-space.

• Add another member to the posix_spawn_file_actions_t struct i.e a union, which would hold the path to chdir to.
• Implement the two functions posix_spawn_file_actions_addchdir() and posix_spawn_file_actions_addfchdir(). These functions would:
  1. allocate memory for another posix_spawn_file_actions_t object in the posix_spawn_file_actions_t array.
  2. take the path/file descriptor from the user as an argument and make the relative field of the newly allocated file actions object, point to it.
• The final step was to add the prototypes for the two new functions to the `src/include/spawn.h' header file

Once the aforementioned changes were made, the only thing left to do was to make the kernel support these two new functions.

Kernel-Space

The following actions were performed inside the kernel space.

• The three functions in the `src/sys/kern_exec.c' file which correspond to the posix_spawn_file_actions were edited:
  • posix_spawn_fa_alloc() was adjusted to make sure that the path passed to posix_spawn_file_actions_addchdir() gets copied from the user-land to the kernel-space.
  • Similarly posix_spawn_fa_free() was adjusted to make sure that the memory allocated in case of FAE_CHDIR gets freed as well.
  • Finally, two new cases FAE_CHDIR & FAE_FCHDIR were added in the handle_posix_spawn_file_actions(). In each of the cases, a call to one of the two newly created functions (discussed in the next point) do_sys_chdir() and do_sys_fchdir() was made respectively.

  Note: At the time of code integration, a helper function was written by Christos Zoulas. This function aimed to reduce the amount of repeated code in both posix_spawn_fa__free() and posix_spawn_fa_alloc()

• Two new functions, similar to the already present sys_chdir() and sys_fchdir() in `src/sys/vfs_syscalls.c' were created. Namely do_sys_chdir() and do_sys_chdir were written with two specific thoughts in mind:
  • By default sys_chdir() and sys_fchdir() took syscallargs as a parameter. The purpose of the new functions was to replace this with const char * and an int type parameter respectively.
  • The do_sys_chdir() also replaced UIO_USERSPACE with UIO_SYSSPACE. This was done because the chdir path passed to this function already resided in the Kernel-space due to the change made in posix_spawn_fa_alloc().
• Finally, the prototypes for the newly written functions were added to the `src/sys/sys/vfs_syscalls.h' file and this file was also included in the 'sys/kern/kern_exec.c'.

Note: Similar to the above changes of user-land and kernel-space, a few tweaks were also made to `src/sys/compat/netbsd/netbsd32.h' and `netbsd32_execve.c'. This was required to help COMPAT_NETBSD32 deal with the new file actions member. However, these changes were made at the time of integration by Martin Husemann.

With most of addition of new features being done, all that remained was testing and documentation.

Testing & Documentation

• A total of ten new test cases have been added to the `src/tests/lib/libc/gen/posix_spawn/t_spawn.c' file.
• Three utility functions were also used to aid in testing. Out of the three, one new function was written and two existing functions (filesize() and empty_outfile()) from `t_fileactions.c' were used. To make sure that the 2 existing functions were shared between both the files i.e `t_spawn.c' and `t_fileactions.c' a new header and C file was created, namely `fa_spawn_utils.h' and `fa_spawn_utils.c'. Following this, the bodies of both the functions were moved from `t_fileactions.c' to `fa_spawn_utils.c' and their prototypes were added to the corresponding header file.
• The general approach that was taken to all test cases was to make posix_spawn() execute ``/bin/pwd'' and write the output to a file. Then read the file and do string comparison. The third function i.e. check_succes() was written for just this purpose.
• The ten test cases cover the following scenarios:
  • Absolute path test - for both chdir and fchdir.
  • Relative path test - for both chdir and fchdir.
  • Trying to open a file instead of directory - for both chdir and fchdir.
  • Invalid path/file descriptor (fd=-1) - for both chdir and fchdir.
  • Trying to open a directory without access permissions for chdir.
  • Opening a closed file descriptor for fchdir.
• The first 8 test cases had a lot of repetitive code. Therefore, at the time of integration, another function was created i.e spawn_chdir(). This function included a huge chunk of the common code and it did all the heavy lifting for those first 8 test cases.

Documentation:

In this matter, a complete man page is written which explains both posix_spawn_file_actions_addchdir() and posix_spawn_file_actions_addfchdir() in great detail. The content of the manual page is taken from the POSIX documentation provided to us by Robert Elz.

Issues

Since the project was well planned from the beginning, it resulted in few issues.

• The user-land was the most straight forward part of the project and I had no trouble sailing through it.
• Kernel space was where things got a bit complicated, as I had to add functionality to pre-existing functions.
• I was completely new to using atf(7) and groff(1). Therefore, it took me some time to understand the respective man pages and become comfortable with testing and documentation part.

Most of the issues faced were generally logistical. As it was my first time doing a kernel project, I was new to building from source, Virtual Machines and other things like SSH. But luckily, I had great help from my mentors and the entire NetBSD community.

Thanks

I would like to express my heartfelt gratitude to The NetBSD Foundation for giving me this opportunity and sponsoring the Project. This project would not have been possible without the constant support and encouragement of both my mentors Martin Husemann and Joerg Sonnenberger. My gratitude to Christos Zoulas who worked on the crucial part of integrating the code. A special mention to all of the other esteemed NetBSD developers, who have helped me navigate through the thick and thin of this project and have answered even my most trivial questions.

I want to configure Intel HD can netbsd run on my machine and what configurations should i make ?
CPU: Info: Quad Core model: Intel Celeron J3160 bits: 64
Graphics: Device-1: Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics
driver: i915 v: kernel
Display: x11 server: X.Org 1.20.13 driver: loaded: modesetting unloaded: fbdev,vesa
resolution: 1920x1080_60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 400 (BSW) v: 4.6 Mesa 21.2.5

Tried to install xf for intel installed xorg slim openbox but when i start slim i get a dark color and nothing at all when i start xinit i see only a white background and can't even tell there's a terminal also no mouse what is the problem ?
What configuration should i make to make it work ?
Its a slow slow mini,tiny pc i would be glad to test netbsd and see how it performs on this slow machine .

@pin, being the maintainer of this particular package has been kind enough to test it on his machine and it builds fine for him.

Does anyone know why I might be getting the below output and how this might be fixed? I can still make install after running make but when I startx the wm is significantly broken.

Any help is greatly appreciated 👍️

~/pkgsrc/wm/sdorfehs $ make
=> Bootstrap dependency digest>=20211023: found digest-20211023
=> Checksum BLAKE2s OK for sdorfehs-1.2.tar.gz
=> Checksum SHA512 OK for sdorfehs-1.2.tar.gz
===> Installing dependencies for sdorfehs-1.2
=> Tool dependency pkgconf-[0-9]*: found pkgconf-1.8.0
=> Tool dependency checkperms>=1.1: found checkperms-1.12
=> Build dependency x11-links>=1.34: found x11-links-1.34
=> Build dependency cwrappers>=20150314: found cwrappers-20180325
===> Checking for vulnerabilities in sdorfehs-1.2
===> Overriding tools for sdorfehs-1.2
===> Extracting for sdorfehs-1.2
===> Patching for sdorfehs-1.2
===> Creating toolchain wrappers for sdorfehs-1.2
===> Configuring for sdorfehs-1.2
=> Fixing paths.
=> Generating pkg-config file for builtin expat package.
=> Checking for portability problems in extracted files
===> Building for sdorfehs-1.2
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c actions.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c bar.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c communications.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c completions.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c editor.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c events.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c format.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c frame.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c globals.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c history.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c hook.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c input.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c linkedlist.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c manage.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c number.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c sbuf.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c screen.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c sdorfehs.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c split.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c utf8.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c util.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c vscreen.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c window.c
gcc -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -O2 -Wall  -Wunused -Wmissing-prototypes -Wstrict-prototypes -Wunused  -DSYSCONFDIR="\"/usr/pkg/etc/\""  `pkg-config --cflags x11 xft xrandr xtst`  -I/usr/pkg/include -I/usr/X11R7/include -I/usr/include -I/usr/X11R7/include/freetype2 -c xrandr.c
gcc -o sdorfehs actions.o bar.o communications.o completions.o editor.o events.o format.o frame.o globals.o history.o hook.o input.o linkedlist.o manage.o number.o sbuf.o screen.o sdorfehs.o split.o utf8.o util.o vscreen.o window.o xrandr.o -L/usr/pkg/lib -L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib `pkg-config --libs x11 xft xrandr xtst`
*** Please use pkgtools/verifypc to sanity check dependencies.
~/pkgsrc/wm/sdorfehs $

Note the upcoming SEMIBUG meeting.  I’ll post a reminder.

• Jenkins with FreeBSD Agents in EC2.  (via)
• Manage Kubernetes Cluster from FreeBSD with kubectl. (via)
• What if Internet stops? How to rebuild an offline federated infrastructure using OpenBSD.
• OpenBSD on Raspberry Pi 4 with Full-Disk Encryption.  (via)
• SEMIBUG is meeting November 16th, with a presentation from Deb Goodkin, head of the FreeBSD Foundation.  It’s online.
• How I ended liking GNOME.  Also, using X with the loss of one hand.
• Valuable News – 2021/11/08.
• UNIX Mouse Shootout.
• 0ad several versions behind, cant play online because of this.  Linking so I remember to play it.
• FreeBSD Documentation: Papers We Love To Read.
• go-modules.mk.
• depotdownloader issues.
• FreeBSD 12.3RC1 is out.
• OPNsense 21.7.5 released.
• OpenBSD Webzine #4.

I am pleased to announce that tcsh-6.23 is now available; this is mainly a bug fix release (after 2 years) with a couple of new features:

1. Add jobs -Z to setproctitle(3)
2. Add ln=target in LS_COLORS
3. Add a :Q modifier that preserves empty arguments

Please consult the Fixes file for a complete list of changes.

Tcsh is an enhanced version of the Berkeley C-shell that offers command line editing and completion plus many other little things that preserve the length of your fingers.

Tcsh runs on most UNIX machines, as well as Windows.

You can get tcsh from ftp://ftp.astron.com/pub/tcsh/tcsh-6.23.00.tar.gz
The latest source is on GitHub: https://github.com/tcsh-org/tcsh

RMD160 (tcsh-6.23.00.tar.gz) = 956bf3a7cf52f5e4865749d29946cf6e8d512ae3

This is a gzip (GNU zip) tar archive. If you don’t have GNU zip you can get it from ftp.gnu.org or other GNU mirrors.

I would like to thank:

• everyone who sent bug reports
• the beta team for all their help, bug fixes, and suggestions

Kind regards,
+ Kimmo

I trying to integrate application with sysrepo in NETBSD platform. Looks like sysrepo requires "pthread_mutexattr_setpshared" support.

Also, looks like NETBSD man-page lists, by default above functionality is hidden , however source code implies its not supported.

Can anyone please help me out here to confirm whether NETBSD supports pthread shared mutex between the process?

I have access to just *nix systems. Either NetBSD and/or bare Linux-based OS.

So my question comes from the fact that ADB is not widely available on all platforms, if so is very hard to install or obtain (having access to internet, get super user access, etc).

Anyways, RNDIS functionality is already offered by almost all Android devices. Allowing the phone to become a "router" will give me the option to use netcat because I can just set up a "server" and get/receive files bidirectionally, without the need of getting ADB involved.

Like this:

NetBSD
dhcpcd -n urndis0

Linux
udhcpd -i usb0

That will give me an IP within a subnet set up by Android. Something like: 192.168.32.225/24

So, essentially the phone acts as a router, giving my *nix computer an IP belonging to a subnet set up by the phone itself. I would like to just open a port on my localhost 127.0.0.1 with netcat and just transfer files.

Something like this:

On Android device:
busybox nc -v -w3 -l -p 3838

On *nix system (Linux in the example below):
nc -v -w3 **(upper higher loopdevice outside subnetted network) 127.0.0.24** 3838

And be able to access the "higher" network/loopdevice already existing within Android's own local network.

Let's assume the Android phone is another host sharing it's connection and assigning a subnet IP to my computer for that matter so my *nix box can access the internet:

My question is then: Can I use the the IP (which is within a subnet) provided by the RNDIS interface of the Android phone to access the local network of the phone itself with just standard tools in *nix?

Solution @Frédéric Loyer Thank you very much!

Wonderful, with this method there is no need for me to get adb on each computer I'm on, most of the time what I got is busybox nc and or ssh. This is perfect, with this I can even ssh into my Android without even needing an active connection on the phone itself, isn't amazing!?

Here is what I did.

# This makes my computer to request an IP to my phone.
$sudo udhcpc -i usb0

# Since I got access to busybox-only most of the time, this gives me the IP from the "router" which is the phone.

$route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.42.129  0.0.0.0         UG    0      0        0 usb0
127.0.0.1       *               255.255.255.255 UH    0      0        0 lo
192.168.42.0    *               255.255.255.0   U     0      0        0 usb0

# ifconfig output shows me the new IP assigned to usb0 on my computer.

After this is just a matter of ssh'ing onto my phone or open ports with Termux. Amazing! :)

I'm an intermediate *NIX user who has been using these OSes since 1994, but I'm not up to date.

I'm frustrated with Mint linux on my very old Dell laptop because when I open too many browser tabs it takes the whole system to such a crawl (suddenly, like a straw that breaks a camel's back) that I can't use the mouse and can't even Alt-Ctrl-F1 to get to a vtty to kill processes. I end up powerswitching the computer off.

I'm looking for an OS that keeps the essential system components running and responding even when a particular process starts grinding down into zombieland, so I could gracefully recover. I need to be able to do the following things:

• Use a wide variety of WiFi hardware (mostly USB but also built-in) on a wide variety of oddball laptop and desktop hardware.
• Read and write reliably to NTFS, hopefully with BitLocker encryption
• Read and write reliably to Ext4, hopefully including LUKS disks
• Hopefully, be able to mount and use VeraCrypt volumes
• Read and write exFAT and memory sticks in general
• Hopefully, be able to run Windows 10 in a virtual environment / Wine
• Security is important to me, but functionality comes first for this use

I'm open to any BSD, Unix or linux OS, or anything else really. I run OpenBSD on this laptop dual-boot, but it won't do all the spiffy things I need to do. This is an old Dell laptop. I'll also be running whatever new OS on an old HP laptop and a few custom-built very old desktops. I'm willing to try a few things, but want to get ideas.

This should be my "Windows replacement" OS, so as full-featured as a workstation as possible.

Are there any other linux OSes that manage system resources better so one app can't drag down the whole system?

NetBSD? FreeBSD?

Thank you! <3 <3

Somewhat short this week, but there’s several releases.

• Automatic Let’s Encrypt certificates in Apache with mod_md.
• FreeBSD audio from a perspective of a happy user.  (via)
• FreeBSD Developer Workstation Setup.
• NetBSD, CTWM, and Spleen.
• MATE 1.26.0 upgrade ready.  (GhostBSD)
• pfSense Software is 15 Today!
• Valuable News – 2021/10/11.
• OPNsense Business Edition 21.10 released.
• OpenBSD 7.0 released.

I did a macOS software update recently and was greeted with a Relocated Items.nosync folder on my desktop.

Inside was a PDF explaining what it was:

During the last macOS upgrade or file migration, some of your files couldn’t be moved to their new locations. This folder contains these files.

These configuration files were modified or customised by you, by another user or by an app. The modifications may be incompatible with the recent macOS upgrade. The modified files are in the Configuration folder, organised in subfolders named after their original locations.

To restore any of the custom configurations, compare your modifications with the configuration changes made during the macOS upgrade and combine them when possible.

There was only one affected file: /private/etc/shells. I’d echo’d the path of the OpenBSD portable Kornshell from pkgsrc into it so I could use it as my daily driver, because I’m a gentleman.

The notice above had me believing they’d replaced my config, but instead they’d retained my original file and put their desired changes into the relocated folder. A quick diff, which sounds more like a band name, showed:

12d11
< /opt/pkg/bin/oksh

I think I’ll be fine keeping that.

By Ruben Schade in Sydney, 2021-10-16.

Back in the fall of 2020, I was approached about adding Spleen to the NetBSD's xsrc repository. Needless to say, I wasn't difficult to convince, and imported Spleen 1.8.2 as font-spleen-misc. With this being done, [email protected] added all the required glue to hook the fonts to the build, and then changed the default CTWM configuration to do automatic font scaling based on screen size, and make Spleen the default font.

CTWM had previously been promoted as the default window manager on NetBSD, and saw several tweaks and improvements to make it look more modern, notably with a nice orange themed menu.

Below is a screenshot of CTWM with Spleen 8x16, running on my HP t510 Thin Client plugged to a 1600x900 monitor, showing JED, Lynx, xcalc and xv.

One last thing to note, there are now live images available in -current for amd64, and NetBSD 10 will be the first release to officially provide them. While NetBSD/evbarm has had live images for a long time now, their availability on amd64 is a much welcome addition, as this allows to easily test NetBSD's default CTWM configuration :-)

The most recent version is currently NetBSD-9.99.90-amd64-live.img.gz and can be downloaded here.

Once again, thanks to Nia for doing all of this!

It is status report season!

• ChiBUG is meeting on the 12th, virtually, at 6:30 PM Central.  “The Writing Scholar’s Guide to *BSD” is the presentation.
• OpenBSD’s pledge and unveil from Python.
• Notes on updating OpenBSD machines to current, supported versions.
• pkgsrc: how to use pkg_comp(8) to automate package builds in a sandbox.  (via)
• What every IT person needs to know about OpenBSD.  Glosses over OpenBSD’s fork, but that’s probably OK.
• HelloDesktop being ported from helloSystem back to FreeBSD ports.  (via)
• The OpenBSD Webzine.  (via)
• Celeste on OpenBSD with Sound – Early Stage.
• Spelling Fixes — Some Advice.
• HardenedBSD September 2021 Status Report.
• GhostBSD 21.09.29 ISO Now Available.
• Toolchains adventures – Q3 2021.
• Valuable News – 2021/10/04.

I've been keeping myself busy since I posted the "Diving into toolchains" article at the beginning of June, so here is an update detailing what I've been up to during the past couple of months.

At the end of June, I went through the FSF copyright assignment process for both Binutils and GDB, which now allows me to contribute larger changes to these codebases. I thus updated the NetBSD system call table in GDB, and added support to readelf for reading OpenBSD ELF core notes.

In Pkgsrc land, I packaged and imported mold, a new linker that is optimized for modern multi-core machines, and updated our binutils package to the latest version.

At the end of August, I attended the OpenBSD k2k21 hackathon, and one of the goals I had was to get source-based code coverage working in LLVM. The first part of this was to find how to allow the compiler driver to link against the libclang_rt.profile library when passing the -fprofile-instr-generate and -fcoverage-mapping options to Clang. Once I figured the magic incantation, I committed my change to src and sent it upstream where it got committed and backported to the LLVM 13 branch. With this part sorted, the next step was to build and ship the library in the base system. I added build infrastructure for the library in base, and linked it to the build. It is now enabled on architectures where Clang is built.

To illustrate what we can do with the source-based code coverage, let's take the following C program:

#include <stdio.h>

int
main()
{
	printf(" >o_/   >o_/   >o_/ \n");
	return 0;

	printf("*PAN!* *PAN!* *PAN!*\n");
}

Let's build and instrument it to emit profile data:

clang -fprofile-instr-generate -fcoverage-mapping ducks.c -o ducks

And we can now run it to collect and process profile data:

LLVM_PROFILE_FILE="ducks.profraw" ./ducks
llvm-profdata merge -sparse ducks.profraw -o ducks.profdata
llvm-cov show ./ducks -instr-profile=ducks.profdata

We can see that no ducks were harmed during this experiment:

Coverage reports can also be created by llvm-cov:

llvm-cov report ./ducks -instr-profile=ducks.profdata

Filename                      Regions    Missed Regions     Cover   Functions  Missed Functions  Executed       Lines      Missed Lines     Cover
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
/home/f/ducks/ducks.c               2                 1    50.00%           1                 0   100.00%           6                 1    83.33%
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
TOTAL                               2                 1    50.00%           1                 0   100.00%           6                 1    83.33%

Using the LLVM_PROFILE_FILE environment variable, it is possible to do several runs with different options and/or input files and get a new .profraw file each time. All those files can then be merged using llvm-profdata, which is pretty useful for doing coverage reports from unit tests.

On top of the OpenBSD related changes I've been contributing upstream to LLVM, I've been continuing my experiments with the build system. I've also been reading documentation about various parts of the toolchain, sending diffs when encountering mistakes or things which could be improved.

binutils and GDB commits:

• 2021-09-11 - 98ca73a - Add support to readelf for reading OpenBSD ELF core notes
• 2021-07-14 - 77db472 - Update the NetBSD system call table to match NetBSD-current

Pkgsrc toolchains related commits:

• 2021-09-27 - 65675ea - Update to mold 0.9.6
• 2021-09-11 - 871f328 - Update to binutils 2.37
• 2021-09-11 - 53d0f2e - Update to mold 0.9.5
• 2021-07-29 - 1b5d585 - Import mold 0.9.3

LLVM commits:

• 2021-09-30 - 97a0ba4 - [clang] Update Clang version from 13 to 14 in scan-build.1
• 2021-09-30 - 01641f6 - [clang] Fix sentence in the usage section of ThinLTO docs
• 2021-09-29 - 7a7caf9 - [clang] Fix library name (libsupc++) in the admonition note
• 2021-09-28 - 5b125a4 - [CMake] Add detection for the mold linker in AddLLVM.cmake
• 2021-09-24 - 626e2a6 - [compiler-rt] Use portable "#!/usr/bin/env bash" shebang for tests
• 2021-09-24 - 4ed0531 - [docs] Document the –print-passes flag in opt
• 2021-09-23 - 7f5ca8c - [clang] Use portable "#!/usr/bin/env bash" shebang for tools and utils
• 2021-09-17 - b588f5d - [clang][scan-build] Use cc/c++ instead of gcc/g++ on OpenBSD
• 2021-09-07 - 4787ef3 - [compiler-rt] Document that builtins is known to work on OpenBSD
• 2021-09-03 - 466451c - [clang] Allow the OpenBSD driver to link the libclang_rt.profile library
• 2021-07-27 - 1862ffe - [clang] Fix a typo in the manual page: s/contraint/constraint
• 2021-07-23 - bc96aa9 - [clang] Fix typos in Options.td and regen ClangCommandLineReference.rst

This is the OpenBSD counterpart of my article about running NetBSD on the Vortex86DX CPU, and its purpose is mostly to archive a dmesg entry and various benchmarks for this machine. I should note that with only 256MB of RAM, the machine is too constrained to do kernel and libraries relinking in a timely manner, due to swapping.

For more information and background about the hardware, please refer to my other article.

Here is the result of a quick md5 -t benchmark:

MD5 time trial.  Processing 10000 10000-byte blocks...
Digest = 52e5f9c9e6f656f3e1800dfa5579d089
Time   = 2.398437 seconds
Speed  = 41693819.766790 bytes/second

Here is the result of the sha1 -t benchmark:

SHA1 time trial.  Processing 10000 10000-byte blocks...
Digest = 74a57b897cc581defa5b3a359fa762a1b83a60e8
Time   = 5.648437 seconds
Speed  = 17704012.632167 bytes/second

For the record, LibreSSL speed benchmark results are available here.

System message buffer (dmesg output):

OpenBSD 7.0 (GENERIC) #203: Wed Sep 22 19:24:38 MDT 2021
    [email protected]:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 267927552 (255MB)
avail mem = 246661120 (235MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 10/29/10, BIOS32 rev. 0 @ 0xf0010
pcibios0 at bios0: rev 3.0 @ 0xf0000/0x10000
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3a80/224 (12 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x17f3 product 0x6031
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc0000/0x8000 0xe9400/0x200!
cpu0 at mainbus0: (uniprocessor)
cpu0: Vortex86 SoC  (586-class) 1.01 GHz, 05-02-02
cpu0: FPU,TSC,CX8
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "RDC R6021 Host" rev 0x02
vga1 at pci0 dev 3 function 0 "XGI Technology Volari Z7" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 7 function 0 "RDC R6031 ISA" rev 0x02
vte0 at pci0 dev 8 function 0 "RDC R6040 Ethernet" rev 0x00: irq 10, address 00:1b:eb:22:16:5c
rdcphy0 at vte0 phy 1: R6040 10/100 PHY, rev. 1
ohci0 at pci0 dev 10 function 0 "RDC R6060 USB" rev 0x12: irq 11, version 1.0, legacy support
ehci0 at pci0 dev 10 function 1 "RDC R6061 USB2" rev 0x03: irq 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "RDC EHCI root hub" rev 2.00/1.00 addr 1
ohci1 at pci0 dev 11 function 0 "RDC R6060 USB" rev 0x12: irq 11, version 1.0, legacy support
ehci1 at pci0 dev 11 function 1 "RDC R6061 USB2" rev 0x03: irq 11
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "RDC EHCI root hub" rev 2.00/1.00 addr 1
pciide0 at pci0 dev 12 function 0 "RDC R1011 IDE" rev 0x01: DMA (unsupported), channel 0 configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 ignored (not responding; disabled or no drives?)
pciide0: channel 1 ignored (not responding; disabled or no drives?)
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb2 at ohci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "RDC OHCI root hub" rev 1.00/1.00 addr 1
usb3 at ohci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "RDC OHCI root hub" rev 1.00/1.00 addr 1
dt: 445 probes
umass0 at uhub1 port 2 configuration 1 interface 0 "SanDisk Cruzer Switch" rev 2.00/1.27 addr 2
umass0: using SCSI over Bulk-Only
scsibus1 at umass0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: <SanDisk, Cruzer Switch, 1.27> removable serial.07815572120302108502
sd0: 7633MB, 512 bytes/sector, 15633408 sectors
uhidev0 at uhub2 port 1 configuration 1 interface 0 "Lenovo ThinkPad Compact USB Keyboard with TrackPoint" rev 2.00/3.30 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub2 port 1 configuration 1 interface 1 "Lenovo ThinkPad Compact USB Keyboard with TrackPoint" rev 2.00/3.30 addr 2
uhidev1: iclass 3/1, 22 report ids
ums0 at uhidev1 reportid 1: 5 buttons, Z and W dir
wsmouse0 at ums0 mux 0
ucc0 at uhidev1 reportid 16: 573 usages, 18 keys, array
wskbd2 at ucc0 mux 1
wskbd2: connecting to wsdisplay0
uhid0 at uhidev1 reportid 17: input=2, output=0, feature=0
uhid1 at uhidev1 reportid 19: input=8, output=8, feature=8
uhid2 at uhidev1 reportid 21: input=2, output=0, feature=0
uhid3 at uhidev1 reportid 22: input=2, output=0, feature=0
uaudio0 at uhub2 port 2 configuration 1 interface 1 "ABC C-Media USB Audio Device" rev 1.10/1.00 addr 3
uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 8 ctls
audio0 at uaudio0
uhidev2 at uhub2 port 2 configuration 1 interface 3 "ABC C-Media USB Audio Device" rev 1.10/1.00 addr 3
uhidev2: iclass 3/0
ucc1 at uhidev2: 11 usages, 3 keys, enum
wskbd3 at ucc1 mux 1
wskbd3: connecting to wsdisplay0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (779fe8066eed6ce5.a) swap on sd0b dump on sd0b

There are no sensors available on this machine.

PCI device data:

# pcidump
Domain /dev/pci0:
 0:0:0: RDC R6021 Host
 0:3:0: XGI Technology Volari Z7
 0:7:0: RDC R6031 ISA
 0:8:0: RDC R6040 Ethernet
 0:10:0: RDC R6060 USB
 0:10:1: RDC R6061 USB2
 0:11:0: RDC R6060 USB
 0:11:1: RDC R6061 USB2
 0:12:0: RDC R1011 IDE

I've just installed virt-manager with pkgin on NetBSD 9.2 just because I want to emulate the virtual machines with qemu + nvmm on NetBSD 9.2. The installation of virt-manager went ok. But,when I ran it,an error came up :

netbsd-marietto# virt-manager

Traceback (most recent call last):

File "/usr/pkg/share/virt-manager/virt-manager.py", line 386, in <module>

main()

File "/usr/pkg/share/virt-manager/virt-manager.py", line 247, in main

from virtManager import cli

File "/usr/pkg/share/virt-manager/virtManager/cli.py", line 29, in <module>

import libvirt

ImportError: No module named libvirt

Googling a little bit maybe I've found the solution here :

https://www.unitedbsd.com/d/285-linux-user-and-netbsd-enthusiast-hoping-to-migrate-some-day

where "kim" said :

Looking at pkgsrc/sysutils/libvirt/PLIST it doesn't look like the package provides any Python bindings -- which is what the "ImportError: No module named libvirt" error message is about. You could try py-libvirt from pkgsrc-wip and see how that works out.

I tried to start the compilation like this :

netbsd-marietto# cd /home/mario/Desktop/pkgsrc-wip/py-libvirt
netbsd-marietto# make

but I've got this error :

make: "/home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile" line 15: Could not find ../../wip/libvirt/buildlink3.mk
make: "/home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile" line 16: Could not find ../../lang/python/distutils.mk
make: "/home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile" line 17: Could not find ../../mk/bsd.pkg.mk
make: Fatal errors encountered -- cannot continue

If u want to see the content of the Makefile,it is :

gedit /home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile

#$NetBSD: Makefile,v 1.32 2018/11/30 09:59:40 adam Exp $

PKGNAME= ${PYPKGPREFIX}-${DISTNAME:S/-python//}
DISTNAME= libvirt-python-5.8.0
CATEGORIES= sysutils python
MASTER_SITES= https://libvirt.org/sources/python/

MAINTAINER= [email protected]
HOMEPAGE= https://libvirt.org/sources/python/
COMMENT= libvirt python library
LICENSE= gnu-lgpl-v2

USE_TOOLS+= pkg-config

.include "../../wip/libvirt/buildlink3.mk"
.include "../../lang/python/distutils.mk"
.include "../../mk/bsd.pkg.mk"

Can someone help me to fix the error ? very thanks.

I have a confession. As opposed to a professioion? WHOA, is that how that works? Don’t answer that.

I’ve mentioned many times how excited I was for OpenZFS in FreeBSD 13, due in no small part to its inline encryption capabilities. I’d used the closed-source equivalent on the last Solaris, and had made some proof of concepts on the -CURRENT branch, but I hadn’t used it for any real world data. I also didn’t feel as compelled to rush out and replace my GELI encrypted volumes as I first thought. It still works, and will for the foreseeable future.

A shiny new set of drives for my home server finally gave me the kick up the proverbial posterior to give it a shot with some prod data that definitely isn’t a Plex server for anime. This was my story. DUN DUN.

The existing GELI approach

We’ve always been able to encrypt ZFS on FreeBSD, albeit with an intermediate layer performing the encryption before our data hits the disk. GELI was the most recent and accepted tool to achieve this, akin to cgd on NetBSD, or LUKS on Linux. It’s proven, well tested, and secure, like my hat. Wait, what?

Here’s an example of a typical encrypted ZFS volume using GELI. We create a new GPT layout, label it (you’ll be glad you did), create a key, create a new virtual GELI encrypted block device, then build our ZFS pool on top. Note in the final step we reference the virtual encrypted device:

# _LABEL="12TB-IronWolf-SERIALNO"
# _KEY="/root/example.key"
	
# gpart -s create gpt /dev/ada5
# gpart add -t freebsd-zfs -l "$_LABEL" /dev/ada5
	
# openssl rand -hex 32 | tee "$_KEY"
# geli init -P -K "$_KEY" "/dev/gpt/$_LABEL"
# geli attach -pk "$_KEY" "/dev/gpt/$_LABEL"
	
# zpool create pool "/dev/gpt/${_LABEL}.eli"
# zfs create pool/tank

This uses a plain disk, but you could just as easily build this on top of an iSCSI mount, or a HAST volume. When you restart, you perform the geli attach then zpool import as normal.

The key here is you’re encrypting the entire partition beneath ZFS. GELI is device and file-system agnostic, and ZFS is unaware (AFAIK) that it’s operating within a virtual encrypted device. This may still be preferable in some circumstances, as we’ll get to in a moment.

OpenZFS inline encryption

By contrast, is a phrase with two words. OpenZFS’s native encryption operates at the dataset level, negating the need for a GELI device that has to be mounted separately. What’s even cooler is that all of ZFS’s data integrity, deduping, compression, exports, and other features can operate on these encrypted datasets, even if they’re not imported/mounted. Cray!

You can prepare your drive with gpart(8) and create a key as per above. After that, we create a zpool(8), which has the encryption feature available by default on FreeBSD 13:

# zpool create pool "/dev/gpt/$_LABEL"
	
# zpool get [email protected] pool
==> pool [email protected] active local

Then create a new encrypted volume. You can also verify the operation and check the encryption scheme used with zfs-get(8):

# zfs create -o encryption=on -o keyformat=hex \
	-o keylocation=file:///root/example.key pool/tank 
   
# zfs get encryption,keylocation,keyformat pool/tank
==> NAME       PROPERTY     VALUE                     SOURCE
==> pool/tank  encryption   aes-256-gcm               -
==> pool/tank  keylocation  file:///root/example.key  local
==> pool/tank  keyformat    hex

Wait, hold on, that’s it? Yes! How cool is that!?

Gotchas

I had initially assumed that using keys would result in the zfs datasets automounting when the zpool is imported, which is not the case. Even if their key is available, you must import them first before the zfs dataset is mounted and ready to use (it looks like an rc.d service was written and reviewed to facilitate doing this on boot, which I’ll need to investigate).

The easiest way to do this is with the lowercase L option in zpool(8) import, which retrieves all the keys it can before mounting your encrypted datasets:

# zpool import pool -l

Or you can load all available keys with zfs(8) load-key:

# zpool import pool
# zfs load-key -a

Refer to the linked man pages for more details. Even if you don’t need more details, and just want to marvel at what well-documented software looks like. The GNU people could learn a lesson or two (or three).

Considerations

As I eluded to above, there are a couple of caveats. GELI encrypts whatever data is handed to it, whereas OpenZFS necessarily stores metadata about the datasets in order to use them. This includes dataset and snapshot names. Bear (bare?) that in mind when you’re naming and structuring your datasets.

This is speculation on my part, but I’d also think there’d be a chance for plausible deniability in a device that’s been completely encrypted with GELI, just as any device that uses whole drive encryption. By contrast, OpenZFS dataset metadata makes it obvious that they contain encrypted data, and the scheme with which the data was encrypted. I could be wrong here though.

Overall, is an item of clothing. OpenZFS encryption makes the system administrator’s life easier, and those caveats don’t concern me for how I store my data. I’ll be using it for everything going forward.

Allan Jude and Kyle Kneisl’s FreeBSD Journal article from last year is a great resource if you’d like to learn more about the implementation of OpenZFS’s encryption system. I also found Jim Salter’s article useful in Ars Technica for learning about key management; once you block all the irrelevant autoplaying videos. #ModernWeb

DISCLAIMER: Cryptography is critical to get right, or it’s not worth doing. Always read and follow the official documentation over someone’s blog, even if the blog has a cute anime mascot and is written by someone with the best of intentions and an awesome hat.

By Ruben Schade in Sydney, 2021-09-11.

All of a sudden (read: without changing any parameters) my netbsd virtualmachine started acting oddly. The symptoms concern ssh tunneling.

From my laptop I launch:

$ ssh -L 7000:localhost:7000 [email protected] -N -v

Then, in another shell:

$ irssi -c localhost -p 7000

The ssh debug says:

debug1: Connection to port 7000 forwarding to localhost port 7000 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip: listening port 7000 for localhost port 7000, connect from 127.0.0.1 port 53954, nchannels 3

I tried also with localhost:80 to connect to the (remote) web server, with identical results.

The remote host runs NetBSD:

bash-4.2# uname -a
NetBSD host 5.1_STABLE NetBSD 5.1_STABLE (XEN3PAE_DOMU) #6: Fri Nov  4 16:56:31 MET 2011  [email protected]:/m/obj/m/src/sys/arch/i386/compile/XEN3PAE_DOMU i386

I am a bit lost. I tried running tcpdump on the remote host, and I spotted these 'bad chksum':

09:25:55.823849 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 67, bad cksum 0 (->3cb3)!) 127.0.0.1.54381 > 127.0.0.1.7000: P, cksum 0xfe37 (incorrect (-> 0xa801), 1622402406:1622402421(15) ack 1635127887 win 4096 <nop,nop,timestamp 5002727 5002603>

I tried restarting the ssh daemon to no avail. I haven't rebooted yet - perhaps somebody here can suggest other diagnostics. I think it might either be the virtual network card driver, or somebody rooted our ssh.

Ideas..?

I wrote a post back in May saying I wasn’t sure that UNIX won, as so many media outlets were claiming. I said I was on the fence, but that I saw Linux continue to depart from UNIX’s legacy in meaningful ways. It’s since been picked up and circulated on the usual news aggregator sites and social media, most of which have generated relevant, tactful comments that swayed my opinion and… nah, got you!

Nobody that I could see challenged the post’s premise that UNIX didn’t win (which for certain Linux and BSD folks was seen as a bad thing for the ongoing project of cross-platform compatibility and good system design, or fabulous by others who claimed it freed their systems from perceived UNIX baggage).

Great, end of the post then, time for a beer! Wait, what do you mean it’s Tuesday morning?

By Ruben Schade in Sydney, 2021-09-07.

After initial work on the wifi renewal branch went quite fast and smooth, things have slowed down a bit in the last few months.

Most of the slow down was due to me not being available for this type of work for unexpectedly long times - a problem that should be fixed now.

However, there were other obstacles and unexpected issues on the way:

• bpf taps are handled differently in the new stack and some slightly obscure site conditions of this had been overlooked in the initial conversion. To make everything work, changes to our bpf framework were needed (and have landed in -current some time ago now).
• Many wifi drivers seem to be in a, let's say, slightly fragile state. When testing the random collection of wifi hardware that I acquired during this project in -current, many drivers did not work at first try and often I was able to provoke kernel panics quickly. This is not a happy base to start converting drivers from.
• After the great success of usbnet(9) for USB ethernet drivers, core and I agreed to do the same for wifi - the result is called usbwifi(9) and makes conversion of usb drivers a lot easier than other wifi drivers. See the conversion instructions for more details. usbwifi(9) is both quite similar but also quite different to usbnet(9), mostly for two reasons: it interfaces to a totally different stack, and many usb wlan chipsets are more complex than ethernet chipsets (e.g. have support for multiple send queues with different priorities). Developing usbwifi did cost quit some time (initially unplanned), but is expected to amortize over the next few drivers and quickly end up as a net win.
• I have been hitting a bug in the urtwn(4) driver used for inial usbwifi(9) development and still not found it (as of today). It seems to hit randomly and not be caused by the usbwifi(9) conversion - a fact that I found out only recently. So for now I will put this driver aside (after spending *way* too much time on it) and instead work on other usb drivers, returning to the bug every now and then and see if I can spot it. Maybe I can borrow a USB analyzer and get more insight that way.

The current state of driver conversion and what drivers are still open are listed in the wifi driver conversion matrix.

Next steps ahead are:

• make another pass over documentation and improve things / fixup for recent changes (done before this blog post got published)
• sync the branch with HEAD and keep tracking it more closely
• convert run(4) to usbwifi
• revisit rtwn(4) and decide if/how it should be merged with urtwn(4)
• revisit iwm(4) and make it work fully
• convert all other drivers, starting with the ones I have hardware for

Currently it is not clear if this branch can be merged to HEAD before branching for netbsd-10. We will not delay the netbsd-10 branch for this.

Netatalk3 is a file server for exporting storage to Macs. Samba has long been considered its replacement, but to this day Netatalk still handles file labels and other Mac-specific metadata more reliably and with greater performance. One day I’ll properly try replicating this in Samba.

I installed it in a new FreeBSD jail:

# pkg install net/netatalk3

Then configured it largely the same as I did on FreeBSD in 2014, and on NetBSD last year. Only this time, all the Macs in the house refused to talk to it.

I tail’d /var/log/daemon.log in the jail and was inundated with afpd(8) spam:

netatalk[34758]: Restarting 'afpd' (restarts: 7)
afpd[42393]: dsi_tcp_init(*): getaddrinfo: Name does not resolve
afpd[42393]: No suitable network config for TCP socket
afpd[42393]: no suitable network address found, use "afp listen" or "afp interfaces"
afpd[42393]: main: no servers configured

I followed the error’s advice and added the IP address of the jail to the [Global] section of my /usr/local/etc/afp.conf file:

afp listen = <IP Address>

It worked, and I was able to log in, as shown in the logs:

afpd[88524]: Netatalk AFP/TCP listening on <IP Address>:548

I don’t recall ever having to add a specific interface or IP address to an afp.conf file before on a FreeBSD or NetBSD host. My hunch is it has something to do with the jail environment, and dsi_tcp_init not being able to autodetect or initialise the jail’s virtual network interface. Please correct me if you have more details!

By Ruben Schade in Sydney, 2021-08-08.

This is what I’d call a thinking out loud about personal circumstances post, rather than anything prescriptive or useful for discerning computators general. You’ve been warned!

Clara and I are running low on drive space on our OpenZFS file server, once again. We have a running joke that driveageddon seems to rear its fragmented head every August. Maybe it’s a self-fulfilling prophecy, though it’s files doing all the filling on these implausibly-fast spinning platters of metal.

(Has someone made a discus anime?)

Our FreeBSD server is the centre of our world. It uses a combination of NetBSD and Debian VMs running in Xen (to be replaced with bhyve at some point) and FreeBSD jails to serve and delegate anything we can offload from our personal and work machines. I have other boxes for tinkering and testing, but this one runs the latest -RELEASE with as unexotic a configuration as I can make it. Vim is saying unexotic isn’t a word. It’s probably right.

My attitude for at least the last six years (possibly longer) has been to buy a pair of the largest drives I can afford, and to cycle out the oldest pair. 2019 was the year I finally said goodbye to a pair of HGST 3 TB units that had performed flawlessly for almost a decade. They’re now in anti-static bags in a safe-deposit box, acting as a cold backup for our most critical family photos and documents.

There’s a thought there that I haven’t had to replace a hard drive due to outright failure in a long time, but I’d dare not mention that here lest I invoke the wrath of Murphys Law. Good thing I didn’t.

But here’s the thing. This time I’m not faced with the same space or chipset constraints, so I could add more drives instead of swapping. Last year I replaced our workhorse HPE Microserver with a refurbished Supermicro workstation board with 8× SATA and 2× NVMe (albeit one on a PCI-E daughterboard) and an old Antec 300 case with 8 LFF drive bays. I even considered getting an additional RAID controller, provided I could use it in JBOD mode for ZFS. That was an unconscionable number of abbreviations and acronyms, and I’m not even a network engineer.

You could argue the timing is great. Chia has driven up the cost of drives, meaning this year I won’t be getting as much of a capacity jump as I have in previous years. Granted going from 4 to 10 would be nice, but it’s still only 6 TB of effective extra space for many hundreds of dollars; not to mention that I insist on using ZFS mirrors for redundancy and ease of replacements/upgrades. Adding drives instead will give me all the extra capacity.

It all makes sense, but my main concerns are still noise and heat. Clara and I live in a one-bedroom apartment now, which is much nicer than sleeping in a studio while the computer in the other end of the room loudly seeks and scrubs its ZFS pools on a recurring basis. But we work from home now, and I have experience with specific WD drives in my bedroom growing up that I don’t want to inadvertently repeat. I’d likely tolerate it, but it’s not fair to Clara having something clicking and buzzing away within earshot all day.

We’ve lucked out thus far with our current HGST, WDs, and Seagates. The read/write heads on the SSDs are also so silent as to be practically non-existent (cough)! But I’ve read reviews of current larger drives of people complaining about noise; the WD Golds and Toshibas seem to frequently cause people ire.

This post was as open-ended as the bag of kettle chips I regret eating. Maybe I need to do some Acoustic Research.

By Ruben Schade in Sydney, 2021-08-03.

Anders Magnusson, writing on the Port-vax NetBSD mailing list:

Some time ago I ended up in an architectural discussion (risc vs cisc etc…) and started to think about vax. Even though the vax is considered the “ultimate cisc” I wondered if its cleanliness and nice instruction set still could be implemented efficient enough. Well, the only way to know would be to try to implement it I had an 15-year-old demo board with a small low-end FPGA (Xilinx XC3S400), so I just had to learn Verilog and try to implement something. And it just passed EVKAA.EXE:

Along with the development of a VAX implementation in an FPGA, discussions arose about possible 64-bit extensions:

For userspace; the vax architecture itself leave the door open for expanding the word size. The instructions are all defined to use only the part of a register it needs, so adding a bunch of ‘Q’ instructions are a no-brainer. Argument reference will work as before. The JMP/JSR/RET/… might need a Q counterpart, since it suddenly store/require 8 bytes instead of 4. Kernel; the hardware structures (SCB, PCB, …) must all be expanded. Memory management changed (but the existing leave much to wish for anyway). All this is probably a quite simple update to the architecture.

It’s nice to see people still putting work and effort into what is nearly a half-century old, and otherwise obsolete, instruction set.

This post was written by Piyush Sachdeva:

What really happens when you double click an icon on your desktop?

Support for chdir(2) in posix_spawn(3)

Processes are the bread and butter of your operating system. The moment you double click an icon, that particular program gets loaded in your Random Access Memory (RAM) and your operating system starts to run it. At this moment the program becomes a process. Though you can only see the execution of your process, the operating system (the Kernel) is always running a lot of processes in the background to facilitate you.

From the moment you hit that power button, everything that happens on the screen is the result of some or the other process. In this post we are going to talk about one such interface which helps in creation of your programs.

The fork() & exec() shenanigans

The moment a computer system comes alive, it launches a bunch of processes. For the purpose of this blog let’s call them, ‘the master processes’. These processes run in perpetuity, provided the computer is switched on. One such process is init/systemd/launchd (depending on your OS). This ‘init’ master process owns all the other processes in the computer, either directly or indirectly.

Operating systems are elegant, majestic software that work seamlessly under the hood. They do so much without even breaking a sweat (unless it’s Windows). Let's consider a scenario where you have decided to take a trip down memory lane and burst open those old photos. The ‘init master process’ just can’t terminate itself and let you look at your photos. What if you unknowingly open a malicious file, which corrupts all your data? So init doesn’t just exit, rather it employs fork() and exec() to start a new process. The fork() function is used to create child processes which are an exact copy of their parents. Whichever process calls fork, gets duplicated. The newly created process becomes the child of the original running process and the original running process is called the parent. Just how parents look after their kids, the parent process makes sure that the child process doesn't do any mischief. So now you have two exactly similar processes running in your computer.

One might think that the newly created child process doesn’t really help us. But actually, it does. Now exec() comes into the picture. What exec() does is, it replaces any process which calls it. So what if we replace the child process, the one we just thought to be useless, with our photos? That's exactly what we are going to do indeed. This will result in replacement of the fork() created child process with your photos. Therefore, the master init process is still running and you can also enjoy your photos with no threat to your data.

Now you could ask me, `But what about the title, some ‘posix_spawn()’ thing?´ Don’t worry, that’s next.

posix_spawn()

posix_spawn() is an alternative to the fork() + exec() routine. It implements fork() and exec(), but not directly (as that would make it slow, and we all need everything to be lightning fast). What actually happens is that posix_spawn() only implements the functionality of the fork() + exec() routines, but in one single call. However, because fork() + exec() is a combination of two different calls, there is a lot of room for customization. Whatever software you are running on your computer, calls these routines on its own and does the necessary. Meanwhile a lot is cooking in the background. Between the call to fork() and exec() there is plenty of leeway for tweaking different aspects of the exec-ing process. But posix_spawn doesn’t bear this flexibility and therefore has a lot of limitations. It does take a lot of parameters to give the caller some flexibility, but it is not enough.

Now the question before us is, “If fork() + exec() is so much more powerful, then why have, or use the posix_spawn() routine?” The answer to that is, that fork() and exec() are UNIX system routines. They are not present in operating systems that are not a derivative of UNIX. Eg- Windows implements a family of spawn functions.
There is another issue with fork() (not exec() ), which in reality is one of the biggest reasons behind the growth of posix_spawn(). The outline of the issue is that, creating child processes in multi-threaded programs is a whole another ball game altogether.

Concurrency is one of those disciplines in operating systems where the order in which the cards are going to unravel is not always how you expect them to. Multi-threading in a program is a way to do different and independent tasks of a program simultaneously, to save time. No matter how jazzy or intelligent the above statement looks, multi-threaded programs require an eagle’s eye as they can often have a lot of holes. Though the “tasks” are different and independent, they often share a few common attributes. When these different tasks due to concurrency start running in parallel, a data race begins to access those shared attributes. To not wreak havoc, there are mechanisms through which, when modifying/accessing these common attributes (Critical Section) we can provide a sort of mutual exclusion (locks/conditional variables) - only letting one of the processes modify the shared attribute at a time. Here when things are already so intricate due to multithreading, and to top it off, we start creating child processes. Complications are bound to arise. When one of the threads from the multi-threaded program calls fork() to create a child process, fork() does clone everything (variables, their states, functions, etc) but it fails to clone other threads (though this is not required at all times).

The child process now knows only about that one thread which called fork(). But all the other attributes of the child that were inherited from the parent (locks, mutexes) are set from the parent’s address space (considering multiple threads). So there is no way for the child process to know which attributes conform to which parts of the parent. Also, those mechanisms that we used to provide mutual exclusion, like locks and conditional variables, need to be reset. This reset step is essential in letting the parent access it’s attributes. Failing this reset can cause deadlocks. To put it simply, you can see how difficult things have become all of a sudden. The posix_spawn() call is free from these limitations of fork() encountered in multi-threaded programs. However, as mentioned by me earlier, there needs to be enough rope to meet all the requirements before posix_spawn() does the implicit exec().

About my Project

Hi, I am Piyush Sachdeva and I am going to start a project which will focus on relaxing one limitation of posix_spawn - changing the current directory of the child process, before the said call to exec() is made. This is not going to restrict it to the parent’s current working directory. Just passing the new directory as one of the parameters will do the trick. Resolving all the impediments would definitely be marvelous. Alas! That is not possible. Every attempt to resolve even a single hindrance can create plenty of new challenges.

As already mentioned by me, posix_spawn() is a POSIX standard. Hence the effect of my project will probably be reflected in the next POSIX release. I came across this project through Google Summer of Code 2021. It was being offered by The NetBSD Foundation Inc. However, as the slots for Google Summer of Code were numbered, my project didn’t make the selection. Nevertheless, the Core Team at The NetBSD Foundation offered me to work on the project and even extended a handsome stipend. I will forever be grateful to The NetBSD Foundation for this opportunity.

Notes

• init, systemd & launchd are system daemon processes. init is the historical process present since System III UNIX. systemd was the replacement for the authentic init which was written for the Linux kernel. launchd is the MacOS alternative of init/systemd.
• This is taken from Operating Systems: The Three Easy Pieces book by Andrea C. Arpaci-Dusseau and Remzi H. Arpaci-Dusseau.
• UNIX is the original AT&T UNIX operating system developed at the Bell Labs research center, headed by Ken Thompson and Dennis Ritchie.

References

1. Operating Systems: Three Easy Pieces by Andrea C. Arpaci-Dusseau and Remzi H. Arpaci-Dusseau.
2. Advanced Programming in the UNIX Environment by W. Richard Stevens and Stephen A. Rago.
3. UNIX and Linux System Administration Handbook by Evi Nemeth, Garth Synder, Trent R. Hein, Ben Whaley and Dan Mackin.

I've been wanting to learn more about compilers and toolchains in general for a while now. In June 2016, I asked about recommended readings on lexers and parsers on Twitter. However, I have to confess that I didn't go forward with reading the Dragon Book.

Instead, I got involved as a developer in the OpenBSD and NetBSD projects, and witnessing the evolution of toolchains within those systems played a big role in maintaining my interest and fascination in the topic. In retrospect, it now becomes apparent that the work I did on porting and packaging software for those systems really helped to put in perspective how the different parts of the toolchains interact together to produce binaries.

Approximately one year ago, I asked again on Twitter whether I knew anyone having worked on compilers and toolchains professionally to get real world advice on how to gain expertise in the field. I got several interesting answers and started to collect and read more resources on the topic. Some of the links I collected ended up on toolchains.net, a collection of toolchain resources which I put online in February.

But the answer that resonate the most with me was Howard's advice to learn by doing. Because I seem to be the kind of person who need to see some concrete results in order to keep motivated, that's exactly what I decided to do.

I started by doing some cleanups in the binutils package in NetBSD's pkgsrc, which resulted in a series of commits:

• 2020-12-20 - ca38479 - Remove now unneeded OpenBSD specific checks in gold
• 2020-12-15 - 7263eee - Add missing TEST_DEPENDS on devel/dejagnu
• 2020-12-14 - b1637da - Don't use hard-coded -ldl in the gold test suite.
• 2020-12-13 - 146def2 - Remove apparently unneeded patch for libiberty
• 2020-12-12 - 6b347a9 - Remove CFLAGS.OpenBSD+= -Wno-bounded directive
• 2020-12-11 - f53b2d8 - Remove now unneeded patch dropping hidden symbols warning
• 2020-12-10 - b037380 - Enable building gold on Linux
• 2020-12-03 - 75d00bc - Remove now unneeded workaround for binutils 2.24
• 2020-12-03 - adfee30 - Drop all Bitrig related patches

Meanwhile, I also got the opportunity to update our package and apply security fixes:

• 2021-02-11 - 761e000 - Update to binutils 2.36.1
• 2021-01-27 - ba983e5 - Update to binutils 2.36
• 2021-01-07 - 7aef5c0 - Add upstream fixes for CVE-2020-35448
• 2020-12-06 - 99fdf39 - Update to binutils 2.35.1

I eventually took maintainership of binutils in Pkgsrc.

Building it repeatedly with different compilers exposed different warnings, and I've also run builds through Clang's static analyzer.

All of this resulted in the opportunity to contribute to binutils itself:

• 2021-04-14 - 5f47741 - Remove unneeded tests for definitions of NT_NETBSDCORE values
• 2021-04-12 - 0fa29e2 - Remove now unneeded #ifdef check for NT_NETBSD_PAX
• 2021-03-12 - be3b926 - Add values for NetBSD .note.netbsd.ident notes (PaX)
• 2021-01-26 - e37709f - Fix a double free in objcopy's memory freeing code

Most recently, I also wrote a couple of blog posts on the topic:

• The state of toolchains in NetBSD
• Speedbuilding LLVM/Clang in 5 minutes
• Speedbuilding LLVM/Clang in 2 minutes on ARM
• The state of toolchains in OpenBSD
• Playing with DJGPP and GCC 10 on DOS

And the journey continues. I'm following a different path from traditional compiler courses starting with lexers and parsers, and doing the opposite curriculum somehow, starting from binaries instead. I will be focusing on the final stages of the pipeline for now: compiling assembly to machine code and producing binaries.

My next steps are to read the full ELF specification, followed by the Linkers and Loader book, and then refresh my ASM skills. My favorite course at university was the computer architecture one and especially its MIPS assembly part, so I'm looking to revisit the subject but with ARM64 assembly this time.

I’ve been a NetBSD developer for three years and it’s been my primary operating system for a long time too – on everything: routers, laptops, Raspberry Pis, PowerPC mac minis, Vortex86 embedded boards, and servers.

I’ve recently been using FreeBSD a lot at work. We have a lot of servers and embedded boards running it, and I was given the option of installing anything I wanted on my workstation. I chose FreeBSD to maintain a separation of BSDs between my work and home life

I thought I’d write a little bit about some differences that stand out to me. Since everyone that knows me well knows that typical use cases like web hosting aren’t really my jam, and I’m more of an embedded, audio, and graphics person, maybe I can offer a more uncommon perspective.

It’s always nice to read perspectives like this.

I'm not exactly sure how I first heard about the Vortex86 CPUs, I think it was either when seeing the demonstration video on KolibriOS project site showcasing the system running on a DMP EBOX machine, or when skimming NetBSD's identcpu.c code. Or did the discovery of the machine prompted me to check if the CPU would be correctly probed by the NetBSD's kernel?

For those interested, Wikipedia has an article retracing the history of the Vortex86 from its birth at Rise to our days.

Several DMP EBOX machines are available for sale at various specialized vendors, but new devices cost several hundreds of dollars which is prohibitive for such low spec systems. However, I was recently able to acquire a boxed older model on a local auction site for about $25: the EBOX 3300A-H, with a 1GHz CPU and 256MB of RAM, no less.

As I already mentioned, those machines are quite slow but they still do have a few things going for them:

• They are totally fanless, and the metal case finish is quite nice
• They are very low-power x86 embedded devices, and still being produced

I used a power meter to do measurements, and an idle system consumes 5.3W. Power consumption peaked at 6.4W when running the OpenSSL speed benchmark.

There is space for a 2.5" hard drive in the enclosure, but I don't have any IDE drives anymore so I opted to use old CompactFlash cards I had laying around. As a side note, it's actually exquisite to use those cards like glorified floppies :-)

For this post, I used a 1GB CompactFlash card and selected a minimal installation in sysinst.

The installed system takes 212M:

Filesystem         Size       Used      Avail %Cap Mounted on
/dev/wd0a          919M       212M       661M  24% /
kernfs             1.0K       1.0K         0B 100% /kern
ptyfs              1.0K       1.0K         0B 100% /dev/pts
procfs             4.0K       4.0K         0B 100% /proc
tmpfs               64M         0B        64M   0% /var/shm

On a freshly booted system, 15 processes are running and 26M of RAM are used:

load averages:  0.01,  0.00,  0.00;               up 0+00:48:26        14:48:28
16 processes: 15 sleeping, 1 on CPU
CPU states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Memory: 26M Act, 6460K Exec, 12M File, 195M Free
Swap: 

  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
    0 root      96    0     0K   26M usbevt     0:01  0.00%  0.00% [system]
  795 root      43    0  6160K 1628K CPU        0:00  0.00%  0.00% top
  555 root      85    0    12M 3472K wait       0:00  0.00%  0.00% login
  630 postfix   85    0    13M 3220K kqueue     0:00  0.00%  0.00% qmgr
  599 postfix   85    0    12M 3172K kqueue     0:00  0.00%  0.00% pickup
  575 root      85    0    13M 2304K kqueue     0:00  0.00%  0.00% master
  196 root      85    0  9780K 1960K kqueue     0:00  0.00%  0.00% syslogd
  583 root      85    0  6788K 1824K wait       0:00  0.00%  0.00% sh
  710 root      85    0  6276K 1448K nanoslp    0:00  0.00%  0.00% cron
  733 root      85    0  6108K 1396K ttyraw     0:00  0.00%  0.00% getty
  730 root      85    0  5720K 1392K ttyraw     0:00  0.00%  0.00% getty
  633 root      85    0  6104K 1388K ttyraw     0:00  0.00%  0.00% getty
  211 root      85    0  7316K 1360K kqueue     0:00  0.00%  0.00% dhcpcd
    1 root      85    0  6600K 1340K wait       0:00  0.00%  0.00% init
  689 root      85    0  5700K 1184K kqueue     0:00  0.00%  0.00% inetd
  402 root      84    0  5920K 1140K kqueue     0:00  0.00%  0.00% powerd

Here is the result of running cat /proc/cpuinfo on this device:

processor	: 0
vendor_id	: Vortex86 SoC
cpu family	: 5
model		: 2
model name	: Vortex86DX
stepping	: 2
cpu MHz		: 1000.05
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu tsc cx8 
clflush size	: 0

For the record, OpenSSL speed benchmark results are available here.

System message buffer (dmesg output):

[     1.000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
[     1.000000]     2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
[     1.000000]     2018, 2019, 2020 The NetBSD Foundation, Inc.  All rights reserved.
[     1.000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[     1.000000]     The Regents of the University of California.  All rights reserved.

[     1.000000] NetBSD 9.2 (GENERIC) #0: Wed May 12 13:15:55 UTC 2021
[     1.000000] 	[email protected]:/usr/src/sys/arch/i386/compile/GENERIC
[     1.000000] total memory = 255 MB
[     1.000000] avail memory = 231 MB
[     1.000000] rnd: seeded with 66 bits
[     1.000000] timecounter: Timecounters tick every 10.000 msec
[     1.000000] Kernelized RAIDframe activated
[     1.000000] running cgd selftest aes-xts-256 aes-xts-512 done
[     1.000000] timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
[     1.000003] Generic PC
[     1.000003] mainbus0 (root)
[     1.000003] Firmware Error (ACPI): A valid RSDP was not found (20190405/tbxfroot-261)
[     1.000003] autoconfiguration error: acpi_probe: failed to initialize tables
[     1.000003] ACPI Error: Could not remove SCI handler (20190405/evmisc-312)
[     1.000003] cpu0 at mainbus0
[     1.000003] cpu0: Vortex86DX, id 0x522
[     1.000003] cpu0: package 0, core 0, smt 0
[     1.000003] pci0 at mainbus0 bus 0: configuration mode 1
[     1.000003] pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
[     1.000003] pchb0 at pci0 dev 0 function 0: vendor 17f3 product 6021 (rev. 0x02)
[     1.000003] vga0 at pci0 dev 3 function 0: vendor 18ca product 0020 (rev. 0x00)
[     1.000003] wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
[     1.000003] wsmux1: connecting to wsdisplay0
[     1.000003] drm at vga0 not configured
[     1.000003] rdcpcib0 at pci0 dev 7 function 0: vendor 17f3 product 6031 (rev. 0x02)
[     1.000003] rdcpcib0: watchdog timer configured.
[     1.000003] vte0 at pci0 dev 8 function 0: vendor 17f3 product 6040 (rev. 0x00)
[     1.000003] vte0: Ethernet address 00:1b:eb:22:16:5c
[     1.000003] vte0: interrupting at irq 10
[     1.000003] rdcphy0 at vte0 phy 1: R6040 10/100 media interface, rev. 1
[     1.000003] rdcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
[     1.000003] ohci0 at pci0 dev 10 function 0: vendor 17f3 product 6060 (rev. 0x12)
[     1.000003] ohci0: interrupting at irq 11
[     1.000003] ohci0: OHCI version 1.0, legacy support
[     1.000003] usb0 at ohci0: USB revision 1.0
[     1.000003] ehci0 at pci0 dev 10 function 1: vendor 17f3 product 6061 (rev. 0x03)
[     1.000003] ehci0: interrupting at irq 11
[     1.000003] ehci0: BIOS has given up ownership
[     1.000003] ehci0: EHCI version 1.0
[     1.000003] ehci0: 1 companion controller, 2 ports: ohci0
[     1.000003] usb1 at ehci0: USB revision 2.0
[     1.000003] ohci1 at pci0 dev 11 function 0: vendor 17f3 product 6060 (rev. 0x12)
[     1.000003] ohci1: interrupting at irq 11
[     1.000003] ohci1: OHCI version 1.0, legacy support
[     1.000003] usb2 at ohci1: USB revision 1.0
[     1.000003] ehci1 at pci0 dev 11 function 1: vendor 17f3 product 6061 (rev. 0x03)
[     1.000003] ehci1: interrupting at irq 11
[     1.000003] ehci1: BIOS has given up ownership
[     1.000003] ehci1: EHCI version 1.0
[     1.000003] ehci1: 1 companion controller, 2 ports: ohci1
[     1.000003] usb3 at ehci1: USB revision 2.0
[     1.000003] rdcide0 at pci0 dev 12 function 0: RDC R1011 IDE controller (rev. 0x01)
[     1.000003] rdcide0: bus-master DMA support present
[     1.000003] rdcide0: primary channel configured to compatibility mode
[     1.000003] rdcide0: primary channel interrupting at irq 14
[     1.000003] atabus0 at rdcide0 channel 0
[     1.000003] rdcide0: secondary channel configured to compatibility mode
[     1.000003] rdcide0: secondary channel interrupting at irq 15
[     1.000003] atabus1 at rdcide0 channel 1
[     1.000003] isa0 at rdcpcib0
[     1.000003] pckbc0 at isa0 port 0x60-0x64
[     1.000003] attimer0 at isa0 port 0x40-0x43
[     1.000003] pcppi0 at isa0 port 0x61
[     1.000003] midi0 at pcppi0: PC speaker
[     1.000003] sysbeep0 at pcppi0
[     1.000003] isapnp0 at isa0 port 0x279
[     1.000003] attimer0: attached to pcppi0
[     1.000003] isapnp0: no ISA Plug 'n Play devices found
[     1.000003] timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
[     1.064509] uhub0 at usb1: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
[     1.064509] uhub0: 2 ports with 2 removable, self powered
[     1.064509] uhub1 at usb2: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
[     1.064509] uhub1: 2 ports with 2 removable, self powered
[     1.064509] uhub2 at usb3: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
[     1.064509] uhub2: 2 ports with 2 removable, self powered
[     1.064509] uhub3 at usb0: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
[     1.064509] uhub3: 2 ports with 2 removable, self powered
[     1.064509] IPsec: Initialized Security Association Processing.
[     3.914550] uaudio0 at uhub3 port 2 configuration 1 interface 0
[     3.914550] uaudio0: vendor 0d8c (0xd8c) C-Media USB Audio Device (0x08), rev 1.10/1.00, addr 2
[     3.934546] uaudio0: audio rev 1.00
[     3.934546] audio0 at uaudio0: playback, capture, full duplex, independent
[     3.934546] audio0: slinear_le:16 2ch 48000Hz, blk 11520 bytes (60ms) for playback
[     3.934546] audio0: slinear_le:16 1ch 48000Hz, blk 6000 bytes (62.5ms) for recording
[     3.934546] uhidev0 at uhub3 port 2 configuration 1 interface 3
[     3.934546] uhidev0: vendor 0d8c (0xd8c) C-Media USB Audio Device (0x08), rev 1.10/1.00, addr 2, iclass 3/0
[     3.944550] uhid0 at uhidev0: input=4, output=4, feature=0
[     4.054550] wd0 at atabus1 drive 0
[     4.054550] wd0: <Hitachi XX.V.3.5.0.0>
[     4.054550] wd0: drive supports 1-sector PIO transfers, LBA addressing
[     4.054550] wd0: 977 MB, 1987 cyl, 16 head, 63 sec, 512 bytes/sect x 2002896 sectors
[     4.064551] wd0: 32-bit data port
[     4.064551] wd0: drive supports PIO mode 4
[     4.064551] wd0(rdcide0:1:0): using PIO mode 4
[     4.084559] WARNING: 1 error while detecting hardware; check system log.
[     4.084559] boot device: wd0
[     4.084559] root on wd0a dumps on wd0b
[     4.094550] root file system type: ffs
[     4.094550] kern.module.path=/stand/i386/9.2/modules
[    20.764808] wsdisplay0: screen 1 added (80x25, vt100 emulation)
[    20.784809] wsdisplay0: screen 2 added (80x25, vt100 emulation)
[    20.794810] wsdisplay0: screen 3 added (80x25, vt100 emulation)
[    20.804812] wsdisplay0: screen 4 added (80x25, vt100 emulation)

Hi everyone,

Due to the unfortunate situation regarding changes in administration on freenode.net, and the resulting chaos, we have decided to move the public NetBSD IRC chat channels from freenode to irc.libera.chat.

This includes:

• #NetBSD - general discussion
• #netbsd-code - development discussion
• #pkgsrc - pkgsrc (primarily development) discussion

You can find information on connecting to Libera at https://libera.chat/

For the last few weeks, I’ve been doing lots of testing of NetBSD‘s build.sh cross-build system on lots of different platforms. Linux is readily available on AWS, as is FreeBSD. You will find NetBSD and OpenBSD in some AWS locations. It’s more difficult to get the BSDs onto AWS because the standard upload tools detect the filesystems and if they are not on the list, the image is not allowed. The BSD FFS and variants are not on the list.

Fortunately there are other tools and other ways to build images. It’s a little protracted. You need to first build a VM, convert it to VMDK, upload it to S3, create a snapshot and then convert it to an AMI.

This set of scripts (by Antoine Jacoutot) does the hard work for you and works for OpenBSD 6.5 up to 6.8. Last night, I created my own fork here which also works for 6.9. Essentially the difference is that the OpenBSD install kernel is compressed and the script now decompresses it and recompresses it where needed.

So as a result on AWS eu-west-2 (London), there are are AMIs for OpenBSD 6.5 through to 6.9. Just search for OpenBSD when you want to launch an image.

There are NetBSD images out there but I’m hoping to get around to producing some too.

I am trying to assemble a simple Hello World program with the GNU assembler (as) on a Raspberry Pi 3 B+ running NetBSD 9.1
What flags do I need to add to as or ld to make them assemble the code correctly for the architecture I am using?

$ as -o hllwrld.o hllwrld.s
$ ld -o hllwrld hllwrld.o
$ ./hllwrld
-sh: Cannot execute ELF binary ./hllwrld

$ uname -a
NetBSD rpi 9.1 NetBSD 9.1 (RPI) #0: Sun Oct 18 19:24:30 UTC 2020  [email protected]:/usr/src/sys/arch/evbarm/compile/RPI evbarm

Is this aarch64 or arm64?

I know there are man pages but I am just learning assembly so I have no idea what configurations/flags/arguments I even need to be looking for.

Thanks for any help.

The NetBSD Project is pleased to announce NetBSD 9.2, the second update of the NetBSD 9 release branch.

It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 9.1 in October 2020, as well some enhancements backported from the development branch. It is fully compatible with NetBSD 9.0.

I’m not even remotely well-versed enough in NetBSD to make heads or tails of the changelog, but it seems like there’s quite a few notable ones in there.