NetBSD Planet

I cannot seem to find any details of how to set this up. The NetBSD Wiki implies that it can work, but I could not find any example config. I found an old post the mentioned adding a config line and downloading some firmware files.
The config line was already in /etc/bluetooth/btattach.conf and was commented out. I added an uncommented version then later added a "d" for debugging. I also found some firmware files on Github

# Raspberry Pi 3 Bluetooth UART
#bcm43xx-3wire  /dev/dplcom0    921600          -FPi 115200
bcm43xx-3wire   /dev/dplcom0    921600          -dFPi 115200

arm64# ls -l /libdata/firmware/bcm43xx/
total 280
-rw-r--r--  1 root  wheel  30049 May 15 14:41 BCM43430A1.hcd
-rw-r--r--  1 root  wheel  44376 May 15 14:41 BCM43430B0.hcd
-rw-r--r--  1 root  wheel  38630 May 15 14:41 BCM43438A0.hcd
-rw-r--r--  1 root  wheel  33376 May 15 14:41 BCM43438A1.hcd
-rw-r--r--  1 root  wheel  63806 May 15 14:41 BCM4345C0.hcd
-rw-r--r--  1 root  wheel  55676 May 15 14:41 BCM4345C5.hcd

Looking at the debug output: I see some hex strings: (which I converted to ASCII)

…42 43 4d 34 33 34 33 30 41 31…
BCM43430A1

…42 43 4d 34 33 34 33 38 41 31 20 33 37 2e 34 4d 48 7a 20 52 61 73 70 62 65 72 72 79 20 50 69 20 33 2d 30 30 34 33 4f…
BCM43438A1 37.4MHz Raspberry Pi 3-0043O

so I think the bcm43xx/BCM43430A1.hcd should be the right firmware, though I do not see any indication if it was loaded.

But the boot up just shows:

attaching Bluetooth controller to dplcom0
…hex code here…
btattach: bth5: Device not configured
configuring Bluetooth controllers:.
starting Bluetooth Link Key/PIN Code manager
attaching Bluetooth HSET service from "speaker"
btdevctl: sbt0: Device not configured
attaching Bluetooth HSET service from "speaker"
btdevctl: ubt0: Device not configured
starting Bluetooth Service Discovery server

the btconfig command does not list any devices.
Does anyone have any suggestions?

Hi all,
I'm trying to compile Software (389 Server).
I spent a lot of hours on several days (nothing special - i know) and I (think) that i fixed/handled a lot of errors so far. But now i feel, that I'm stuck.

ld tells me it doesn't find libjson-c. But:

• I installed it with pkgin.
• I find it
• I set LD_LIBRARY_PATH to the Path.

But ld stubbornly says that it cant find it. Any suggestions?

`
ld: cannot find -ljson-c
*** Error code 1

Stop.
make[1]: stopped in /usr/src_projects/389_directory_server/389-ds-base-3.0.1
*** Error code 1

Stop.
make: stopped in /usr/src_projects/389_directory_server/389-ds-base-3.0.1
nbsdfc1# echo $LD_LIBRARY_PATH
/usr/pkg/lib
nbsdfc1# find /usr | grep libjson
/usr/pkg/lib/libjson-c.a
/usr/pkg/lib/libjson-c.so
/usr/pkg/lib/libjson-c.so.5
/usr/pkg/lib/libjson-c.so.5.3.0
/usr/pkgsrc/emulators/suse131_32_libjson
/usr/pkgsrc/emulators/suse131_32_libjson/CVS
/usr/pkgsrc/emulators/suse131_32_libjson/CVS/Root
/usr/pkgsrc/emulators/suse131_32_libjson/CVS/Repository
/usr/pkgsrc/emulators/suse131_32_libjson/CVS/Entries
/usr/pkgsrc/emulators/suse131_32_libjson/CVS/Tag
/usr/pkgsrc/emulators/suse131_32_libjson/Makefile
/usr/pkgsrc/emulators/suse131_libjson
/usr/pkgsrc/emulators/suse131_libjson/CVS
/usr/pkgsrc/emulators/suse131_libjson/CVS/Root
/usr/pkgsrc/emulators/suse131_libjson/CVS/Repository
/usr/pkgsrc/emulators/suse131_libjson/CVS/Entries
/usr/pkgsrc/emulators/suse131_libjson/CVS/Tag
/usr/pkgsrc/emulators/suse131_libjson/Makefile
/usr/pkgsrc/emulators/suse131_libjson/DESCR
/usr/pkgsrc/emulators/suse131_libjson/distinfo

`

I looked on the filesystem level:
nbsdfc1# ls -lah libjson*
-rw-r--r-- 1 root wheel 151K Mar 23 10:36 libjson-c.a
lrwxr-xr-x 1 root wheel 14B May 15 22:09 libjson-c.so -> libjson-c.so.5
lrwxr-xr-x 1 root wheel 18B Mar 23 10:36 libjson-c.so.5 -> libjson-c.so.5.3.0
-rwxr-xr-x 1 root wheel 63K Mar 23 10:36 libjson-c.so.5.3.0

In earlier errors symlinks worked.
I made a try with a direct link to libjson-c.so.5.3.0 with the same result. So I switched back to the original pkgin-setup.

If i'm just blind, sorry in advandce!

The NetBSD project seems to agree with me that code generated by “AI” like Copilot is tainted, and cannot be used safely. The project’s added a new guideline banning the use of code generated by such tools from being added to NetBSD unless explicitly permitted by “core“, NetBSD’s equivalent, roughly, of “technical management”.

Code generated by a large language model or similar technology, such as such as GitHub/Microsoft’s Copilot, OpenAI’s ChatGPT, or Facebook/Meta’s Code Llama, is presumed to be tainted code, and must not be committed without prior written approval by core.

↫ NetBSD Commit Guidelines

GitHub Copilot is copyright infringement and open source license violation at an industrial scale, and as I keep reiterating – the fact Microsoft is not training Copilot on its own closed-source code tells you all you need to know about what Microsoft thinks about the legality of Copilot.

This is going to be the last thread I make about failed pkgsrc builds.

trying to build pkgsrc/lang/go (or any package dependent on Go fails with the following error:

[...]
===> Building binary package for go118-1.18.10nb1
=> Creating binary package /home/dave/pkgsrc/packages/All/go118-1.18.10nb1.tgz
===> Installing binary package of go118-1.18.10nb1
=> Returning to build of go121-1.21.10
=> Tool dependency mktools-[0-9]*: found mktools-20220614
=> Tool dependency cwrappers>=20150314: found cwrappers-20220403
=> Full dependency bash-[0-9]*: found bash-5.2.26nb1
=> Full dependency perl>=5.0: found perl-5.38.2
===> Checking for vulnerabilities in go121-1.21.10
===> Overriding tools for go121-1.21.10
===> Extracting for go121-1.21.10
/bin/rm -r -f /home/dave/pkgsrc/lang/go121/work/go/test/fixedbugs/issue27836*
===> Patching for go121-1.21.10
=> Applying pkgsrc patches for go121-1.21.10
===> Creating toolchain wrappers for go121-1.21.10
===> Configuring for go121-1.21.10
=> Substituting "paths" in src/crypto/x509/root_solaris.go
=> Replacing bash interpreter in lib/time/update.bash misc/arm/a misc/cgo/fortran/test.bash misc/wasm/go_js_wasm_exec misc/wasm/go_wasip1_wasm_exec src/all.bash src/bootstrap.bash src/buildall.bash src/clean.bash src/cmd/compile/internal/ssa/_gen/cover.bash src/cmd/go/mkalldocs.sh src/cmd/vendor/golang.org/x/sys/plan9/mkall.sh src/cmd/vendor/golang.org/x/sys/plan9/mkerrors.sh src/cmd/vendor/golang.org/x/sys/unix/mkall.sh src/cmd/vendor/golang.org/x/sys/unix/mkerrors.sh src/cmd/vendor/golang.org/x/sys/windows/mkerrors.bash src/cmd/vendor/golang.org/x/sys/windows/mkknownfolderids.bash src/crypto/internal/boring/build.sh src/crypto/internal/boring/build-boring.sh src/crypto/internal/boring/build-goboring.sh src/go/doc/comment/mkstd.sh src/internal/trace/mkcanned.bash src/cmp.bash src/make.bash src/race.bash src/run.bash src/runtime/race/mkcgo.sh src/syscall/mkall.sh src/syscall/mkerrors.sh src/syscall/mksysnum_plan9.sh.
WARNING: [replace-interpreter] Skipping non-existent file "misc/arm/a".
WARNING: [replace-interpreter] Skipping non-existent file "misc/cgo/fortran/test.bash".
WARNING: [replace-interpreter] Skipping non-existent file "src/cmd/go/mkalldocs.sh".
=> Replacing Perl interpreter in src/net/http/cgi/testdata/test.cgi src/regexp/syntax/make_perl_groups.pl src/syscall/*.pl.
===> Building for go121-1.21.10
cd /home/dave/pkgsrc/lang/go121/work/go/src &&  env  GOROOT_BOOTSTRAP=/usr/pkg/go118  GOROOT_FINAL=/usr/pkg/go121    GOCACHE=/home/dave/pkgsrc/lang/go121/work/.cache/go-build  /usr/pkg/bin/bash ./make.bash -v
Building Go cmd/dist using /usr/pkg/go118. (go1.18.10 netbsd/amd64)
cmd/dist

Building Go toolchain1 using /usr/pkg/go118.
# cd /home/dave; git status --porcelain
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
error obtaining VCS status: exit status 128
	Use -buildvcs=false to disable VCS stamping.
error obtaining VCS status: exit status 128
	Use -buildvcs=false to disable VCS stamping.
error obtaining VCS status: exit status 128
	Use -buildvcs=false to disable VCS stamping.
error obtaining VCS status: exit status 128
	Use -buildvcs=false to disable VCS stamping.
go tool dist: FAILED: /usr/pkg/go118/bin/go install -tags=math_big_pure_go compiler_bootstrap purego -v bootstrap/cmd/...: exit status 1
*** Error code 2

Stop.
make[2]: stopped in /home/dave/pkgsrc/lang/go121
*** Error code 1

Stop.
make[1]: stopped in /home/dave/pkgsrc/lang/go121
*** Error code 1

Stop.
make: stopped in /home/dave/pkgsrc/lang/go

I then run export GIT_DISCOVERY_ACROSS_FILESYSTEM=1 and try again...

This time I tried building lang/go121

~/pkgsrc/lang/go121 λ doas make install clean
=> Bootstrap dependency digest>=20211023: found digest-20220214
===> Checking for vulnerabilities in go121-1.21.10
===> Building for go121-1.21.10
cd /home/dave/pkgsrc/lang/go121/work/go/src &&  env  GOROOT_BOOTSTRAP=/usr/pkg/go118  GOROOT_FINAL=/usr/pkg/go121    GOCACHE=/home/dave/pkgsrc/lang/go121/work/.cache/go-build  /usr/pkg/bin/bash ./make.bash -v
Building Go cmd/dist using /usr/pkg/go118. (go1.18.10 netbsd/amd64)
cmd/dist

Building Go toolchain1 using /usr/pkg/go118.
# cd /home/dave; git status --porcelain
fatal: not a git repository (or any of the parent directories): .git
error obtaining VCS status: exit status 128
	Use -buildvcs=false to disable VCS stamping.
error obtaining VCS status: exit status 128
	Use -buildvcs=false to disable VCS stamping.
error obtaining VCS status: exit status 128
	Use -buildvcs=false to disable VCS stamping.
error obtaining VCS status: exit status 128
	Use -buildvcs=false to disable VCS stamping.
go tool dist: FAILED: /usr/pkg/go118/bin/go install -tags=math_big_pure_go compiler_bootstrap purego -v bootstrap/cmd/...: exit status 1
*** Error code 2

Stop.
make[1]: stopped in /home/dave/pkgsrc/lang/go121
*** Error code 1

Stop.
make: stopped in /home/dave/pkgsrc/lang/go121

Something is wrong with my system and I have no idea what. Re-installation imminent.

I need a usb sound card that is verified to work on NetBSD. I have a computer where the sound card isn’t compatible with NetBSD and I need a working solution. I have tried purchasing a usb sound card that should work with NetBSD, as it is the correct device class, but it doesn’t.

Can anyone please tell me what they have found to work (and are using on a regular basis), so that I don’t have to throw more money out of the window?

NetBSD 10 and NetBSD 9.4 were only recently released, leaving one final branch to receive what will be its last update: NetBSD 8.3. NetBSD 8.0 was originally released in 2018, so this final release marks six years of updates, which is a good track record, especially now that two newer main releases are available to choose from. With 8.3 being the final release, this means no more regular or security updates, pkgsrc no longer supports the 8.0 branch either – so yeah, time to upgrade.

NetBSD 8.3 brings various updates and bug fixes for libX11, xterm, tmux, and httpd, and the root name servers and time zone data have been updated to their latest iterations as well. There’s of course a full list of changes to peruse through if you want to know every little detail that’s changed. You can update your installation in-place, of course, or download the installation media for 8.3 from one of the many mirrors.

Preface:
I know this is totally unecessary and probably entirely useless for most people, but...

I've recently installed NetBSD-Current on a spare disk on my Desktop machine and am slowly getting used to building everything from source. I am quite fond or the fuzzypkg script on Void linux, a wrapper for use with xbps. So I wondered if something similar could work for pkgsrc.

Disclaimer:
This script is currently untested and was written by ChatGPT in collaboration with Google's Gemini AI. I basically played pong with ChatGPT and Gemini until I was happy most things were covered. I have no idea if this particular script will work, but I like the idea behind it.

#!/bin/sh

# Check if fzf is installed
if ! command -v fzf >/dev/null 2>&1; then
  echo "Error: fzf is required. Please install it first." >&2
  exit 1
fi

# Check if bat is installed (optional, for package description previews)
if ! command -v bat >/dev/null 2>&1; then
  echo "Warning: bat is not installed. Package description previews won't be available." >&2
fi

# Path to the user's pkgsrc directory (replace with your actual path)
PKGSRCDIR="$HOME/pkgsrc"

# Check if the pkgsrc directory exists
if [ ! -d "$PKGSRCDIR" ]; then
  echo "Error: $PKGSRCDIR directory not found. Please create it and place your pkgsrc directory inside." >&2
  exit 1
fi

# Find available packages and store them in a variable
pkgs=$(find "$PKGSRCDIR" -mindepth 2 -maxdepth 2 -type f -name 'Makefile' -exec dirname {} \; | sort)

# Use fzf for user selection with bat for previews
selected_pkg=$(fzf --preview 'cat $PKGSRCDIR/{}/DESCR' <<< "$pkgs")

# Check if a package was selected
if [ -z "$selected_pkg" ]; then
  echo "No package selected"
  exit 1
fi

# Change directory to the selected package
cd "$PKGSRCDIR/$selected_pkg" || exit 1

# Build and install the package
echo "Building and installing $selected_pkg..."
make install clean clean-depends distclean

Explanation:

1. Dependency Checks: The script starts by verifying if fzf and bat are installed. If not, it displays an error message and exits.

2. pkgsrc Directory: It defines the path to the user's pkgsrc directory. Replace $HOME/pkgsrc with the actual location on your system.

3. Directory Existence Check: It checks if the specified pkgsrc directory exists. If not, it displays an error message and exits.

4. Finding Packages: The script uses find to search within the pkgsrc directory for directories containing a file named Makefile. It then extracts directory names and sorts them for presentation.

5. Interactive Selection: This is where the magic happens:
- The script stores the list of packages (pkgs) in a variable.
- It uses fzf to create an interactive menu displaying the available packages.
- Instead of cat, it uses bat in the preview command --preview 'bat $PKGSRCDIR/{}/DESCR'. This assumes you have bat installed, a syntax highlighter for better code and text rendering. It displays a preview of the package DESCR file when hovering over a package in the fzf menu. Of course you could use cat if you prefer.

6. Selection Validation: After user interaction, it checks if a package was actually selected. If not, it displays a message and exits.

7. Directory Change: It navigates to the directory of the chosen package within the pkgsrc directory structure.

8. Build and Install: Finally, the script uses make install clean clean-depends distclean to build and install the selected package.
- make install: Performs the installation process.
- clean: Removes temporary build files after installation.
- clean-depends: Cleans up downloaded dependency files.
- distclean: Removes everything related to the build process, including downloaded archives.

Summary:

This script empowers you to easily search, select, build, and install packages from your pkgsrc source directory on NetBSD Current. It offers user-friendly features like fzf for selection and leverages bat for enhanced previews (assuming it's installed) to help you choose the right package. Remember to adjust the PKGSRCDIR path if your pkgsrc directory is located elsewhere.

The NetBSD Project is pleased to announce NetBSD 8.3, the third and final release from the NetBSD 8 stable branch.

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

This also represents the end-of-life for the netbsd-8 release branch. No further security updates will happen. Users running 8.2 or an earlier release are strongly recommended to upgrade to a newer branch, preferably the recent NetBSD 10.0 release.

Pkgsrc has already desupported the netbsd-8 branch.

See the full release announcement (including download links).

My early imaginings of a collaborative Open Source successor to qmail, let me assure you, did not include going nearly four years between releases. Well, at least it hasn’t been more than four. notqmail 1.09 is here:

• qmail list announcement
• Fediverse and Twitter
• Lobste.rs, Hacker News, and Reddit
• Release notes

For decades, due to each administrator needing to patch in their particular missing bits of functionality, the qmail source code itself has effectively been a public API. Some future release of notqmail will include everything most everyone needs. On that day, we’ll freely make desirable code changes without worrying about breaking people’s patches. On that day, notqmail will have become a relatively normal software project operating under relatively normal constraints.

This is not that day. notqmail remains a uniquely challenging legacy-code rehabilitation project, and 1.09 is merely a solid, long-overdue release that includes the work of a couple dozen new contributors.

Since this release took too long, our next development cycle will be

1. Time-bounded
2. Focused on process improvements

In legacy code, every time we can turn a vicious cycle virtuous, it’s a big win. By making the code easier and safer to change, we’ll have more fun; by having more fun, we’ll make more progress; by making more progress, we’ll get more feedback; by getting more feedback, we’ll have more fun; and so on.

Have fun with notqmail 1.09! Let us know how the upgrade goes for you. (I’ll be updating the pkgsrc package soon.) And if getting involved is your kind of thing, please feel welcome to join us.

I want to run GoToSocial on some *BSD system. Because I am who I am, I went for using NetBSD 10.0 . And because my hypervisor is running bhyve on OmniOS , you get the title of this blog post.

Don’t get too anxious, it is quite straightforward. So let the journey begin.

↫ Joel Carnat

Bhyve is a hypervisor originating from FreeBSD, while OmniOS is a distribution of illumos, a continuation of the last open source Solaris release from Oracle. GoToSocial, meanwhile, is an ActivityPub social network server, so it belongs in the same family as Mastodon, Glitch, Akkoma, and countless others. This guide makes this whole process look like a piece of cake, so if you’ve ever been interested in running your own ActivityPub server – read on.

On a slightly related sidenote, there’s no OSNews AT instance, partly because I don’t want to deal with the moderation and costs, and partly because I’m incredibly happy being a member of Exquisite, a Glitch instance running on OpenBSD, managed by OpenBSD enthusiasts. Never say never, of course, but the odds of seeing an OSNews AT instance in the future are very slim.

But the biggest differential factor between BSDs and GNU/Linux is the way it is structured.

In Linux, all components are designed to work together, but are completely separate. You’ve got the kernel, init systems, multimedia daemons, userland, bootloader, virtualization and containerization mechanisms, package managers, and so on. They are all separate projects with their own goals and are operated by separate entities. This is why we’ve got different Linux Distributions instead of Operating System. Everyone can take the kernel, start adding components on top of it, and a few minutes later the DistroWatch is even harder to keep up with.

Each BSD on the other hand is designed as single system. All components are created and developed together. Things work together perfectly, because they are designed, coded, tested and released as one.

↫ Michał Sapka

As I’ve mentioned here and there over the past few weeks, I’ve been exploring the world of BSD lately, and after bouncing of FreeBSD I’ve found a very happy home on OpenBSD. Now, this doesn’t mean I’m now a full-time OpenBSD user or anything like that – Linux is the main operating system on my gaming PC, my laptop, and my workstation, and that’s not going to be changing any time soon. However, after installing, exploring, and using OpenBSD on a machine cobbled together from spare and older parts, I can definitely see the appeal.

OpenBSD feels more coherent than a Linux distribution – I use Fedora KDE, if that matters – and the various lower-level systems seem to talk to each other in ways that make more intuitive sense than the individually developed systems in a Linux distribution do. Diving into the command-line interface of a Linux distribution can sometimes feel confusing because different tools use different conventions, because they’re developed by entirely different people and projects, with different ideas about how flags should work, how output should be presented, and so on. On OpenBSD, it seems much easier to carry over something you learn from one tool to the next. I simply feel more secure and knowledgeable, even if it’s still the same idiot me.

The documentation plays a big role here. They’re in one place, written in a consistent style, and reference each other left and right, making it easy to find your way around to other commands or tools you haven’t yet considered using. On Linux, you’re going from one project’s documentation to another project’s documentation, and not only will the style change, the quality will also vary greatly.

That’s not to say everything’s perfect on OpenBSD – it’s clearly a hardened server operating system, and its focus on security will definitely throw up annoying hurdles if you’re just trying to do workstation things. Firefox, for instance, is hobbled by strict security rules through unveil, which makes perfect sense for what OpenBSD is first and foremost trying to be, but if you’re just a regular user like me, it’s annoying that Firefox can only access ~/Downloads, or that it can’t set itself as the default browser so unless you disable that check, Firefox will keep complaining about it. Diving into Firefox and unveil is on my list, though, because you should be able to ‘fix’ this.

Furthermore, while every piece of software, or an equivalent, is pretty much always available for Linux, on OpenBSD it’s more hit and miss, and it seems to take a bit longer for new releases of especially bigger software packages to get updated. I mean, there’s obviously no Steam on OpenBSD, but smaller, less well-known projects generally also don’t support OpenBSD, so you’re either going to be compiling things yourself or hope someone packages it up for OpenBSD.

Then there’s the various vanity things we’ve come to expect from modern Linux distributions, like slick, fully graphical boot and shutdown sequences, detailed graphical tools for managing your packages, graphical firmware and driver managers, and so on. OpenBSD has none of these things, and while that’s no issue for me, I can see how it would throw other people off.

FreeBSD, OpenBSD, NetBSD, and the few others often kind of get lost in all the Linux, Windows, and macOS violence, and to be quite honest – I feel like many people in the BSD community seem mostly okay with that. If you’ve never spent any serious time using any of the BSDs, but you’re interested in operating systems and don’t mind spending a few hours learning how to manipulate your system through CLI tools – dive in. There’s a ton of fun to be had, and things to learn.

For now, I’m continuing my exploration of OpenBSD, and if things keep going as well as they are, I may consider at least switching over the workstation in my office from Fedora KDE to OpenBSD – but I highly doubt it’ll ever make its way to my gaming desktop or my laptop.

The big question – does all this have a future? The good news is that all new hardware has generic support in X. Someone writes either a modesetting kernel driver or a classical wsdisplay kernel driver and they will be automatically supported by the associated drivers in X. The bad news is that to have applications running we require access to a larger open source ecosystem, and that ecosystem has a lot of churn and is easily distracted by shiny new squirrels. The process of upstreaming stuff to X.Org is an ongoing process, but it’s likely we’ll run into things that will never be suitable for upstream.

↫ Nia Alarie on the NetBSD blog

I had no idea NetBSD did such heavy customisations of its X.Org implementation, many of which have never made their way upstream. The project also maintains support for several older GPUs, uses its own input driver, and more – it’s quite impressive.

I am trying to use OpenVPN as a client under NetBSD using this command:

openvpn --client --config /etc/openvpn/config.ovpn

I am getting the following output and errors:

localhost# openvpn --client --config /etc/openvpn/openvpn.ovpn 
2024-04-26 10:29:35 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2024-04-26 10:29:35 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 
2024-04-26 10:29:35 OpenVPN 2.6.10 x86_64--netbsd [SSL (OpenSSL)] [LZO] [LZ4] [MH/PKTINFO] [AEAD]
2024-04-26 10:29:35 library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.10
Enter Auth Username:********
Enter Auth Password:********
2024-04-26 10:32:48 TCP/UDP: Preserving recently used remote address: [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 Socket Buffers: R=[32768->32768] S=[32768->32768]
2024-04-26 10:32:48 Attempting to establish TCP connection with [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 TCP connection established with [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 TCPv4_CLIENT link local: (not bound)
2024-04-26 10:32:48 TCPv4_CLIENT link remote: [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2024-04-26 10:32:48 TLS: Initial packet from [AF_INET]**.191.33.**:1701, sid=0006909e 9b0d208f
2024-04-26 10:32:48 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2024-04-26 10:32:48 VERIFY OK: depth=1, C=US, ST=New York, L=New York, O=Ubiquiti Inc., OU=UniFi_OpenVPN_CA, CN=UniFi_OpenVPN_CA
2024-04-26 10:32:48 VERIFY KU OK
2024-04-26 10:32:48 Validating certificate extended key usage
2024-04-26 10:32:48 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2024-04-26 10:32:48 VERIFY EKU OK
2024-04-26 10:32:48 VERIFY OK: depth=0, C=US, ST=New York, L=New York, O=Ubiquiti Inc., OU=UniFi_OpenVPN_Server, CN=UniFi_OpenVPN_Server
2024-04-26 10:33:53 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
2024-04-26 10:33:53 [UniFi_OpenVPN_Server] Peer Connection Initiated with [AF_INET]**.191.33.**:1701
2024-04-26 10:33:53 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2024-04-26 10:33:53 TLS: tls_multi_process: initial untrusted session promoted to trusted
2024-04-26 10:33:53 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.7.1,route 192.168.4.0 255.255.255.0,route 192.168.2.0 255.255.255.0,route 192.168.1.0 255.255.255.0,route 192.168.3.0 255.255.255.0,route-gateway 192.168.7.1,topology subnet,ping 10,ping-restart 60,ifconfig 192.168.7.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'
2024-04-26 10:33:53 OPTIONS IMPORT: --ifconfig/up options modified
2024-04-26 10:33:53 OPTIONS IMPORT: route options modified
2024-04-26 10:33:53 OPTIONS IMPORT: route-related options modified
2024-04-26 10:33:53 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2024-04-26 10:33:53 TUN/TAP device /dev/tun0 opened
2024-04-26 10:33:53 /sbin/ifconfig tun0 192.168.7.2 192.168.7.1 mtu 1500 netmask 255.255.255.0 up
2024-04-26 10:33:53 /sbin/route add -net 192.168.7.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.7.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net **.191.33.** 192.168.1.254 -netmask 255.255.255.255
route: writing to routing socket: File exists
add net **.191.33.**: gateway 192.168.1.254: File exists
2024-04-26 10:33:53 ERROR: OpenBSD/NetBSD route add command failed: external program exited with error status: 1
2024-04-26 10:33:53 /sbin/route add -net 0.0.0.0 192.168.7.1 -netmask 128.0.0.0
add net 0.0.0.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 128.0.0.0 192.168.7.1 -netmask 128.0.0.0
add net 128.0.0.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.4.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.4.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.2.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.2.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.1.0 192.168.7.1 -netmask 255.255.255.0
route: writing to routing socket: File exists
add net 192.168.1.0: gateway 192.168.7.1: File exists
2024-04-26 10:33:53 ERROR: OpenBSD/NetBSD route add command failed: external program exited with error status: 1
2024-04-26 10:33:53 /sbin/route add -net 192.168.3.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.3.0: gateway 192.168.7.1
2024-04-26 10:33:53 GID set to nogroup
2024-04-26 10:33:53 UID set to nobody
2024-04-26 10:33:53 Initialization Sequence Completed
2024-04-26 10:33:53 Data Channel: cipher 'AES-256-GCM', peer-id: 0, compression: 'lzo'
2024-04-26 10:33:53 Timers: ping 10, ping-restart 60

I have a working internet connection when running OpenVPN as a client, but I can't access any of the machines on the network **.191.33.**, I know I should be able to SSH into 192.168.1.114, but I can't reach that machine through OpenVPN, there are firewall rules in the Ubuiquity box allowing traffic from 192.168.7.* to 192.168.1.* I know this is working, its testet from Mac and PC using the OpenVPN Client, I just can't get it to work on NetBSD

This is my routing table before running OpenVPN:

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
default            192.168.1.254      UGS         -        -      -  iwn0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
192.168.1/24       link#2             UC          -        -      -  iwn0
192.168.1.68       link#2             UHl         -        -      -  lo0
192.168.1.254      00:1e:80:a2:2e:ff  UHL         -        -      -  iwn0

This is my routing table when running OpenVPN:

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
0/1                192.168.7.1        UGS         -        -      -  tun0
default            192.168.1.254      UGS         -        -      -  iwn0
**.191.33.**/32    192.168.1.254      UGS         -        -      -  iwn0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
128/1              192.168.7.1        UGS         -        -      -  tun0
192.168.1/24       link#2             UC          -        -      -  iwn0
192.168.1.68       link#2             UHl         -        -      -  lo0
192.168.2/24       192.168.7.1        UGS         -        -      -  tun0
192.168.3/24       192.168.7.1        UGS         -        -      -  tun0
192.168.4/24       192.168.7.1        UGS         -        -      -  tun0
192.168.7/24       192.168.7.1        UGS         -        -      -  tun0
192.168.7.1        192.168.7.2        UH          -        -      -  tun0
192.168.7.2        tun0               UHl         -        -      -  lo0
192.168.1.254      00:1e:80:a2:2e:ff  UHL         -        -      -  iwn0

This is my routing table after stopping OpenVPN:

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
0/1                192.168.7.1        UGS         -        -      -  tun0
default            192.168.1.254      UGS         -        -      -  iwn0
**.191.33.**/32    192.168.1.254      UGS         -        -      -  iwn0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
128/1              192.168.7.1        UGS         -        -      -  tun0
192.168.1/24       link#2             UC          -        -      -  iwn0
192.168.1.68       link#2             UHl         -        -      -  lo0
192.168.2/24       192.168.7.1        UGS         -        -      -  tun0
192.168.3/24       192.168.7.1        UGS         -        -      -  tun0
192.168.4/24       192.168.7.1        UGS         -        -      -  tun0
192.168.7/24       192.168.7.1        UGS         -        -      -  tun0
192.168.7.2        tun0               UHl         -        -      -  lo0
192.168.1.254      00:1e:80:a2:2e:ff  UHL         -        -      -  iwn0

This is my routing table when i have destroyed tun0:

ifconfig tun0 destroy

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
default            192.168.1.254      UGS         -        -      -  iwn0
**.191.33.**/32    192.168.1.254      UGS         -        -      -  iwn0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
192.168.1/24       link#2             UC          -        -      -  iwn0
192.168.1.68       link#2             UHl         -        -      -  lo0
192.168.1.254      00:1e:80:a2:2e:ff  UHL         -        -      -  iwn0

The route to **.191.33.** is still there when stopping OpenVPN and destroying the tunnel tun0, I don't know if this is expected behaviour.

Update I have checked several computers now, and none of them have the 192.168.1/24 route, its only on the PC running NetBSD, I have tried to delete it, with no success. I have also read a lot of man pages and various other documentation, but I have not come up with anything usefull yet.

OpenVPN Config

client
dev tun
proto tcp
remote **.191.33.** 1701
resolv-retry infinite
nobind

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nogroup

persist-key
persist-tun

auth-user-pass
remote-cert-tls server
cipher AES-256-CBC
comp-lzo
verb 3

auth SHA1
key-direction 1

reneg-sec 0

redirect-gateway def1

<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>

Intent

I am trying to connect to a VPN at a remote location, from home. The remote network is protected by a firewall facing the internet, all computers on the network behind the router is accessible, the 192.168.7.* network is standard Ubuiquity and used for VPN clients, I have added a firewall rule to allow traffic from 192.168.7.* to the 192.168.1.* network, this works fine from all computers I have tried it with, Mac, PC, Windows, Linux, MacOS. etc. except a PC running NetBSD.

The network configuration on the PC running NetBSD was performed during installation, and I used the auto-configuration feature, so I have not specified any networks, routes or rules at all. I am able to access the internet when using OpenVPN client, I just cannot access any of the machines on the remote network. So I guess the part I am missing is the routing from 192.168.7.* to 192.168.1.* so I will be able to access computers attached to that network

A few years ago, I wrote a "state of things" blog post about Wayland on NetBSD. It's only natural that I should do one about X11, which is used by far more people to get a graphical environment on NetBSD.

There are a lot of differences from how NetBSD and the typical distributor ship X.Org. For one, we ship it as an optional monolithic package rather than separate individual packages. This means every driver is included on every system, rather than as an optional module. Sometimes, this means we need to fine-tune driver selection to ensure the correct drivers are loaded on the correct hardware, since multiple conflicting drivers can claim a video output. We also want sensible fallbacks, since if you're using a GPU from the future with an old OS version, you probably want X to seamlessly fall back to a regular framebuffer.

Secondly, the way our "xsrc" repository is set up, it's effectively functioning as a fork of X.Org that regularly pulls from upstream freedesktop.org (but does not push back). This allows X development to happen as part of NetBSD.

Thirdly, we use our own build system based purely on BSD makefiles, not X.Org's based on GNU autotools. This fits well with our build.sh cross-compilation system.

We have a number of drivers which have not made their way upstream. Perhaps the most ubiquitous of these is xf86-input-ws, a driver which came from OpenBSD, targets an API from NetBSD, and continues to be developed in both. This is a generic input driver that can support any pointing device that the kernel supports. Unlike xf86-input-mouse, it doesn't assume the device is a mouse, and can support advanced touchpad and touchscreen features. Other NetBSD exclusives include xf86-video-pnozz, xf86-video-mgx, and xf86-video-crime. While these all share the "xf86" name inherited from the historical XFree86 distribution, none of them are exclusively for x86.

There are a number of drivers that are accelerated when used in NetBSD, but the acceleration support is missing upstream. This is mostly due to the work of macallan@, who has diligently worked on drivers for accelerators found on SPARC and PowerPC hardware.

X.Org has historically supported two 2D acceleration modes, XAA and EXA. XAA seems complicated - according to the X.Org Foundation it supports accelerating "patterned fills and Bresenham lines" (eh?). XAA was removed from the X.Org server in 2012, and many old drivers were not updated to support the newer and simpler EXA model, except in NetBSD, over a time period of several years.

Did you know that Nvidia used to have an open source graphics driver? It supported 2D acceleration for a range of cards. In NetBSD, it's retained for platforms that included embedded Nvidia chips and aren't capable of (or predate, or don't want) the modern novueau driver. Six years ago, it was updated in NetBSD to support EXA acceleration.

There are a few ways our X integration could be improved. While lots of attention has been paid to the server, less has been paid to clients (programs). Did you know that X includes a text editor, and that text editor supports syntax highlighting and spell checking?

NetBSD includes its own command-line spell checker and associated dictionaries, spell(1), inherited from the BSD UNIX of yore. It's pretty basic, and only supports variations of English. To get spell checking to work in xedit, you need to install ispell (another command-line spell checker) from pkgsrc, install a dictionary, then set some Xresources (or create symlinks) to make sure xedit finds ispell. This could surely be streamlined by teaching xedit about spell.

We also ship every program that has been included with historical X.Org distributions. This includes well-known things like xterm, slightly less well-known things like xbiff(1), and obscurities like bitmap(1) (apparently a 1-bit-per-pixel alternative to MS Paint). A while ago, we removed some libraries which are no longer used by the modern X server, and maybe we should evaluate whether we need all of these programs too. xmh(1) is a frontend for a mail system that isn't included in base. Together, bitmap and xmh are around 300 kilobytes.

We include fonts, bitmaps and scalable, for a wide range of computing devices. In the latest versions of NetBSD, the font size will automatically scale with the screen size to support HiDPI displays as well as small mobile devices. However, we don't ship a scalable cursor theme at the moment. We're also missing high-resolution fonts for Japanese, a shame considering the popularity of NetBSD in Japan. Koruri looks interesting and is suitably small, maybe we should import it.

While we have many useful simple programs by default (a clock, a calculator, an editor, a window manager, a compositor, a terminal emulator...), we're notably missing a screen locking program for X in the default install, although we have lock(1) for the tty.

The big question - does all this have a future? The good news is that all new hardware has generic support in X. Someone writes either a modesetting kernel driver or a classical wsdisplay kernel driver and they will be automatically supported by the associated drivers in X. The bad news is that to have applications running we require access to a larger open source ecosystem, and that ecosystem has a lot of churn and is easily distracted by shiny new squirrels. The process of upstreaming stuff to X.Org is an ongoing process, but it's likely we'll run into things that will never be suitable for upstream.

Of course, on NetBSD, you also have the option of trying vanilla modular X.Org from pkgsrc, or using something else entirely.

In February last year I wrote about running a FreeBSD desktop, and concluded that sometimes you need to give yourself permission to tinker.

Well recently I’ve started tinkering with Alpine Linux! It’s been recommended to me for years, so I’m finally getting around to checking it out. There’s a lot to like if you come from BSD, which we’ll dig into here.

A potted history

The Alpine website describes it as:

an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency.

Its small footprint and design decisions also make it more secure:

All userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. These proactive security features prevent exploitation of entire classes of zero-day and other vulnerabilities.

Natanael Copa discussed the genesis of the project back in 2005, making it older than I realised. Like the BSDs, it’s found its way into embedded systems, routers, and mobile devices, as well as general purpose servers and desktops.

Alpine is also a popular base for use in Linux containers, owing to its compact size and limited dependencies. There are also toolchains for easily running it in a chroot(8), which is interesting for someone who uses NetBSD chroots(8) and FreeBSD jails extensively for testing and deployments.

Installation

Alpine comes in a few different versions, including builds for ARM, PPC64, x86, and x86_64.

I downloaded the Xen ISO image because I was booting it on a VM at work, before realising I misread Dom0 as DomU. The former refers to a Xen hypervisor, not a guest. Either way, it booted and installed the same as a standard ISO.

The install process is about as simple as you could make it. You log into the live environment with root and no password, then execute setup-alpine.

You’re asked basic questions for your keymap, networking, timezone, and root authentication. You can also inject an SSH key from the start, which is useful if you’re deploying a fleet of VMs or servers with an orchestration tool after the fact, or you’re deploying to a mediocre hosting provider that doesn’t give you an OOB console.

You’re also given the choice of a few different SSH servers and ntp clients, which let me choose my preferred OpenSSH and openntpd. It also correctly identified it was operating under Xen.

It can also configure an LVM, but I stuck with what Alpine calls standard sys partitions for now. This uses ext4.

Post-install and exploration

Booting into Alpine for the first time, your given a hint as to why it’s special: dmesg(1) informs you you’re running OpenRC! It’s portable, small, fast, efficient, transparent, and secure. It’s also very familiar to a BSD person used to writing rc scripts. /etc/rc.conf and crond(8)!? Yes!!!

At the risk of embellishing my feelings about this, it is such a relief that there are Linux distros like Devuan, Gentoo, and Alpine using this. It’s a breath of alpine air, and has legitimately made Linux fun again.

Along with OpenRC, Alpine is bundled with musl, and runs busybox. Both are obviously more limited than GCC and the GNU coreutils, but they further contribute to the base system’s smaller size and attack surface. llvm is also available, as is the MirBSD Korn shell, one of my two preferred interactive shells.

Um, Ruben, I’d like to interject for a moment. What you are referring to as Linux, is in fact, GNU/Linux, or as I’ve recently taken to calling it, a GNU grilled cheese sandwich merely featuring Linux as the…

… nope!

Packages

Speaking of installing packages, let’s take a look at that. Alpine’s default package manager is apk. As is normal on Linux, this handles updating the base system and all packages, because it makes no distinction. I’d be interested to see if I could also run an unprivileged copy of this as I like to do on the BSDs, but I haven’t checked yet. There’s also pkgsrc, so no biggie.

Configuration is in /etc/apk/repositories, where you can enable the community repo by uncommenting the second URL supplied by the installer. Alpine also has a testing repo, and you can add your own.

Usage is easy, though I’ve still been mistyping apt install instead of apk add, because old habits die hard. There’s an official web interface, and Alpine repos are on pkgs.org.

A few packages later, and I had my “essentials” going, like I do on my console-only laptop:

Perhaps the package I was most surprised about was zfs. It was literally two commands to install and load the kernel module (though obviously root on ZFS would be more involved). What that would look like after an upgrade I’d have to see, but thus far I’m impressed.

# apk add zfs zfs-lts
# modprobe zfs

Conclusion

I’ve barely scratched the surface, but there’s enough here for me to seriously consider a switch to it as my primary Linux distro for testing and servers. I love that htop(1) and lsof(1) only shows a small list of recognisable processes, that it uses OpenRC, that package management seems straight forward, and that it’s so simple to configure. I’ve wondered what a modern, functional “Occam’s Linux” would look like. This is it.

I’d be interested in seeing if uutils runs if I need something more than busybox, but for a server I doubt it.

I heard you liked Alpine, so I etc…

By Ruben Schade in Sydney, 2024-04-26.

The NetBSD Project is pleased to announce NetBSD 9.4, the fourth release from the NetBSD 9 stable branch.

It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 9.3 in August 2022, as well as some enhancements backported from the development branch. It is fully compatible with NetBSD 9.0. Users running 9.3 or an earlier release are strongly recommended to upgrade.

The general NetBSD community is very excited about NetBSD 10.0, the latest NetBSD release, but if for some reason you can not (or do not want to) update to 10.0, it is strongly recommended to update to 9.4. This is especially true for users still using a NetBSD 8.x release as that old release branch will be desupported by the end of April 2024.

Full release notes, including download links

If you sorta squint and tilt your head, it’s a games theme this week.

• Roguelike vs. Roguelite: What’s the Difference?  (via)
• Awesome-Selfhosted.  (also via)
• rigg 1.0 released – a new way to run indie games on OpenBSD.
• SEthernet: Modern, low-cost 10/100 Ethernet for the Macintosh SE and SE/30.
• Mastodon for Apple II (][+, //c, IIe, and IIgs)
• Hex marks the spot.  (via)
• pkgsrc-2024Q1 branch released, and NetBSD 10.0.
• Further Explorations, the companion volume to 50 Years of Text Games, is available for standalone purchase.  Related: merchandise.
• The Greenwich prime meridian isn’t where it used to be.
• FreeBSD Speedrun.
• Terminal status bar with only stock tools.

Your unrelated music for the week: New Strategies for Modern Crime Vol 1.  (via)

Hi! My name is Ruben Schade, and I’m a solution architect for an indie cloud company who mostly runs Linux, but tries to use FreeBSD and NetBSD where he can. This is my story. LAW AND ORDER DUN DUN

The post

Yesterday I saw the news that Microsoft will be including ads in an upcoming Windows 11 update, which so perfectly encapsulates all that’s wrong with modern IT. I saw a few people post about it on Mastodon, which generated dozens of comments from Linux fans saying the real solution was to switch to their OS.

Before I went to bed, I posted:

Linux people, please understand this. Sometimes people need to run Windows. They’re allowed to complain about Windows ads, or tracking, or any other enshittification problems, without you saying “use Linux” every time.

Suffice to say, I woke up to a storm of certain Linux people… not understanding this. But a few themes emerged, which I thought I’d respond to in aggregate here instead.

Replies that miss/ignore the point

• I don’t understand why someone would need to run Windows. If I offered you $1,000, I’ll bet you could think of some reasons. Don’t take me up on that though, I’m trying to save for a house. In this economy!?

• Using Windows makes you a cog in the capitalist machine. This assumes agency. Also, no.

• I’m philosophically against Windows. I might be too. It’s irrelevant.

• You don’t have a right to complain if you use Windows. Big we should improve society somewhat vibes with this.

• You deserve all the hate coming your way. I’ve certainly learned my lesson.

• It’s GNU/Linux. No comment. Wait, that’s a comment. Fsck.

• I don’t understand why you’re so angry/frustrated/etc. Probably the most honest thing they could have said.

Replies that address the point

• Run within a VM. This at least solves the technical issue of certain hardware or software not working on Linux. Running a VM isn’t always feasible, but the point at least acknowledges that Windows is unfortunately still necessary.

• Use Wine, or some other shim. Again, not always tenable, and you’re smart enough to know why. But the community is making incredible strides, even in gaming.

• I love how many people are proving your point. Self-awareness definitely seems lacking among a cohort of Linux people, even though we may see eye to eye on a lot of things. That does make me a bit sad.

By Ruben Schade in Sydney, 2024-04-14.

I am trying to write a driver for NetBSD that will reserve 10 pages of virtual memory, then provide the first 5 pages with physical addresses. At the end, I output the page number, its physical address, and flags such as Valid, User and Modified. However, it seems to me that the flags are not working correctly, since for all pages, all flags have the same value, which is 1 (true). Please help me figure out what I'm doing wrong.

#include <sys/cdefs.h>
#include <sys/module.h>
#include <sys/param.h>
#include <sys/sysctl.h>
#include <uvm/uvm.h>

MODULE(MODULE_CLASS_MISC, driver, NULL);
#define PAGESIZE 0x1000
extern paddr_t avail_end;
vaddr_t va;
struct pglist plist;
static int lab4_modcmd(modcmd_t cmd, void* arg) {
   va = uvm_km_alloc(kernel_map, PAGESIZE*10, 0, UVM_KMF_VAONLY);
   if (va == 0) {
      return 0;
   }
   int error = uvm_pglistalloc(PAGESIZE*5, 0, avail_end, 0, 0, &plist, 5, 0);
   if (!error) printf ("LAB4 loaded\n");
   struct vm_page *page = TAILQ_FIRST(&plist);
   for(int i = 0; page; i++) {
      pd_entry_t *ppte;
      ppte = L2_BASE+pl2_i(va+PAGESIZE*i);
      paddr_t pa = VM_PAGE_TO_PHYS(page);
      printf("Page - %d\n", i+1);
      printf("Valid - %d\n", ((*ppte & PG_V) ? 1 : 0));
      printf("Used - %d\n", ((*ppte & PG_U) ? 1 : 0));
      printf("Modified - %d\n", ((*ppte & PG_M) ? 1 : 0));
      printf("Physical address - 0x%lx\n", pa);
      printf("\n");
      page = TAILQ_NEXT(page, pageq.queue);
   }
   uvm_pglistfree(&plist);
   uvm_km_free(kernel_map, va, PAGESIZE*10, UVM_KMF_VAONLY);
   return 0;
}

I tried to look for other examples where these flags are used.

It’s funny that I field almost as many sysadmin questions about Minecraft than I do BSDs thesedays. Even Minecraft on BSD! This post addresses the most common question after running Minecraft on FreeBSD, and on NetBSD. I’ll assume here that you have a functional server, and know how it works.

Say you have a map running on your local Java Minecraft install, and you want to import it as another into a Java multiworld server running Paper (as I recommend), such as one running MyWorlds or Multiverse. How do you do this?

Locating your Minecraft data directory

First, access your saved local world in the appropriate location:

• Windows: %appdata%\.minecraft
• Mac: ~/Library/Application Support/minecraft/
• Linux: ~/.minecraft/

Within this folder, you’ll have a folder called world. This contains your world data, along with subfolders for the associated Nether (DIM-1) and End (DIM1) worlds. These are generated when you first create the world, even if you’ve never accessed them:

• ./world/
  • ./DIM-1/
  • ./DIM1/

Importing without mutliworld, and some context

Importing is easy on a Minecraft server without multiworlds. You copy the world folder into the Minecraft server folder before starting the server, then run. If you’re importing into an existing server, you’ll want to backup and move the existing world folder elsewhere first before replacing it, unless you don’t need it anymore.

You’ll notice that after importing, the server has rearranged the worlds into their own folders in the server directory:

• ./world/
• ./world_nether/
• ./world_the_end/

This works, but what if you use a multiworld plugin and want a custom folder name for this world?

Importing with a multiworld plugin

It’s important to note that the Minecraft server will only import world folders. If your imported world is called something like resourceserver, it won’t import the Nether or End worlds automatically. This might not matter to you, but you’ll end up teleporting to your server’s default Nether or End, not the ones you expected.

The temptation is to rename DIM-1 to world_nether, and DIM1 to world_the_end, as several forum posters and AI-generated guides suggest. This doesn’t work, because the other two worlds are missing metadata. Thanks GPT, you monumental waste of resources!

The solution I’ve found is to temporarily rename the imported world as world, let the server import it, then rename it to what you wanted. In more detail:

1. Stop the Minecraft server, and temporarily rename the existing server world folder to something else, like world_backup.

2. Copy your local imported world folder into the server, leaving the name of the folder set as world.

3. Start the Minecraft server, letting it rearrange the folders into world, world_nether, and world_the_end, then generate the required metadata for each.

4. Stop the Minecraft server again, then rename the folders to what you want, such as resourceserver, resourceserver_nether, and resourceserver_the_end.

5. Rename your original world_backup back to world again, assuming you want this to be the default.

6. Start the Minecraft server again, and import your world.

Importing the world, and its attached Nether and End

If you use MyWorlds like I do, you can now import the worlds from the game with these:

/myworlds load resourceserver
/myworlds load resourceserver_nether
/myworlds load resourceserver_the_end

Donezo.

By Ruben Schade in Sydney, 2024-04-11.

I have the following code that produces a window with a QTableView visible. I add a QTextEdit to the right but hide it. When I run the code it looks as though space has been reserved on the right for the TextEdit even though the TableView has a setSizePolicy of Expanding. What do I need to set so that the TableView initially takes up all the space in the window, then shrinks to accommodate the TextEdit and then expands fully when the TextEdit is hidden? Thank you in advance.

import sys
from PyQt5.QtWidgets import QApplication, QGridLayout, QMainWindow, QPushButton
from PyQt5.QtWidgets import  QSizePolicy, QTableView, QTextEdit, QWidget

class MainWindow(QMainWindow):
# https://www.pythonguis.com/faq/file-image-browser-app-with-thumbnails/
    def runBtn(self):
#https://www.youtube.com/watch?v=LCJEyuCZlAY
        if self.hdn == True:
            self.text.show()
            self.hdn = False
        else:
            self.text.hide()
            self.hdn=True

    def __init__(self):            
        super().__init__()
        widget = QWidget()
        self.setCentralWidget(widget)
        self.layout = QGridLayout(widget)
        self.hdn = True

        self.Btn = QPushButton('Hide/Show',self)
        self.Btn.clicked.connect(self.runBtn)
        self.layout.addWidget(self.Btn, 0, 0, 1, 1)

        self.view = QTableView()
        self.layout.addWidget(self.view, 1, 0, 48, 50)
        self.view.setSizePolicy(QSizePolicy.Expanding, QSizePolicy.Expanding) # /73522221/

        self.text = QTextEdit()
        self.text.hide()
        self.layout.addWidget(self.text, 1, 50, 48, 2)

app = QApplication(sys.argv)
window = MainWindow()
window.show()
app.exec_()

A few weeks ago, Apple released new versions of Xcode and Command Line Tools. Not thinking too hard about how my pkgsrc developer environment often gets broken by OS or tool updates, I updated promptly. For one thing, I’m kinda used to it. For another, it doesn’t usually break. For a third thing, managing dependencies — anything not my code that can break my code — means responsibility for dealing with the inevitable trouble, and therefore the sooner I find it the better. (More on my approach to life with dependencies.)

A vendor-provided toolchain is a significant dependency. So I accepted the Command Line Tools update, and it commandeered my spare time for two weeks as I hurried carefully to repair one of the world’s biggest continuous-integration cauldrons on one of its most popular platforms. When I ran my usual pkg_rolling-replace -suv to rebuild anything outdated, it did not go well at all.

Did I mention that a few weeks ago we were aiming to stabilize for yesterday’s quarterly release? Suddenly, if we didn’t scramble to straighten things out for macOS users, we’d have to manage a complicated situation for a while. But if we created a mess on other platforms by moving rashly, that’d be even worse.

The usual feedback mechanism for proposed infrastructure changes is to compare full bulk builds before and after. There was no time for that.

Happily, the conclusion of the story is boring: as always, the pkgsrc 2024Q1 stable branch supports macOS and its developer tools, including the latest releases of each. (So does -current pkgsrc, of course, if that’s your thing.)

Curious what we had to do to keep it boring? Read on.

Stricter clang defaults

Upstream Clang 16 and GCC 14 have promoted several warnings to errors by default, and Apple’s Clang 15 has followed suit. (Gentoo has very helpfully documented this for packagers.) These changes are intentional and well-intentioned, pushing maintainers to ship more reliable code. But pkgsrc’s job is to build nearly 30,000 codebases we don’t maintain. And stricter compiler defaults break a lot of builds.

As you might hope, we can make the breakage go away in one place.

In pkgsrc, packages declare which programming languages are required for their build. The compiler framework then selects package-and-platform-appropriate compilers, places them preferentially in the package’s build environment, and — crucially — intercepts compiler invocations and rewrites them for a variety of purposes.

When we look into pkgsrc’s clang logic, we find prior art for this specific class of problem. In September 2020, Xcode 12 (and its associated Command Line Tools) arrived even later in our quarterly schedule and promoted -Wimplicit-function-declaration to an error. The surgical fix: on macOS only, if invoking clang reveals the new stricter default, we pass -Wno-error=implicit-function-declaration to demote the error back to a warning.

Apple Clang 15’s new strictures aren’t observable in the same way, so we adjust our workaround: if clang doesn’t complain when we try demoting the new errors back to warnings, we pass those arguments too, via the same compiler-framework mechanism.

Missing m4 and yacc

This messy regression found only in the Command Line Tools 15.3.0.0.1.1708646388 update — not in the corresponding full Xcode 15.3 (build 15E204a) update — must have been unintended.

On macOS, some of the familiar Unix tools in /usr/bin are in fact stubs. When invoked, they either execute into the corresponding installed program (living somewhere under /Library/Developer) or prompt the user to install the Command Line Tools.

This Command Line Tools update uninstalls m4 and yacc from /Library/Developer. But since the OS-provided /usr/bin/m4 and /usr/bin/yacc stubs still exist, running m4 or yacc still does something: it pops up a window prompting you to reinstall the CLT. Unfortunately, as the latest available version doesn’t provide those tools, reinstalling is a waste of time.

As you might once again hope, we can hide the problem without personally visiting 29,000+ packages.

In pkgsrc, we also have a framework to control which non-compiler tools are invoked during builds. Packages declare which tools are required for their build. The tools framework then selects package-and-platform-appropriate incarnations of the declared tools and places them preferentially in the package’s build environment.

We just got handed a few new twists to handle in the framework, is all.

First, because this clever new CLT failure mode outfoxes our usual tool-detection mechanism, we special-case m4 and yacc detection on macOS, performing an existence check for the stubs’ targets. Then the selection mechanism’s usual fallback logic can provide them some other way. This prevents the primary source of needless CLT install popups. For non-macOS platforms, no change.

Second, because some packages might not yet be declaring all their tool dependencies, we special-case m4 and yacc handling on macOS: when they’re not declared, we place them in the build environment anyway, as no-ops. If the package build happens to invoke them, nothing happens. This prevents the secondary source of needless CLT install popups, at the risk of breaking macOS builds for packages that are missing these tool declarations and have heretofore gotten lucky; in such cases, the breakage will be obvious and the fix easy. For non-macOS platforms, no change. (At leisure, we might like to broaden this approach to help find and fix all undeclared tools on all platforms.)

Third, because the flex tool expects to invoke a GNU-compatible m4, we adjust the tools framework to infer gm4 from a flex declaration so that the framework controls which m4 gets found. This more correctly expresses our intent on all platforms, and in the macOS package build environment it restores /usr/bin/flex to a working state.

Broader xcrun search

We were already relying on xcrun for a couple of things, so when our new tool-detection special cases were sometimes getting surprising results from it, that was concerning. Turns out xcrun no longer looks solely in Apple-controlled locations, but also consults the environment’s $PATH. By invoking xcrun with an empty PATH and --no-cache, we obtain controlled, predictable tool detection.

Conclusion

Under the constraints, we changed as little as possible, as safely as possible, as similarly as possible to previous proven changes, avoiding novel constructs or any whiff of unforeseen consequences. We could not have done nearly as safe or thorough a job without good abstractions already in place. Total lines of pkgsrc infrastructure code changed: less than 100. Now that 2024Q1 is out, we have room to refactor.

These 15.3 updates also include a brand new linker. So far it hasn’t given us any trouble. If that changes, wanna guess whether we have one place to take care of it?

This is the ninth post in my toolchains adventures series. Please check the previous posts in the toolchains category for more context about this journey. There was no Q4 2023 report as there wasn't really anything worthwhile to write about.

I've been taking a break from Pkgsrc to only focus on OpenBSD at this point, for which I updated binutils to version 2.42 in the ports tree.

During this OpenBSD release cycle, the remaining parts required to get pinsyscalls(2) working have been committed, and I added support upstream for the PT_OPENBSD_SYSCALLS segment type to readelf in GNU Binutils, as well as in LLVM versions of objdump and readobj.

Lastly, I also wrote a blog post about Speedbuilding LLVM/Clang in 3 minutes on Power10.

As usual, I’ve also been busy reading different material, and adding new resources to toolchains.net.

binutils commits:

LLVM commits

The NetBSD project is pleased to announce the eighteenth major release of the NetBSD operating system NetBSD 10.0!
See the release announcement for details.

The netbsd-10 release branch is more than a year old now, so it is high time the 10.0 release makes it to the front stage. This matches the long time it took for the development branch to get ready for branching, a lot of development went into this new release.

This also caused the release announcement to be one of the longest we ever did.

If you want to try NetBSD 10.0 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

Recently, a backdoor was discovered in the xz compression library. xz/liblzma are included as a part of NetBSD and used by the project for distribution of new releases and packages.

The version of xz shipped in all stable (and unstable) versions of NetBSD predates any code changes by the author of the backdoor. NetBSD is therefore safe and unaffected by the recent discoveries. It is believed that the attack only targets Linux/glibc, but checking this allowed us to rule out any other attempts at compromising the library by the author.

The version of xz shipped in pkgsrc, however, is affected. Using xz from pkgsrc is a non-default setting on NetBSD, and requires explicit opt-in. Most users of NetBSD will not install xz from pkgsrc because the version from the base system is preferred. However, users of pkgsrc on other platforms will need to take precautions.

Regardless of NetBSD being affected or not, the discovery of the backdoor is a wake-up call and further discussion will be happening internally over how to proceed.

A sixth Release Candidate of my other favourite OS was made available on the 12th of March. From the NetBSD blog:

RC6 fixes a few issues with the new named/bind imported for RC5 plus several minor issues.

If you want to test 10.0 RC6 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

This is old news for the NetBSD community, but I mentioned that I’d been testing RC5 last month, so I felt like I should pass this on.

By Ruben Schade in Sydney, 2024-03-22.

I'm debugging the NetBSD kernel with gdb, but I would like to be able to display information about the memory region an address is in. I'm mainly interested in finding out the permissions of a page of memory, along with the size of the region it is enclosed in (if the latter part of that question makes sense).

Does the kernel have a concept of memory regions in kernel space? i.e. a contiguous block of pages (virtual addresses) reserved for a specific purpose (which is kept track of somewhere)? Or is it down to each specific module to keep track of which blocks of memory belong to a logical group?

Here's an example of what I'm looking for:

(gdb) addressinfo 0xffffffff80e1000

                Start                End    Offset    Perm     Size
    0xffffffff80e0000  0xffffffff80e2000    0x1000    r--p     0x2000   

I don't mind adding a hook to the kernel for a GDB script to output this information, if this functionality does not exist. At the minimum it would be useful to add a hook for GDB scripts to view the page permissions.

Command line / history is I guess the mini-theme.

• ELIZA Effect, something important to remember about AI.  From a dinosaur blog of all places.
• The Art and History of Lettering Comics.  Authoritative work from a master in the field.  You have seen his work even if you do not realize it.  (via)
• State of the Terminal.  (via)
• The Life and Death of the Bulbdial Clock.  Links to interesting sources.
• Failing to Fail: The Spiderweb Software Way.  (via)
• Regular Expression Matching Can Be Simple And Fast.  (via)
• Related: Structural Regular Expressions (PDF).  You may not be surprised to see it’s by the author of sam.  (via)
• Followup: video is up for the most recent NYCBUG event, “NetBSD for the Advanced Minimalist“.
• Editing long commands in your shell.  (via)

It took almost a year of tinkering, buying parts, testing, configuring, fixing, cursing, and shouting with excitement, but I now have a KVM setup that finally works, across two decades of computer history from a Commodore VC-20 to a Dell Dimension Pentium III!

We start with this assortment of parts to take signals and convert them to VGA for my KVM, inspected for quality by one of Clara’s Prince Cats. Some of these ended up being replaced or not used.

Clokwise from left to right we have:

1. The RetroTINK-2X-Pro, with a Belkin HDMI to VGA adaptor. This box of wonders converts and upscales the S-Video from my 8-bit Commodore machines with zero configuration and fuss. The Belkin converts this to a crisp VGA signal for the KVM.

2. A DB13W3 connector. This converts the Sun TurboXGX frame buffer card on my Sun SPARCStation 5 to VGA.

3. The GGLabs CGAtoRGBv2. This converts the EGA signal from my Am386 tower to 15 KHz VGA, which surprisingly my VGA LCD accepts. It might also work with my Commodore 128’s 80-column mode eventually, if I get its VDC working.

4. A cheap S-Video and Composite to VGA converter (retired). I used this with the Apple //e before I got the ∀2 Analog VGA card. It was fine.

5. Luis Antoniosi’s MCEtoVGA converter (retired). Worked fine for EGA, but the GGLabs card has no artefacting or fuzziness.

6. The ∀2 Analog (not pictured). This card generates a VGA signal from any slot on an Apple ][, including my //e Platinum. 80 column colour is not only feasible on this machine now, but it looks stunning!

The next piece was my handsome beige KVM, which I got on eBay for a steal because it had no cables; something I later came to regret! But I finally have cables now.

With these connectors, we now have the KVM ports set up like this:

1. Am386 EGA → CGAtoRGBv2 → VGA
2. NEC APEX 486 DX2 → VGA
3. DIY childhood P1 → VGA
4. Dell Dimension 4100 P3 → VGA
5. Sun SPARCStation 5 → DV13W3 adaptor → VGA
6. 8-bit Commodores → RetroTINK → HDMI → VGA
7. Apple //e Platinum → ∀2 Analog → VGA
8. Reserved for another upstream KVM? Gulp

And it works! I can press the button on the KVM, or invoke a key command, and jump between DOS 3.3 on my Apple //e, to NetBSD on the SPARCStation, then across to GEM on the 386, then check where my BNSF GP38-2 is up to in Train Simulator on my Dell.

It’s a hornet nest of cables, and I can’t tell you how happy I am now! Well, I guess I just did! Now it’s time to update Sasara.moe with all this stuff.

FAQs

• Why did you do a lossy conversion from HDMI to VGA? Beacuse the RetroTINK outputs HDMI, and my KVM uses VGA.

• Why use a VGA KVM, not DVI or HDMI? Because VGA is the highest common denominator across all these machines, and my beige NEC LCD uses VGA.

• Surely your Dell has DVI? Yes, but see above.

• Which 8-bit Commodore machines do you use with this setup? Right now it’s a VC-20 [sic], 64C, C128 (40-column mode only, the 80-column VDC circutry is currently borked), C16, and a Plus/4. Clara’s and my shared retro server Sasara.moe has the full list. The 64C is my daily driver, with the others in a glass cabinet to the side where I can easily access them and swap them out (unlike the massive Apple //e)!

• I can never get these converters! How did you? It can be tricky, they come in and out of stock constantly. The best thing to do is to subscribe to Tindie sellers so you get an update as soon as they’re available, and keep some money budgeted to the side so you can pounce.

• You should use $FOO or do $BAR instead. Where were you yesterday?

• What did you use for the keyboard and mouse? I used AT to PS/2 for the keyboards, and serial to PS/2 for the mouses where necessary. This did rule out having a more modern optical mouse unfortunately, but I have nostalgia for that Microsoft Dove soap bar mouse anyway.

• Have you tried the RGBtoHDMI? I’ve heard great things, but this setup works for me.

• Can you help me troubleshoot my own complicated video setup? In the words of a ship’s rigger, I’m a frayed knot. This was all trial and error, mostly error, and I’m not in a hurry to repeat the experience.

• What VGA cables did you use? I ended up finding some second-hand Belkin KVM cables, and a high-quality shielded cable to go to the monitor.

• What about your other machines? I have some other late 1990s PCs, but their function mostly overlaps with the Dell that has the best specs. At some point I’ll wire them into this spaghetti, but right now they’re museum pieces until I get more space.

• Was it worth it? If you’re in a tiny apartment like me, its the difference between having retrocomputing as an accessible hobby, and not. If I had a decent-sized place with a hobby room, I’d much rather have dedicated setups for each machine, or at least each generation of machine.

• Do any of Clara’s Prince Cats help with configuring the machines too? As a matter of fact, yes.

By Ruben Schade in Sydney, 2024-03-17.

The March 6 NYCBUG meeting is coming up, and it sounds like something I’d want to see: NetBSD for the Advanced Minimalist, working remote using only a $100 Pinebook.  Be sure to RSVP if you can go cause this is in-person and they need to know who is coming into the NYU facility.

I have create a disk image on netbsd

newfs -F -s 10G 1.img

How to mount it?

I have tried "nodev" but give error and try to mount /mnt/p2

mount -v -o nodev /home/user/1.img /mnt/p2

Mini-theme: collections of media.

• Backblaze Drive Stats for 2023.
• ROMchip: A Journal of Game Histories.  (via)
• NetBSD 10.0 RC4 available!  There’s now a Wii port, which is neat.  (via)
• The Salmar Construction, a 1970s “large music synthesis engine”.  (via)
• The miracle of the commons.  Principles that apply to open source projects.  (via)
• Reversing the Web-@nywhere Watch: browse fragments of the Web on your wrist.
• An RNG that runs in your brain.
• Lost infosec battles.
• The Schickele Mix Online Fan Archive.  (via)
• This message does not exist.
• Computational Poems.  (via)
• At long last: the MWL Title Index.
• A Simpler Life: Trapping Spambots Based on Target Domain Only.

Your unrelated music link of the week: Omni: Souvenir.