[talk] [Link] and [Spiel] How we put together BSD systems

Raul Cuza raulcuza at gmail.com
Wed Mar 2 01:45:13 EST 2016

I ran across this blog posting from Lennart Poettering, one of the
developers of systemd:


At some point I imagined a similar article being written for BSD with
statements like the following:

Traditional BSD systems are built around packaging systems like [ports
or pkg(?)], and an organization model where upstream developers and
downstream packagers are relatively clearly separated: an upstream
developer writes code, and puts it somewhere online, in a tarball. A
[port maintainer or] packager than grabs it and turns it into pkgs.
The user then grabs these [ports or pkgs] and installs them locally on
the system.

The exercise sucked all the air out of the room. The statement lacks
veracity. This just isn't the way I think about BSD.

So does that mean the rest of what the article talks about is
irrelevant to *BSD? Every OS I've used has at one point or another
frustrated me with coordinating versions of libraries with app

I think the solution Poettering offers is off mark, because the
problem of keeping libraries and binaries versioning in sync is easier
to do when approaching the whole system as a single system instead of
PACKAGES + OS. This is not to mention the nightmare it would be to
manage all the different OS, home, and library resources.

Don't get me wrong, building on a core OS with ports and packages is
an essential part of building a BSD box. It is just that the final
result is a unified whole instead of many layers of code piled upon
each other.

I've only managed FreeBSD and OpenBSD systems for myself and for
specific organizational services. If I had a few hundred jails, would
there be a part of the system that approaches the complexity of the
btrfs volume Poettering lists midway through his post? Anyone know how
to get a a behind the scene tour of https://www.nearlyfreespeech.net/
so I can find out?


More information about the talk mailing list