> I've seen attempts at bringing the Linux ABI to FreeBsd, including the familiar and popular apt package manager.

That's ridiculous. `pkg` on FreeBSD is a thousand times more consistent and user friendly. Perhaps you are talking about the days before pkg-ng (next generation) became the default, but now installing anything is as easy as `pkg install foo` and it just works. It even updates automatically so URLs aren't out of date.

I have a deep respect for BSD family, and their way of doing things, but regardless of OS and distro, apt is probably the most advanced package manager currently.

When used with aptitude, it's very easy to use, extremely powerful and flexible. Also, it has the most extensive knowledge on details of packages in terms of dependency graphs and modification of files which belongs to packages.

At least, that's what I saw in 14 years.

While this is certainly true, have you used pkg in the last year or so? It's come on leaps and bounds. The solver is now on a par with apt's SAT-solver, and overall it's (IMO) almost as good as apt at this point.

No, honestly I didn't. I've installed OpenBSD to a VM in the beginning of the year to learn it, but I had no time to either play or learn using it.

Looks like I need to resume learning it. Thanks.

OpenBSD isn’t using the pkg we are talking about, fwiw. You’ll need to install FreeBSD for that.

Thanks, will try FreeBSD first, then.

OpenBSD's package manager is actually really easy to learn and use. Even I can do it.

I will try both, promise. :) I also find OpenBSD's ideology more resonating to me.

OpenBSD's package manager comes unconfigured out of the box, though :(

Can you elaborate on this? I'm not sure which version added it but /etc/installurl is configured to use cdn.openbsd.org during install. Prior to this, I believe /etc/installurl was populated with the mirror you chose during install. That had been around for at least a couple/few versions, IIRC.

Is there something else you are referring to? https://man.openbsd.org/installurl

I'd certainly not discourage having a play around with it!

I started trying it out with FreeBSD 10.0 a few years back. pkg was rough around the edges back then. If you had a lot of packages installed, like lots of development tools and desktop environments, it wasn't hard to get it into a situation where it would segfault or run into dependency problems during an upgrade. Right now, with 11.2, I've not run into any crashes for a good 2-3 years or any intractable dependency problems in a good 2 years or more. It's probably not perfect, these are very complex tools which are hard to verify, but it's certainly eminently usable from the point of view of an admin/end user/casual ports contributor like myself.

In fact, when upgrading from Ubuntu 18.04 to 18.10 a few weeks back, I did actually run into a problem with apt refusing to upgrade because it couldn't work out the upgrade path. I had to remove a few packages which were causing problems, then re-install them after the upgrade. Whether that was apt or the packages having genuinely broken dependencies I'm not sure since I didn't investigate in detail.

> , apt is probably the most advanced package manager currently.

Apt is certainly the best package manager in my opinion. I haven't used rpm based package managers in a while, but I doubt they don't have feature parity at this point.

I think the magic ingredient of apt that makes it work so seamless is the thousands of diligent maintainers behind it. That's the "feature" that none of the other packaging systems have at the moment.

I also have a deep respect for the raw no-nonsense approach of the various BSDs, but every time I try running it in a professional capacity, the apt eco-system lures me back.

I use both apt, pkg-ng and yast/zypper/rpm. Both apt and pkg-ng work well. Apt has --really-long-switches that are easy to remember but not quite as many shortcuts for them. Sometimes pkg-ng is annoyingly upgrading itself but that's it. Rpm is rather annoying but zypper and yast make things easy to manage. I remember the old RedHat 4.2 days when I had to work with rpm exclusively; it has an inconsistent CLI with weird command line switches.

You shouldn't compare rpm with apt. rpm is a different layer equivalent to dpkg in the Debian world.

As you point out, apt layer/functionality is provided by zypper, yum, dnf, etc. and the main difference is that it is not unified across the main rpm distributions. Still, Fedora/Redhat yum replacement, dnf, is built on SUSE/openSUSE zypper's solver library (libsolv).

I know. Dpkg is more consistent anyway.

Have you seen the current size of the ports tree? It's on the scale of a distribution the size of Debian.

While there is certainly some Linux-specific software which doesn't work on FreeBSD (and vice versa to a smaller extent), this is a tiny fraction of the total amount of portable free software packaged for both.

It's not easy to accidentally make software that compiles on Linux and fails on BSD.

There are degrees of difficulty. If you're developing on Linux there are numerous portability traps you might fall into if you're not paying attention and testing on other platforms like MacOS or BSD. From glibc-specific functions and structure members, to libraries which are Linux-only. You also have compiler differences, e.g. GCC vs LLVM.

None of these are usually much work to correct. But they can creep in without you realising if your CI isn't testing on multiple platforms.

The most annoying I had recently was a service using PAM for authentication/authorisation. Linux-PAM is both Linux-specific and subtly incompatible with Solaris PAM (the original implementation) and OpenPAM on FreeBSD. This means you have to have three sets of ifdefs for the different implementations, which is annoying. But if you developed for Linux and never tried building or testing on the other platforms, you would never appreciate the problem even existed!

It's a bit like shell scripts that call for sh, but have bashisms in them.

Thanks for the comments. It's easy to forget the norm is not testing on multiple compilers and OSs. BTW, I haven't been testing my stuff on ARM and I probably should. Not that I expect anything to break, but I don't want the stuff I don't expect to break surprising me.

what about debian/kfreebsd (never used it, just wondering)

I don't think that's being released anymore.