FreeBSD upgrade and packaging will change a lot in 15.0.
Currently - up to 14.x - the freebsd-update(8) command is used for upgrades - and yes - it can require manual intervention - but one can also use it in unattended mode like that:
But the FreeBSD 15.x will use PKGBASE concept [1] and [2] and parts of the system will be 'just' pkg(8) packages and also maintained by pkg(8) - so FreeBSD Base System upgrades will be just pkg(8) commands - just like now with non system packages.
FreeBSD has always been able to self-host (build the itself from source) with just whats available in the FreeBSD src repository. To do this it needs a toolchain that includes among other things a linker, an assembler, and a C and C++ compiler. This used to be GCC, but GCC was replaced with clang which is a C and C++ frontend for LLVM. Just sticking to the last GCC 4.x release under GPLv2 forever wasn't an option and neither was importing a GPLv3 toolchain. Clang also brought some welcome advantages (it used to provide a lot more useful and human readable error messages, better code analysis tools to catch common bugs).
The reasons you have different versions of LLVM in the ports tree is that users either directly require a specific version or other ports require a specific LLVM version as a dependency (e.g. compilers for Rust, Haskell, Julia, etc.). There will never be a situation where every user and every port is happy at the same time with just one LLVM version, because LLVM isn't just the compiler frontends, but also the C++ libraries used to implement compilers and API changes with each release.
And even if the compilers available in the ports tree using LLVM as their code generation backend could be patched to build with the latest version, which would already be an unreasonable demand on their port maintainers. The new LLVM release may add new optimisations that are "legal" to a language lawyering compiler writer according to their understanding of the LLVM IR semantics, but still break existing code by exploiting undefined, under defined, or implementation specific behaviour.
The problem with moving the system compiler out of the ports goes deeper than just the self hosting aspect. The binary package repositories compiled from the ports tree must work for all still supported minor releases on that major release line (e.g. https://pkg.freebsd.org/FreeBSD:14:amd64/latest/ works for both 14.0 and 14.1). Given that the supported lifetimes of minor releases in a major release line overlap and that compilers don't provide perfect binary compatibility this would lock in the compiler for the whole major release to whatever was packaged for the .0 release. Do you want to be restricted to C and C++ language version and instruction set support from 5 years ago by the end of a major release line? Stuck dealing with compiler bugs that have been fixed ages ago, but never backported?
I would like to see full support for external toolchains from ports before anyone dares to evict the compilers from the base system even if LLVM is a bloated enough to dominate the build time and install size.
Lets assume You got 4TB 6TB 5TB and 8TB drives ... just do a 4TB 1st primary partition on each of them and create a ZFS pool from that - I do not understand where the 'pain' is ...
You can then add 1TB 2nd partition on 6TB and 5TB and 8TB drives and add another ZFS VDEV to the same pool - or create another pool.
... and You can also add 3rd partition.
Also its really easy to get used drives in the same or similar size ... unless you live in some really 'hard to live' part of the world.
> As far as I know you can't have mismatching drives as a single contiguous space in ZFS. Maybe it has changed.
Yes you can, example below:
vermaden ~ % truncate -s 1G FILE.0
vermaden ~ % truncate -s 2G FILE.1
vermaden ~ % mdconfig.sh -c FILE.0
IN: created vnode at /dev/md0
vermaden ~ % mdconfig.sh -c FILE.1
IN: created vnode at /dev/md1
vermaden ~ % lsblk md0
DEVICE MAJ:MIN SIZE TYPE LABEL MOUNT
md0 2:17 1.0G zfs - -
vermaden ~ % lsblk md1
DEVICE MAJ:MIN SIZE TYPE LABEL MOUNT
md1 2:18 2.0G zfs - -
vermaden ~ % doas zpool create test md0 md1
vermaden ~ % zpool status test
pool: test
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
test ONLINE 0 0 0
md0 ONLINE 0 0 0
md1 ONLINE 0 0 0
errors: No known data errors
I do not know how you buy your disks but when I need to buy storage I know exactly what SIZE I want to buy - I do not just get ANY disk and then think 'how' to utilize it :)
But with ZFS you have plenty of options to use disks of different sizes.
Example below, RAIDZ from 4 disks of 2TB and added a mirror of two 5TB disks to the same ZFS pool.
vermaden ~ % doas zpool create test raidz md{0,1,2,3}
vermaden ~ % zpool status test
pool: test
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
test ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
md0 ONLINE 0 0 0
md1 ONLINE 0 0 0
md2 ONLINE 0 0 0
md3 ONLINE 0 0 0
errors: No known data errors
vermaden ~ % doas zpool add test mirror md4 md5
vermaden ~ % zpool status test
pool: test
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
test ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
md0 ONLINE 0 0 0
md1 ONLINE 0 0 0
md2 ONLINE 0 0 0
md3 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
md4 ONLINE 0 0 0
md5 ONLINE 0 0 0
errors: No known data errors
My 'fault' is that I do not add exact date of the update but ... this is the message I keep on my front page:
Keep in mind that I try to update articles posted here. I follow all supported FreeBSD versions – you can check which FreeBSD versions are currently supported on this page – FreeBSD Release Information: Currently Supported – from official FreeBSD website. If something gets out of date or works differently on newer versions – I add a needed UPDATE to a post to make it up to date.
reply