FreeBSD from a NetBSD developer’s perspective | Hacker News Reader

FreeBSD from a NetBSD developer’s perspective

washbear.neocities.org

175 pointsjayp141875 comments

> FreeBSD Ports sometimes shows me a text menu for configuring package options, while pkgsrc just uses text configuration and tries to make it so you don’t need to reconfigure packages. I’m the kind of person who prefers text configuration, but I can see how others wouldn’t.

Posting because it took me way too long to run into this on my own: make config-recursive lets you get all the ncurses per-port menus out of the way at once. Not a full fix, but it does take a rough edge off of the default port config/building experience.

e: Real lovers of text config could also use Poudriere to build their own packages since it takes per-port config options files. I think you can do something similar with portmaster as well.

ee: now I think about it, the choices from the ncurses menus just get stored in /var/db/ports, so you could probably edit it directly as text if you felt like it.

See ports(7) which mentions "config-recursive" and other targets that may be useful:

* https://www.freebsd.org/cgi/man.cgi?ports(7)

You can also set port options in /etc/make.conf. I find this easier than the /var/db/ports solution because you can see all the configuration in a single file, rather than file-per-port.

using portmaster does the same thing, runs all the configs up front.

portmaster is a big quality-of-life improvement, that's almost always one of the first things that I build on a clean install

FreeBSD started with options and you could edit /etc/make.conf

You could also make them available for specific packages, for example:

    .if ${.CURDIR:N*/ports/www/apache2*} == ""
    SUEXEC_DOCROOT=/usr/local/www
    SUEXEC_USERDIR=public_html
    .endif

Then they implemented the ncurses approach which made it more user friendly. You can still change some defaults for example I have this:

    OPTIONS_UNSET+=X11
    OPTIONS_UNSET+=DOCS
    OPTIONS_UNSET+=EXAMPLES
    OPTIONS_UNSET+=CUPS
    OPTIONS_UNSET+=OPENGL

Here's more how to use them: https://github.com/freebsd/freebsd-ports/blob/main/Mk/bsd.op...

The options are also stored in the config as you mentioned and if a new option is added the old one's state is preserved. Overall this reminds me early days with smartphones and iPhone users making excuses why not having copy&paste was better.

> On the other hand, QEMU is this huge piece of software with documentation scattered all over the web and no man pages.

My frequent resource: https://manpages.debian.org/jessie/qemu-system-x86/qemu-syst...

Not available for BSDs? Maybe that's a mishap by the distro?

I've got several man pages for qemu (FreeBSD 13.0, qemu-5.0.1)

   $ apropos qemu
   qemu(1) - QEMU User Documentation
   qemu-img(1) - QEMU disk image utility
   vdeq, vdekvm, vdeqemu(1) - Virtual Distributed Ethernet wrapper for QEMU/KVM virtual machines
   qemu-block-drivers(7) - QEMU block drivers reference
   qemu-cpu-models(7) - QEMU CPU Models
   qemu-ga-ref(7) - QEMU Guest Agent Protocol Reference
   qemu-qmp-ref(7) - QEMU QMP Reference Manual
   qemu-ga(8) - QEMU Guest Agent
   qemu-nbd(8) - QEMU Disk Network Block Device Server

OTOH, there's no manpage for qemu-system-X, so maybe that's the confusion.

Also, >the pw man page is much scarier than NetBSD’s useradd.

FreeBSD has an adduser(8), which is a bit more friendly than pw.

>which is a bit more friendly than pw.

pw is one of those that i wish had a --dryrun type option enabled by default and required a --doit switch. this was brought up a few days ago, and i really like the idea of scary commands using the dry run as a default.

I think what they mean is that the manpage you link is just synopsis of command line options and not anything that help understand what happens with QEMU and how to fix it when something goes wrong.

I wonder how close NetBSD’s design is to 4.4BSD, the last version of BSD from UC Berkeley’s CSRG? My understanding is that FreeBSD has a lot of features that are exclusive to it, such as jails and Capsicum, and FreeBSD also has some Solaris-derived components such as ZFS and Dtrace. I’m under the impression that NetBSD’s specialty is in providing a BSD that is easily portable to a wide range of architectures. Because BSD is not just a kernel, but an entire operating system, NetBSD’s portability makes it attractive when choosing a Unix for “exotic“ hardware.

> Because BSD is not just a kernel, but an entire operating system

To my chagrin, I’ve never understood this. (A Linux distribution is not just a kernel, either.)

It just means that the BSDs have both their kernel and their full userland maintained by the same team whereas Linux to a certain extent splits responsibilities between the kernel devs and a bunch of other projects.

the bsd kernel is made by the same team as the rest of the system, and follows the same release schedule. Thus they can add a new syscall (e.g., pledge in openbd), and update all the programs at once to use it. That wouldn't really be possible in a linux distribution.

Great write up. I would have wanted to say much the same, when I cut from NetBSD to FreeBSD back when the IBM X30 laptop was my daily drive.

I ran pkg on OSX for a while, and would still do if homebrew hadn't solved other problems for me. the /opt vs /usr/local thing is quite interesting, on systems which think "they" own /usr/local

Doing things in kernel vs doing things in userspace is a subject worthy of more discussion. We now have TCP in userspace models, browsers which have internalised a huge amount of the network dependency stack and QUIC, which I do not believe is kernel supported normally.

TIL you could run pkg on OSX, when did that stop working, Tiger / Leopard?

I last tried around Leopard, but I am unsure it stopped working. https://pkgsrc.joyent.com/install-on-osx/ suggests it hasn't.

> On the other hand, QEMU is this huge piece of software with documentation scattered all over the web and no man pages.

On every Linux distro I can recall it has manpages, and glancing at the AUTHOR section on Ubuntu implies that it's upstream and not a local distro-added thing. Anyone know what's going on there?

Answer per https://news.ycombinator.com/item?id=27416077 upthread: yes, FreeBSD has qemu manpages, might just be that the OP couldn't find them under the expected name.

> I use Multicast DNS on my home network - mostly this is just for convenience, and so I don’t have to remember lots of different IP addresses.

> NetBSD includes multicast DNS support by default through a port of macOS’s mDNSResponder called mdnsd. It seems it’s available for FreeBSD but not a core part of the OS. I’m also under the impression that it’s more common to use Avahi (the Linux community’s answer to mDNSResponder) on FreeBSD, but I don’t know for certain.

I use Avahi on a vnet Jail. I basically put every host on /usr/local/etc/avahi/hosts and this is enough for name resolution even if the system or device has no mDNS broadcasting capabilities.

I never understood why you would use BSD instead of Linux. It it just a preference, or is there really a benefit?

Preventing software monoculture, for one. The same argument could have been made about using Linux instead of Windows not that long ago.

The terrible 1995-2000, where Dec and Solaris boxes where thrown away and shiny windows servers run everywhere, not one day without a hard reset.

To be fair, when faced with a need to make a practical decision on whether to use a Linux or a BSD preventing software monoculture is the last thing on my mind. (In fact, my decision would often be influenced by wanting to keep the infrastructure as uniform as possible.)

Yes it's a massive benefit (for me), but i don't tell you which one, because would you believe me that linux is better for server and development then windows without testing it out for yourself?

BSDs actually descends from UNIX and had it not been for the AT&T litigation, most likely Linux kernel wouldn't have had the uptake it had.

Additionally we don't need UNIX monoculture.

I don't entirely agree. The SYSV vs BSD thing was constant before either (Free,Net,Open)BSD and Linux came into a rivalry. I was there, using both across the timescale (I'd been doing sysadmin and development work on V7, Unix 32V, BSD4.1->4.2 (thats sockets) and then Ultrix/Solaris &c)

SYSV had streams/STREAMS when BSD had sockets. Arguably streams is a superior model.

NFS came to the fore in BSD. SYSV had RFS. It was a different model of network filestore.

MGR -> v8 ->Plan9 was there too. There has always been room for more than one viewpoint of what a UNIX conforming system is.

The rise of Linux has a lot to do with licence terms (for some reason the BSD 4 clause hold harmless appealed more to the embedded market) and the natural tendency of some driver vendors to write for Linux. Google deciding to deploy linux at scale inside the borg, and as Android was recognition of reality.

Van Jacobsen, who did a lot of work on TCP tuning and congestion control in the BSD kernel, wound up in Google, and stopped developing for BSD. So, BBR (for instance) came to BSD late and only because Netflix sponsored it. A bunch of the GPU driving space, WiFi card blobs, they're in Linux kernel before BSD. Docker hasn't been ported to BSD notwithstanding the possibly superior models in Jails and Bhyve, the supremacy of Dockerfile has to be understood as "mindshare"

TL;DR BSD lost a lot of "mindshare" but there was always room for a BSD-vs-SYSV-vs-Plan9 thinking, from before-times.

I was also there, and unless we are talking about embedded space, we are approaching a UNIX === Linux monoculture, versus how it used to be.

As you very well point out, BSD lost a lot of mind share, and if it wasn't for macOS, it would probably matter even less.

Hence why it matters to keep diversity alive.

Why do you use Linux instead of BSD? It's the same question.

Some potential reasons for using FreeBSD:

It's the same three firewalls forever, not a progression of different firewalls.

Old knowledge still works, for example, netstat is still the way to list socket connections and ifconfig is still the way to configure interfaces. I did some work with FreeBSD in 1999, and then nothing until 2004, and all the knowledge transferred, then in 2011 I changed jobs and skipped ahead several versions, and again all the knowledge transferred. But I kind of stopped using Linux heavily in 2013, and when I had to work on it at work in 2016, all the tools had changed, so I had to relearn (or just avoid the Linux part of my job, which I had the luxury of doing).

Official kernel support for ZFS.

Receive side scaling support is nice, if you need it; although I guess not a lot of people do.

Different positions on philisophical arguments like an integrated source repository with the kernel and the base userland software, or init systems.

The "old knowledge" thing is a huge one - I know there are reasons why Linux keeps changing which firewall manager you're supposed to use and now we do ip addr show instead of ifconfig eth0 but it is annoying to keep up.

I know Linus has a "don't break userland" theory which causes some of the above, but it breaks MY userland memory when I have to learn new tools.

Of course if you stay with Ubuntu you'll find fifty thousand posts on whatever question you have.

> I know Linus has a "don't break userland" theory which causes some of the above

And the worst part, Linux actually breaks userland _way_ more often than any of the *BSDs...

"Moving what should have been dev nodes to sysfs since 2010 (TM), then reorganizing sysfs every couple years..."

This is where the *BSD trees including the kernel and the distribution also helps - they can keep the “user interface” the same while still updating everything.

Linux seems to have to create a new way of doing something because there’s no guarantee they can get the distributions to update the tooling.

> which firewall manager you're supposed to use

Just use iptables directly and iptables-save/restore. In FreeBSD pf.conf is way nicer and easier but this trick works for me in Linux.

>Just use iptables directly and iptables-save/restore.

Not nftables?

Yeah, I'm talking about ipchains -> iptables -> ntfables, not necessarily the various firewall management toolchains on top of those (shore wall, ufw, etc).

I have no idea what it uses as a kernel interface nowadays. Did they change the userspace tool again? This is another reason why I like FreeBSD. The tools and syntax barely changed between ipf and pf and the latter was an improvement. I even use as a gateway instead of an EdgeRouter which I find a nuisance to set firewall rules onto.

Because Linux is the dominant OS on servers (so my dev environment can match the prod environment,) has way more tutorials,and documentation and also has way better hardware support.

> has way more tutorials,and documentation

I'll agree on the rest, but more docs != better docs; BSDs tend to ship complete manpages without needing to wade through a hundred blogposts (half of which are out of date or slightly wrong).

I’m not really talking about Man pages. Yeah this is the argument the BSD fans like to use but those dozens of blog posts for every Linux question makes it a much nicer experience for new users to get what they want working quickly.

It's not just man pages. I can't speak for OpenBSD and NetBSD since I'm unfamiliar with those systems, but for FreeBSD there is the excellent FreeBSD Handbook (https://docs.freebsd.org/en/books/handbook/), which is great for learning how to set up and administer a FreeBSD system.

If your a new users you should start understanding your system, and don't follow potentially wrong or old tutorials, that's a big problem with the Linux-Information-overflow.

Thae's a nice ideal, but if you need to get something working, nothing beats searching for the error message.

The original package maintainers could write instructional materials that start from the errors, but I suspect that's too hard. Without specific training, it'll always be easier for third parties to provide ad hoc than first parties to produce as part of release.

The way I see it, there’s a bigger difference between some Linux distributions than between, say, Slackware Linux and a BSD, so one could also ask why someone would use Arch instead of Ubuntu (or the other way around).

I use FreeBSD on my servers and for research for the following reasons:

1. The documentation is excellent. The man pages are well-written and have useful examples, and the FreeBSD Handbook and Developer Guide are great resources.

2. First-class support for features such as ZFS and Dtrace.

3. This is a preference, but I like the BSDs' conservatism when it comes to adding new features. It seems that new features in the BSDs seem to be more in line with the Unix philosophy (similar to the Solaris and Joyent communities' attitudes), while the Linux community seems to be more willing to add features that may solve problems, but not necessarily in the way that some diehard Unix users would (e.g., PulseAudio, systemd).

With that being said, I use Linux for work and in the WSL environment on my Microsoft Surface tablet. Linux is also a great operating system, and sometimes I need to use Linux instead of FreeBSD for hardware and software support reasons (for example, I use CUDA for my job, which needs Linux).

FreeBSD has superior:

- package management (pkg & ports)

- file system (native ZFS)

- instrumentation (systat & dtrace)

- documentation (handbook & examples in most man pages)

- event notification interface (kqueue vs broken by design epoll & inotify)

- license (BSD, no GPLv3 at all)

- stability (POLA)

- quality control (no shellshock, no dataloss on fsync)

- network performance (200gbps TLS encrypted traffic on a single socket at Netflix, millions of open connections per server at WhatsApp)

- scaling (there is no cliff when resources get saturated just a bit of a "back pressure")

It adds up to the point where I see some companies keep their use of FreeBSD secret as a competitive advantage.

On the other hand I really like what Alpine Linux is doing.

Agree with all except the package management part. I switched to Debian after 15 years using FreeBSD simply due to how much better apt is. I don't have much time so unattended-upgrades is a live saver for me. I do miss FreeBSD though, it is really well designed and thought out but it is more suited to people who are happy to maintain the packages regularly especially when there are major upgrades. A recent example is the change in the default version for Python which needed some manual intervention to sort out the packages. Somethjng that honestly apt does much better.

Whatever happened to debian built around FreeBSD? (debian kFreeBSD?). Did systemd kill it?

I tried it circa 2012 (on a macbook, which was clearly a bad choice, but work told me I would love a mac and I didn't so might as well try other bad things). It was kind of a mess, I recall having trouble with basic networking utilities because they tried to provide GNU tools, but they didn't really work and you'd need to get the FreeBSD tools anyway, which was tricky because those weren't packaged.

I agree, apt is a path well traveled and python2 -> python3 migration had some opportunities for improvement. On the other hand I can custom build nginx with a TUI and have package registered as an actual package instead of just being dumped into /usr/bin & /etc/ like with a manual build on Linux. That feature alone makes me believe FreeBSD packages are a tiny bit better as I use it all the time.

You can build Debian packages from source with custom options to get a resulting .deb to install. I will fully admit the process tends to be a bit easier when dealing with BSD ports though.

As a FreeBSD user, the pkg/ports system is the biggest frustration I have. I run -current and update every few weeks (using zfs boot envs and beinstall and pkg upgrade). Every few months, there is some breaking change. Something suddenly wants to uninstall KDE, or cannot find a path forward, etc. I ran ubuntu for years and updated as- or more-frequently and never encountered these problems. Even updating from LTS to LTS was smoother.

I think part of the difference is that ubuntu is a fixed release, while FreeBSD is a rolling release. I wish there was a fixed release of FreeBSD. The best I've been able to do is using -stable quarterly pkgs on FreeBSD-current. This way, I only get security updates except for 4 times a year..

> I run -current and update every few weeks (using zfs boot envs and beinstall and pkg upgrade). Every few months, there is some breaking change.

Well yeah, you're tracking unstable; you can't compare -current to an LTS.

Quarterly is not LTS too, it's just 'slower'...but yeah one should compare 'latest' to Arch and not to LTS that's for sure.

Absolutely agreeing with you, i was thinking about that too. Maybe something like OpenQA and much much more testing can solve it. It's really a bit of a pain, the System is stable like a rock, but that brings nothing if the ports/pkg ecosystem gets neglected (by the whole project not the porters....please don't get me wrong)

I have lost access to my old account, but this comment has so much FUD (and seems to describe the state of Linux as it was about ten years ago) that I had to make a new one to respond.

>- package management (pkg & ports)

It's a matter of taste, I much prefer the power of dnf (the rewritten and modernized yum with full backwards compatibility) with its support for transactions (and transaction rollback, like reverting the state of packages as they were at a particular point in time) and many similar features.

>- file system (native ZFS)

Ubuntu has ZFS built in. You just have to install userland tools (run a single command to add a half-megabyte package and wait a few seconds).

>- instrumentation (systat & dtrace)

dtrace was ported to Linux long ago. We also have bpftrace: https://lwn.net/Articles/793749/

- documentation (handbook & examples in most man pages)

Back in the day it was way easier for me (as a *nix newbie) to find the answer to any of my questions for my Linux systems. I am not a native English speaker and I couldn't read English documentation at all. The various Linux docs, blog posts and community support absolutely dwarfed anything that was available for FreeBSD.

- event notification interface (kqueue vs broken by design epoll & inotify)

No mention of io_uring? https://lwn.net/Articles/776703/

- license (BSD, no GPLv3 at all)

Similarly, it's a matter of taste. The GPL family is a clear win for me.

- quality control (no shellshock, no dataloss on fsync)

The recent WireGuard fiasco proved that one wrong. Most code that's going into your system gets /absolutely/ no review besides its original developer. IIRC I heard that from Allan Jude (I think you should know of him) in one of the recent episodes of 2.5admins.com. He was obviously very uncomfortable describing the QA situation throughout the entire discussion.

WireGuard did not make it into a release now did it? Code was indeed crap and they pulled it at the last minute. Lots of users were disappointed including me but then a better version was released as a package and I'm a happy camper.

>FreeBSD has superior:

>- package management (pkg & ports)

Debatable

>- file system (native ZFS)

Debatable... ZFS is good for many use cases and is a hot broken mess for many others

>- instrumentation (systat & dtrace)

Debatable

>- documentation (handbook & examples in most man pages)

Debatable... I have not fund this to be true in 15 years at least.

>- event notification interface (kqueue vs broken by design epoll & inotify)

Debatable

>- license (BSD, no GPLv3 at all)

Debatable

The GPL is why Linux is miles ahead of *BSD in mindshare.

>- stability (POLA)

Debatable... Maybe 20 years ago FreeBSD was more stable but I had more stability problems with FreeBSD in the last 15 years than any Linux distro I ever used.

>- quality control (no shellshock, no dataloss on fsync)

Again debatable.

>- network performance (200gbps TLS encrypted traffic on a single socket at Netflix, millions of open connections per server at WhatsApp)

LOL debatable again! Youtube, Facebook, Amazon Video, Hulu, most stock trading exchanges. FreeBSD used to be the goto for web servers and services now its nearly dead in that space with market share in the single digits.

>- scaling (there is no cliff when resources get saturated just a bit of a "back pressure")

Benchmarks have shown Linux outperfroming any of the BSD's in scaling since 2003 at least. And the Super Computer and server market proves FreeBSD can't scale.

>Benchmarks have shown Linux outperfroming any of the BSD's in scaling since 2003 at least. And the Super Computer and server market proves FreeBSD can't scale.

Really?

https://www.phoronix.com/scan.php?page=article&item=corei9-f...

> DragonFlyBSD 6.0 manages to edge past Ubuntu 21.04 as the fastest of the operating systems tested on this Intel Core i9 workstation

> - scaling (there is no cliff when resources get saturated just a bit of a "back pressure")

If you haven't found the cliffs, you're just not scaling hard enough. Of course, they are hard to find them in 'normal' server patterns, but if you do unconvential things, the cliffs may be closer. I retired, but my last project hit a bottleneck with FreeBSD 12.0 on outgoing tcp connection rate that's much lower than any kernel bottleneck on incomming connection. I don't know the kernel bottleneck on incomming connections because I never hit it; maybe I've hit configured FD limits, but other than that, I've only been application limited other than ocassionally running into a bug that reduces capacity.

Are you familiar with "vmstat -z"? It will show you any kernel limit that was hit under the "FAIL" column. When you know what is happening/failing its much easier to tune and scale. dtrace is also invaluable for this.

No I wasn't, that's quite nice, thanks. At work, we had tools to look at selected vm stats, but a fuller pictures is nice, and I don't have access to the tools I did anyway.

The fail column of course only applies to explicit limits; not things like doing task X requires lock Y, so if you're doing X a lot on a 56-thread machine, you can only do it so much before lock contention grinds you to a halt. (OTOH, top usually shows what lock you're waiting on, so it's pretty easy to track from there, and I know there are better lock debugging tools, I've just never needed them because either the lock is blindingly obvious and I can work on it, or it's kind of subtle and the other fixer knows how to use the tools for subtle problems :)

I speak for myself. OpenBSD and FreeBSD are a joy to use. Haven't checked on NetBSD but that's what I would use if I had a m68k system lying around.

Or check it out for free at https://sdf.org

Thats very cool but I want the m68k experience.

While at it are there similar services for public testing? I briefly remember some years ago IBM allowing shell access to one of their then new POWER systems.

>IBM allowing shell access to one of their then new POWER systems.

Can remember that too, was sponsored by IBM at some university, but it's closed long ago, was actually really cool.

Oh... here I am again. Found this:

https://openpower.ic.unicamp.br/minicloud/

This Brazilian university provides free access to a Power system for developers who want to port their applications.

It looks like you can actually run your own virtual machines in a cloud-like environment: https://youtu.be/TE_4UKHrjwE

I got into BSD around the late 1990s. At the time, Linux distros like the famous Red Hat 5 series, SUSE and Caldera were touting the ease of install with graphical GUIs and X windows environments. I tried them all but found that I wasn't learning how to actually use the terminal commands or understand the startup scripts or filesystem very well. I then tried the BSDs and finally felt like I was beginning to understand how everything fit together and appreciated the whole system architecture better.

Man pages were detailed and precise. Ports and packages were a breeze to install. For me, it made all the difference. I settled on OpenBSD for the security emphasis and my first project was to install a proper firewall for my office. It was a joy to setup. Config files were simple and clear. The firewall itself was incredibly powerful (since superseded by the even better PF https://www.openbsd.org/faq/pf/).

I haven't looked back ever since. Whenever I have to work in a Linux environment, I shudder at the number of processes running, the confusing filesystem decisions of each distro, the poor Man pages and the behemoth that is systemd. I really wish BSDs got more attention and support from developers and users. They really are fantastic operating systems, each with their own particular specialisations (NetBSD - portability, OpenBSD - security, FreeBSD - general purpose, DragonflyBSD - clustering, SMP).

Also, obligatory User Friendly strip link: http://www.userfriendly.org/cartoons/archives/99mar/19990320...

I like the BSDs because I have a hope of understanding them. They're simple and well-documented, and make design choices I like. (For example, on a BSD I can use 'man -Otag=l ls' to go straight to the documentation for 'ls -l'. Try doing that reliably on Linux.)

I played around with freeBSD for a couple of days recently. I quite liked it until it came time to updating the system (I delibearely installed 12 to test this). Missing .so libraries everywhere. I suppose if I was more of a unix pro I would have figured out the problem, but trivial updates are a big deal for me.

Did you update from 12.x to 13.0? FreeBSD maintains ABI compatibility across minor versions, and major version updates are usually like `freebsd-update -r '<major>.<minor>-RELEASE' upgrade`, `freebsd-update install`, reboot, `pkg upgrade`, reboot, `freebsd-update install`.

That second `freebsd-update install` removes the shared libraries from the old version and will result in old binaries breaking like you described. The `pkg upgrade` step implies an ABI change as well, replacing your installed packages with the same packages built for the new major version.

It's even possible to keep old binaries working by installing the appropriate `compat` package, e.g. compat12x if you have FreeBSD 12 binaries you want to run on FreeBSD 13: https://www.freshports.org/misc/compat12x/

Yes.

12.0 -> 12.2 was smooth (my cloud provider had 12.0 from a dropdown menu).

I see from your post I was supposed to reboot twice to upgrade major versions. I'm sure it was in one of the docs I was reading and I lazily skim passed it. So it's on me.

Don't feel bad. I've used FreeBSD for a long time but still find it kinda confusing when the "same" command has different effects depending on system state. Heck even I got it wrong since I forgot it's actually three steps — install the new kernel and reboot into it, install the new userland and reboot into that, reinstall packages, and then remove the old userland: https://www.freebsd.org/releases/13.0R/installation/#upgrade

On the plus side it's super-easy to recover since even if your `pkg` is broken there's a `pkg-static`: https://www.freebsd.org/cgi/man.cgi?query=pkg-static&sektion...

A `pkg-static bootstrap -f && pkg upgrade -f` would probably sort that system out if you ever end up in that state again :)

Did you upgrade via source or binary upgrade? IME binary upgrades have been incredibly smooth.

https://docs.freebsd.org/en/books/handbook/cutting-edge/

jmmv and jmcneill (probably more) work on both NetBSD and FreeBSD

Users perspective? This specific user is a developer; I'd say this subject is quite misleading.

Ok, we've promoted the user in the title above.

Reply on news.ycombinator.com