washbear

This is not the reason. We created this branch in July 2025 (GCC 12.5 was released on 11 July, 2025) and spent a year stabilizing it. A new system compiler is considered far too much of a risky, incompatible change to backport. Especially since lots of C code no longer compiles with GCC 14+ without significant changes.

Each time we upgrade the system compiler, it requires extensive work to keep all of our supported architectures in working order, and adjust our code for compatibility.

This is partly the reason, the other reason is that we created this branch in July 2025 (GCC 12.5 was released on 11 July, 2025) and spent a year stabilizing it. A new system compiler is considered far too much of a risky, incompatible change to backport. Especially since lots of C code no longer compiles with GCC 14+ without significant changes.

People get "POSIX compliance" confused with "Unix certification". The first is an API you implement, the second is a rubber stamp.

All active Unix-like operating systems aim to implement the new interfaces as they're defined.

If that's your first target for removal, I'd wager a large amount of money that you're [unfamiliar](https://man.netbsd.org/compat_freebsd.8) with the NetBSD code base.

This is part of the contract all new committers are required to sign. Becoming a NetBSD committer requires membership of the NetBSD Foundation and there's an understanding that trust is expected.

The article is wrong, it has branding disabled (so it identifies as Nightly), but it's stable Firefox. And the linked article indicates that one compositor can be used.

Yes, X11 works. Feature chart here: https://wiki.netbsd.org/ports/evbarm/apple/

Not true; we have podman

The author of the post probably accidentally hit the Compose key before comma by mistake. Compose comma comma produces that character.

https://en.wikipedia.org/wiki/Compose_key

A very NetBSD mistake.

I wonder if there's a PDF reader that can render to sixel graphics - mlterm-wscons can display sixels.

It's "big in Japan". Used on many ISP routers there, for example Internet Initiative Japan's "SEIL" family, as well as most workstations in a few Japanese universities.

pkgsrc enjoys mild popularity in the scientific computing community, a lot of NetBSD use is probably in education - Cambridge University uses it for their thin clients too.

This is exactly the type of hardware where NetBSD shines - it's often best to install it on something from a few years ago where driver support has matured to a fine vintage. Very good OS for preventing old hardware from being binned.

> I may have some useful hardware sitting around here at the house. Some of it may be 20 years old. How can I tell whether any of it will be useful to this project?

NetBSD developer hat on

It will likely be very useful, martin would particularly like CardBus and PCMCIA hardware, though he's kind of overwhelmed by requests right now.

If you can find some way to get the chipset identifier (maybe check dmesg, usbdevs/pcidevs if your operating system provides such a command), that's the useful information that he needs.

> Why are you comparing pkgsrc to pacman.

The original commented suggested that XBPS was similar to pkgsrc. I suggested that XBPS has far more in common with Arch Linux's package manager than pkgsrc or anything else in the BSD world. As you yourself note in your next paragraph...

> Your comments do not sound like those of a daily NetBSD user.

I have commit access. Since three years ago. My name is on the latest release announcement.

You prick.

Actual package recipes. BSD-style packaging systems are written in BSD make using a mk/ framework rather than Arch-style shell scripts. If a package already exists for FreeBSD Ports I would check that first because it's much more similar to what I'm used to.

Fundamentally pkgsrc is built on very low level tools, awk, shell, make, cwrappers, and pkg_install, although you can manage it with high-level ones (obviously pkgin is there, but there's also a lot of other third-party tooling).

One reason to try it might be that pkgsrc mostly solves the problems Nix solves with conflicts in a much simpler way, by allowing multiple co-existing branches installed to different prefixes.

Such a thing exists - https://github.com/oasislinux/oasis

It is nowhere near as cross-platform as pkgsrc - it only really supports macOS and Linux.

As a pkgsrc committer, xbps is nothing like pkgsrc. The underlying stuff is much more similar to something like Arch or Alpine Linux than anything that exists in the BSD world, and it's much less configurable than pkgsrc.

Aside from the obvious BSD things (clean separation of base and third-party software, very different networking stack, etc), notable NetBSD things include a lot more security and hardening features enabled by default, a powerful and versatile default package manager (https://pkgsrc.org/), very good support for ARM (all 'mainline', etc). The NPF firewall is also quite nice.

the core difference now is that Sun and tens of other unix vendors are dead so there's less competing commercial influences to the Linux crowd involved in maintaining this stuff.

note that Alan Coopersmith is paid by Oracle to work on Solaris.

what do you mean computing life exists outside of containers that exist in a magical void

thank you :)

this is an odd conclusion to make from my article, given that the entire point of it is to assert the difficulty in establishing trust and the lack of wisdom in relying on a single source