Hacker News Reader

While I mostly agree, you also hit the power of the freebsd system: you can do something different. In linux if you want PostgreSQL 12+PostGIS 3.0 with xml support and the packages deliver PostgreSQL 12+PostGIS 3.0 without xml you are stuck without xml support as the package systems don't make it easy for lay people to select options. With FreeBSD you get that power if you want it.

It should be easier though.

I don't update Linux, FreeBSD, or any other OS in place except on my FreeBSD-CURRENT desktop. The only way to operate in production is to create a new VM from your template, apply the runbook/state/whatever, route everything to the new VM, and drain the old VM.

My personal systems aren't where they should be for CM, but I still can't think of a good reason to update in place rather than rebuild and copy over configuration/data.

Flavors should make it easier to operate with packages instead of ports, but I don't have any idea what's going on there. If I were supporting a large number of systems, I'd want FreeBSD over Linux any day of the week and twice on Sundays because the ports system doesn't make you choose between a stable OS branch and current software.

I actually think there is nothing wrong with the upgrade process. What about pkg-style makes it better? On those other systems you still need a reboot for kernel changes to take effect.

It's more the number of reboots and invocations of freebsd-update. Since these are all manual steps, you need to keep track of where you are and invoke the next step manually.

The current process for upgrading FreeBSD is roughly, assuming that you're just using packages and not ports is:

* freebsd-update upgrade

* freebsd-update install

* reboot

* freebsd-update install

* pkg upgrade

* reboot

* freebsd-update install

* (optional) reboot

In comparison, the process for upgrading OpenSuse Tumbleweed, assuming that you're just using packaged software, is:

* zypper dup

* reboot

If the base system were managed by pkg, the FreeBSD version of the process should probably look a lot like the OpenSuse Tumbleweed version. Condensing upgrades down to a two-step process seems like it will be a significant quality-of-life improvement to me.

I think there's value to having base separate from pkg, too. The way we ran FreeBSD at the two companies I worked where it was used heavily was to manage base and other things separately.

For base updates, we'd usually shut down services, install kernel and userland, and reboot --- I know this isn't the proper order, but most of the time the new userland is compatible enough to reboot (and you can usually power cycle if that doesn't work out). For updates where rebooting would be hard this way, we'd do it the right way, but then you need to add an extra reboot after installing userland, or restart all the services from base. If needed, we'd install the compat packages after the reboot. We would not update ports/pkg/etc at the same time; old binaries are expected to continue to work on a new system (and generally do). In house binaries are either compiled on the system they run, or centrally on a machine (or chroot/jail) running the oldest release on the fleet.

Generally,

When you need to upgrade software not from base, because of security updates or new features or ennui, you do that isolated from base changes. The only complication here is if you haven't updated base recently enough, pkg may provide binaries you can't run, and ports may provide software you can't compile (this one takes longer).

We would generally only update base for exceptional releases, or when it became hard to update non-base software on older releases. However, new machine installs would get the most recent release we had tested.

But if there are ABI breakages in base (say, a new syscall used in libc) you want to boot the new kernel with the old userland, then get the new userland later.

At least, I have heard this explanation in the context of OpenBSD, and assume it may also apply to FreeBSD.

I believe that's the same in FreeBSD as well. I also think it's a solved problem in the Linux world - OpenSuse Tumbleweed sometimes rebuilds every package because they've changed libc. Apart from watching 2000+ packages get updated, there's really no impact when this happens.

To solve this, the updater could create a new boot environment[0], install everything in that boot environment using as many passes as required, then reboot into that environment. OpenSuse already does a similar thing[1], though I don't know how well it works.

[0] https://www.freebsd.org/cgi/man.cgi?beadm

[1] https://news.opensuse.org/2018/05/15/transactional-updates-i...

The situation on linux is actually different because the kernel and glibc are maintained separately and the syscall ABI is treated as a boundary between components.

Any time a new syscall is wrapped the userland maintainers need to account for what happens when run on an old kernel and typically have some fallback logic.

Sounds like a great yak-shaving opportunity, to write a script that automates it

Which everyone does, if one has more then 2 machines ;)

I absolutely agree. I run FreeBSD on my NAS to take advantage of ZFS but every time I update it I have to Google the process or find my notes since it's incredibly non-intuitive.

I have a detailed set of instructions to follow when I'm upgrading my home server, plus notes from each time I've upgraded it.

At this point, I've only got two services (postgresql and mosquitto) which run on bare metal, everything else is in VMs. Once I move those off of FreeBSD the upgrade process will be greatly simplified (well, as simplified as FreeBSD gets anyway).

freebsd-update prints out what you need to do next at each step though. If it wants you to reboot and run it again it says that.

Or you just read the printout until it says fetch first ;)

Why do you not use poudriere? And build automatically everything from ports then install the build-ed packages on you machine's?

This is something I've been meaning to look into, but it still doesn't change the postgis30/postgresql11-server dependency in the current ports tree.

I'm sure I could work around it, but then I start to ask myself whether I'd rather do FreeBSD software administration or create an OpenSuse VM, install the packaged software (which is already the right version and already has the right config options), and work on my GIS project.

>but it still doesn't change the postgis30/postgresql11-server dependency in the current ports tree

If you tell make.conf that postgres12 is the default it will compile postgis for that version, same with php/ruby/mysql and so on.

I feel poudriere takes too much time and disk space building literally everything. I would like it to pick up dependencies from pkg and only build stuff from source when I have options changed.

Incidentally I wrote a shell script that does this.

>I feel poudriere takes too much time and disk space building literally everything.

No not really just your packages and the dependencies of those.

Ok, slight exaggeration. The dependencies get quite huge though, especially when you are using something substantial.

Yeah that's true, having 1400 pkg installed needs often ~300 pkg to rebuild...but hey then you know everything is in harmony ;)

Building both gcc and llvm from scratch (which somehow usually ends up happening) is probably more harmony than I need in my life.

Both are faster build then chrome or Firefox ;)

I usually upgrade by recompiling the OS. Minor updates only take a few minutes to compile using filemon and the WITH_META_MODE=YES environment variable. The advantage is that it's easy to maintain out-of-tree patches to the source.