Home > FreeBSD > FreeBSD 12.0 releasedFreeBSD 12.0 released Submitted by Ruben Thom Holwerda 2018-12-12 FreeBSD 10 CommentsThe 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. About The Author Thom HolwerdaFollow me on Twitter @thomholwerda 10 Comments FlyingJester 2018-12-12 11:56 pm EST Cool to see more features for jails, especially bhyve inside a jail! jessesmith 2018-12-13 4:15 pm EST 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. tankist 2018-12-13 7:37 pm EST TrueOS is a trailblazer for newest technologies while FreeBSD is more for stability. jessesmith 2018-12-13 10:14 pm EST 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. laffer1 2018-12-14 5:16 am EST 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. fmaxwell 2018-12-15 12:34 pm EST 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.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. Doc Pain 2018-12-16 11:13 pm EST 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. [/q]On FreeBSD, there is a separation between “the OS” and “3rd party programs” (usually installed from the ports collection from source, or via pkg). System configuration resides in /etc, whereas 3rd party programs and services use /usr/local/etc for this purpose. The /usr/local subtree has almost the same structure as the top level directory entries, just for “not the OS” stuff. See “man 7 hier” for details.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?”It can get even worse if file formats, names, or locations change. Even though some programs try to use what’s there and make the best out of it, other services might fail to start (or crash!) if they expect a configuration of format X, but there’s only the file in format Y of the previously installed version available. This is something quite hard (or nearly impossible?) to deal with by the updating process itself.Keeping track of things that have been touched manually is often helpful. Versioning systems such as SVN or Git (or in the past, OS-supplied CVS) can be a real benefit.[q]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.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. 🙂 tidux 2018-12-15 9:35 pm EST 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. laffer1 2018-12-15 9:44 pm EST 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! laffer1 2018-12-15 10:09 pm EST 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.