1. 50
  1.  

  2. 9

    Also here’s the full FreeBSD 13.0 Release Notes

    1. 5

      I wish there was something better there than freebsd-update(8) which takes hours (!!!!!) to do a major upgrade. It’s so bad, that the FreeBSD infrastructure people rolled their own custom solution.

      Sadly (?), PkgBase seems dead.

      1. 4

        I just updated 2 systems from 12.2 to 13.0 and it took maybe 20 or 30 minutes to do both systems.
        I don’t disbelieve you, but how is it taking hours for you? Slow internet (I have pretty fast internet)? Slow disks (I have either SSD’s or large zpools that are pretty zippy)?

        (note: I did have to wait about an hour for my local poudriere to rebuild all packages for 13.0, but that gets done anyway, so I didn’t include it in the time it took).

        I agree though, freebsd-update is in general pretty slow, and PkgBase seems like it may never arrive, or at the very least won’t happen for quite a while yet.

        1. 4

          I hate freebsd-update with a passion. It forks a child process for every single file that it compares and it does so sequentially and so it can be very slow on systems with slow single-threaded performance, platforms where fork is slower than normal (including some virtualised environments). It’s also heavily limited by random disk read latency because everything it does is sequential: If it tried to the comparisons in parallel then it could at least take advantage of things that are in the buffer cache, prefetched, or just cheaper to read out of order with NCQ in one thread while another is blocked on I/O, but it doesn’t.

          I’ve often seen it take an hour to upgrade a few hundred MiBs of the base system and then had pkg upgrade multiple GiBs of packages in under a minute on exactly the same machine.

          The logic for detecting changes is also really unreliable. I’ve had freebsd-upgrade leave me with an unbootable system three times. As far as I can tell, it scans the files, detects that they aren’t what it expects, and then patches them anyway.

          I really wish the FreeBSD Foundation would invest in pkg-base. It’s 80% done (it works great for me, but there are some configurations that it doesn’t work well for and there’s some usability that could be improved) but the rest of the work is tedious and involves the incredible pain of touching the FreeBSD build system, so it’s hard to get volunteers to do it.

          1. 3

            On my 24 core Xeon with ~250Mbps Internet and NVMe disks, upgrading from 12.2 to 13.0 took over two hours.

            I also upgraded some more modest 11.4 machines, and those “only” took about half an hour. Unsure about the discrepancy.

            Another machine I have got stuck, and I had to restart freebsd-update(8). The second time worked.

            freebsd-update(8) on FreeBSD, and syspatch(8) and sysupgrade(8) on OpenBSD are relatively new. Most of my life I have been doing upgrade by building from source, so I guess I shouldn’t complain too much, it’s still progress.

            1. 3

              freebsd-update(8) on FreeBSD, and syspatch(8) and sysupgrade(8) on OpenBSD are relatively new. Most of my life I have been doing upgrade by building from source, so I guess I shouldn’t complain too much, it’s still progress.

              I already used freebsd-update back in the day and I stopped using FreeBSD around 2014. It’s not that new.

              Two hours on a Xeon machine seems ridiculous; if you have the time, you should really write a bug report or something for that.

              1. 2

                I’ve certainly had some systems inexplicably take longer than others, but sounds like you have run into some real bad ones. Yikes!

                1. 1

                  I’ve got a little Celeron J4125 NUC-style machine that I did the 12.2->13 upgrade on. Took about 10 minutes.

                  I’ll be curious to learn what impacted a beefy Xeon or similar reports I’ve seen crop up occasionally.

                2. 3

                  20/30 minutes still seems pretty long to me for a base system update. freebsd-update seems optimized to reduce network usage with all its binary diff cleverness, which is still useful in various cases, but for many people it’s a lot less useful than it used to be. Even with my regular ADSL connection just doing a download of the ~220M of the full base.tar.xz + kernel.tar.xz will be faster (at 1M/s it’s less than 4 minutes), and the extract/removal of old tools shouldn’t take more than a minute or so.

                3. 4

                  PkgBase is not dead. People are using it as we speak. It’s just hasn’t been enabled by default as there are still some rough edges to be addressed. Here’s a community PkgBase server you may consider using: https://alpha.pkgbase.live/

                4. 4

                  * Removed CU-SeeMe support from libalias(3).

                  Damn, that’s a throwback. I’ve been meaning to write something on the history of videoconferencing…

                  1. 2

                    Right? I recall trying it circa 1992 at the Mac-based art lab I was working in while in grad school. That it worked at all seemed amazing.

                  2. 3
                     * Several drivers have been ported to the PowerPC64 architecture.
                    

                    I’m not gonna fall into the trap of saying “PowerPC? Who uses that anymore?”

                    So let me ask the actually relevant question - what are people using PowerPC for these days?

                    1. 7

                      There are many POWER systems in TOP500, including two in TOP10.

                      On a smaller scale, the aerospace industry uses it heavily as an embedded platform. So is the automotive industry.

                      1. 3

                        Wow. I didn’t know TOP500 existed. Thanks for that! I wonder if any of these IBM POWER systems are running FreeBSD :)

                        Something tells me not so much and that they’re all still running AIX.

                        1. 4

                          They are all running Linux[1]. There hasn’t been any non-Linux system in TOP500 for many years (decades?) turns out that AIX was last present in 2017.

                          Btw, the systems running AIX, Linux, and IBM i are all different even though they use the same CPUs. You can’t mix and match operating systems.

                          [1] https://www.top500.org/statistics/list/

                          1. 1

                            Holy cow and RedHat flavors DOMINATE the mix!

                            I guess that shouldn’t surprise me, but it does.

                            1. 4

                              That’s a little misleading, on many clusters the thing you log in to has RHEL/SuSE/CentOS/Scientific Linux but all of the compute nodes are busybox appliances so that’s really the “most prevalent” distro by orders of magnitude.

                              1. 2

                                rpm-based stuff always was kinda enterprise-y, while deb stuff was for “the little guy”. Not saying about quality, just how I saw it most of the time.

                                1. 2

                                  I know a few Highly Opinionated Debian sysadmins who might beg to differ but I get where you’re coming from here :)

                                  1. 1

                                    Yeah i don’t lean either way, it’s just how i perceived people generally think about it.

                                2. 1

                                  I’m not sure about other areas of HPC, but scientific HPC has been dominated by RHEL variants for a long time, partly influenced by Fermi Linux. Even if you didn’t specifically run a distro like Scientific Linux, a lot of the ecosystem assumed you were on something similar to RHEL or CentOS, and it was extra work to get things configured if you weren’t.

                                  It’s shifting a bit now with machine learning stacks, which are more likely to treat Ubuntu as the default assumption.

                                3. 1

                                  Btw, the systems running AIX, Linux, and IBM i are all different even though they use the same CPUs. You can’t mix and match operating systems.

                                  Yes, you can. I’ve had systems running all three on the built-in hypervisor. What you can’t do is run the IBM OSes on non-IBM hardware like a Talos II.

                            2. 2

                              Uh, did you completely miss all the hype around Raptor Talos/Blackbird workstations?

                              There are also Power Mac G5s still in use, the latest models of which are even PCIe based, but it’s still 2005 hardware. And there’s an AmigaOne thing powered by an NXP chip. There’s a crowdfunding project slowly collecting money to build a laptop with these NXP chips.

                              Also the PlayStation 3 was powerpc64 but it’s the worst option due to the comically small amount of RAM lol

                              1. 2

                                Sorry I don’t know what Talos Blackbird is.

                                1. 1

                                  POWER9 workstation boards focused on openness and obtainable by regular people (though still quite expensive). Many many blog posts about them have hit lobsters and other news aggregators…

                            3. 3

                              In-kernel TLS finally lands! This is very cool. I’m curious to see how straightforward it’ll be to use it.

                              1. 3

                                It’s disappointing that it supports TLS 1.0 & 1.1. Nobody should be using those. https://datatracker.ietf.org/doc/rfc8996/

                                1. 2

                                  My offhand guess is that netflix falls back to old tls versions due to old TV software (or similar devices) out there that end users can’t update.

                                  1. 1

                                    I hope old protocols are at least disabled by default and surrounded by scary warnings.

                              2. 1

                                How is FreeBSD’s Linux emulation these days? Is anyone running Linux-based Docker/OCI containers on FreeBSD in production (without running Linux itself through virtualization)?

                                1. 4

                                  It’s improved a lot in 13. It doesn’t support seccomp-bpf though, so you can’t run the Linux container management programs. It’s probably good enough to run a lot of Linux containers in jails, but the orchestration code isn’t there yet.

                                  1. 3

                                    Stupid not a FreeBSD user question: Why would you do that? Aren’t jails the moral equivalent? Or would one want to run Docker for simple software distribution convenience purposes?

                                    1. 4

                                      Docker / OCI containers in common use conflate a bunch of things:

                                      • A way of distributing a self-contained userspace thing.
                                      • A way of building a self-contained userspace thing using layers of filesystem overlay.
                                      • A way of orchestrating local deployment of self-contained userspace things.
                                      • A way of isolating self-contained userspace things.

                                      Jails provide the fourth of these (in a significantly lower-overhead way than the horrible mess of cgroups and seccomp-bpf on Linux), but they don’t provide any of the other bits. Between ZFS and jails, FreeBSD has great mechanisms for running container-like things, but doesn’t yet have good tooling for building and deploying them.

                                      The containerd port and runj program linked by @kwait are likely to end up with the right things here. That should make it possible to build layers, package them up and deploy them on FreeBSD. The bit that isn’t currently getting any investment is making runj able to deploy containers that are packaged as Linux binaries running on the FreeBSD Linux ABI layer.

                                      1. 2

                                        There is also Bastille, which looks pretty nice. IIUC it builds on FreeBSD jails and takes care of the distribution and deployment aspect (your first point).

                                        1. 2

                                          in a significantly lower-overhead way than the horrible mess of cgroups and seccomp-bpf on Linux

                                          As I understand it, the main Linux facility for this kind of isolation is namespaces. I’m not sure how seccomp-bpf found its way into container tools, but presumably “for extra security”.

                                          Namespaces should have the same kind of overhead (basically none) as jails. The main difference is that namespace API is additive (you tell it “isolate PIDs” then “isolate the networking” and so on, building the sandbox piece by piece) while the jails API is subtractive (you kinda just start with a package deal of full isolation, but you can opt out of some parts – set the FS root to /, or the networking to the host stack). Namespaces are more flexible, but much harder to use securely.

                                        2. 3

                                          It would be nice to be able to run the FreeBSD kernel, to have ZFS without entering a licensing gray area if nothing else, while being able to take advantage of both all the software available for Linux and the accumulated tooling and practices around Docker (especially when it comes to building container images). Since a Docker image is basically a JSON manifest and a bunch of tarballs, maybe it wouldn’t be too hard to write a tool that could fetch and unpack a Docker image and run it in a FreeBSD jail.

                                            1. 2

                                              That is really, really rad. I need this in my life.

                                              1. 4

                                                runj is my project! It’s nice to see other folks excited about it. There’s some previous discussion here. No Linux support yet; I’m focusing on a FreeBSD userland first.

                                            2. 3

                                              Given that zfs is now deployed on millions of Ubuntu installs around the world I’m not sure how much weight I’d place on said gray area.

                                              YMMV however.

                                              1. 2

                                                I just never understood this. The CDDL is not compatible with the GPL, and this prevents ZFS being part of the same code, though it can be installed as an external module, and from what I understand ZFS on Linux works fine.

                                                What’s the legal grey area here? How is this different from installing an MIT (or any other GPL-incompatible) licensed project on your Ubuntu machine?

                                                1. 5

                                                  As I understand it (I am not a lawyer, this is not legal advice), the issue comes from a bunch of different things:

                                                  First, the GPL says that any software derived from GPL’d software must impose the conditions of the GPL on the combined work and may not impose any additional conditions. This is usually paraphrased as saying that it must be GPL’d, but that’s not actually the case. It’s fine to ship a BSD-licensed file as part of a GPL’d project. The GPL also talks about ‘mere aggregation’. Just distributing two programs on the same medium is explicitly excluded from the GPL, but linking them may trigger the license terms.

                                                  Second, there’s a bit of a grey area about exactly what the GPL applies to in Linux. Linux is distributed under GPLv2, but the source tree includes a note written by Linus (which is not part of the license and not written as a legal document) that the GPL obviously doesn’t apply across the system call boundary. Some internal kernel symbols are also expose as public non-GPL-propagating symbols but that is not actually part of the license. To make this more fun, some bits of code in the kernel were released as GPL’d code elsewhere and then added to the Linux kernel and so it’s possible for the copyright holders of this code to assert that they don’t believe that these exemptions apply to their code. This is somewhat moot for ZFS because uses GPL-tainted kernel symbols.

                                                  Third, the GPL is a distribution license. This means that there are only two things that it can prevent you from doing:

                                                  • Distributing a GPL’d project
                                                  • Distributing something that is a derived work of a GPL’d project.

                                                  Typically, the work-around that companies such as nVidia use is to write a driver that is developed completely independently of the Linux kernel and is therefore not a derived work of the Linux kernel, then write a shim layer that is a derived work of the Linux kernel and is able to load their non-GPL’d driver. They cannot distribute the two together (because the GPL would kick in and prevent distribution of a thing where the combined work does not grant all of the permissions found in the GPL), but they can distribute their own code (they own it) and the shim (by itself, it is GPL compliant). A customer can then acquire both and link them together: the GPL is explicitly not a user license, once you have received the code you are free to use it in any way, including linking it with things where you are not permitted to release the result).

                                                  So using ZFS on Linux is fine, the tricky bit is how you distribute the the CDDL’d component and the Linux kernel together.

                                                  My general view of Linux legal questions is that the vast majority of users are doing something that could be regarded as a violation of the license but no one with standing to sue has any incentive to torpedo the ecosystem.

                                                  1. 1

                                                    Thanks for the detailed answer. This clears it up. 🙏

                                        3. 1

                                          Is FreeBSD’s grep better than the one macOS ships?

                                          1. 4

                                            Just the facts: FreeBSD 13 includes BSD grep 2.6.0-FreeBSD. On macOS Big Sur, grep --version reports an earlier version of the same project, BSD grep 2.5.1-FreeBSD, and man grep is stamped “July 28, 2010.”

                                            1. 1

                                              was kinda thinking the same thing, like how did they end up on the GNU grep instead of the BSD one? I’m sure there’s fun history there.

                                              1. 2

                                                GNU tools are great? People like Perl-style regexes and –long-arguments though it looks like more recent BSD greps have long args.

                                                1. 1

                                                  Oh interestingly this came from OpenBSD which at some point had just replaced their classic BSD version with “FreeGrep”: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/grep/grep.c.diff?r1=1.2&r2=1.3&f=h

                                                2. 1

                                                  Yes, in that I can run it on non-Apple hardware ;-P

                                                3. 1

                                                  From the release notes:

                                                  Removed the obsolete binutils 2.17 and gcc(1) 4.2.1 from the tree. All supported architectures now use the LLVM/clang toolchain.

                                                  Does this mean that FreeBSD can be used in a completely GNU-less way now?

                                                  1. 4

                                                    Not completely, but mostly. If you want to debug a kernel crash you still need gdb.

                                                    1. 3

                                                      There’s a wiki page that tracks the [L]GPL removal from base. It looks as if the only two things in base that are [L]GPL’d are:

                                                      • diff3, which (I think) is required by etcupdate (and possibly pkg?), so makes it difficult to upgrade the system if it’s not there. There’s been some work to replace this with the OpenBSD version, but it doesn’t look as if there’s been much progress for a long time.
                                                      • dialog, (LGPL, not GNU, I belive) which is used for a bunch of the system administration commands. You can build the base system without this if you’re building an appliance that doesn’t need these tools.

                                                      I generally end up installing bash though, because I learned some bashisms 20 years ago and never got around to retraining my fingers in zsh. I also install vim, so have a big GPL’d thing that I spend a lot of my time in on pretty much every FreeBSD system.

                                                      1. 2

                                                        nit: vim isn’t GPL’d, it’s Charityware.

                                                        1. 2

                                                          Huh, I thought it was GPL + a suggestion to donate, but it looks as if it’s its own license. Thanks!

                                                    2. 1

                                                      Not related to FreeBSD 13 (at least not that I am aware of), but other news in case someone is interested in trying it out. Vulkan is now supported using the NVIDIA driver.