The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 12.0-RELEASE. This is the first release of the stable/12 branch.
The full release notes have all the details.
The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 12.0-RELEASE. This is the first release of the stable/12 branch.
The full release notes have all the details.
Cool to see more features for jails, especially bhyve inside a jail!
For a while now one of the big features planned for FreeBSD 12.0 was managing the base system’s updates with pkg. That was apparently dropped at some point as FreeBSD 12.0 still uses freebsd-update for the base system and pkg for third-party packages.
This has led to an interesting development where some FreeBSD-related projects, such as TrueOS and GhostBSD, are using pkg to manage the updates to the base OS while FreeBSD is still using freebsd-update.
TrueOS is a trailblazer for newest technologies while FreeBSD is more for stability.
Yes, pretty much, that is why TrueOS is based on FreeBSD -current. I just find it interesting that, as a result, TrueOS has been using technology many of us thought we were getting in FreeBSD 12.0, but didn’t. This means TrueOS’s “FreeBSD 12.0-current” branch diverged from FreeBSD’s 12.0-current branch somewhat, surprising some of us.
It’s hard to make a reliable and consistent binary update system for an operating system to begin with. It can get sketchy with merges when everyone changes their system differently. It’s not like apple which basically locks down half the directories on a modern install from user manipulation.
The other issue is that freebsd-update is actually pretty efficient with bandwidth. There might be some tuning needed not just with installing files in /etc and so on but also getting it to be efficient for mirroring packages.
It’s not as clean cut as deinstalling and installing a newer package. You have to leave the machine in a semi consistent state while you’re doing it. You’d have to follow a similar pattern of updating the kernel first, booting on it, and then installing the other packages for instance. You’d have to generate a list of files that no longer exist in the new install and remove them. You need to merge config files or try to set a hook for mergemaster + a staged directory to diff against.
It’s complicated.
That’s a very insightful post.
Another thing that is increasingly more difficult is tracking and replicating changes on modern, complex, operating systems. It’s made more so when software installations spew files all over the system’s directories.
Recreating such a system after a major hardware upgrade (new PC) can result in weeks of “oh yeah, I forgot we installed that” and “what was the configuration file I had to manually edit to get this to work last time?”
Apple’s “.app” construct is an elegant solution to the file spew problem. It’s basically a directory structure treated by the GUI as a single file. A .app can contain executables, property list (.PLIST) files, frameworks, plugins, icons, and other resource files. It’s not perfect, and every developer’s use of it isn’t optimal, but it’s a step in the right direction.
If I remember correctly, that is what PC-BSD (TrueOS) introduced with their PBI packaging format. Not only did one package contain everything that’s needed to run the software (simplified: “all dependencies included”), it also used separated installation paths for everything. Updating and removal was easy because the updater always just concerned one such subtree.
Today, the Solaris-ism /opt is sometimes used for this purpose: One subdirectory (subtree) for each program, and symlinked “starters” in /opt/bin which is in $PATH. But of course that’s not a standard thing. 🙂
That’s not actually true on Linux and FreeBSD (and probably other unices). The kernel and any binaries in use exist in memory, whether RAM or swap. The stuff on the disk doesn’t matter to any running process. The only thing you need to watch out for is config file changes.
it is true. If you replace binaries with newer version in FreeBSD they won’t necessarily work with the kernel. pkg does what i said and the manual buildworld installworld steps do too. A future userland is not backward compatible!
I know why you think that. In Linux, glibc is maintained separately and works on a range of linux kernel versions. That’s just not true in FreeBSD. A 12.x libc is not compatible with a 11.x kernel, but a 12 kernel can run older userlands.
It’s possible not to be able to run reboot or shutdown in FreeBSD if you do the userland first and it will fail to boot in some cases with a newer userland and older kernel. You have to drop a newer kernel on the disk with a bootable flash or dvd in this case.
Further, Oracle developed the in memory patching for the linux kernel. In the even there was an issue like that, a distro could patch the running kernel. That can’t be done in BSD.