Search Results for: FreeBSD
The Vector Packet Processor (VPP) is a framework for moving packets around at high rates. Its core concept is handling packets in groups known as “vectors,” which allows for the native use of vector processor instructions for packet classification and processing in different CPU architectures — currently amd64 and arm64. VPP can process packets at incredibly high rates and competes with many dedicated forwarding appliances. This is achieved using userspace networking that bypasses the host’s normal network stack. This article describes the porting of VPP to FreeBSD and working with the upstream VPP project to include FreeBSD as a supported target. ↫ Tom Jones It’s not unusual for me to link to something a little over my head, and this is another example of something I know y’all will like, but I don’t really understand fully.
A new point release in the FreeBSD 14 series – the first one, in fact, not counting 14.0. FreeBSD 14.1 adds SIMD implementations of string and memory operations on amd64 in the C library to improve performance, improvements to the sound system, such as device hotplug support, and the latest versions of OpenZFS, clang/llvm, and OpenSSH. FreeBSD 14.0 users can just upgrade to FreeBSD 14.1, or you can do a fresh install, of course.
About a week ago I reported on a case study from Dell and FreeBSD, about Dell’s ThinOS thin client operating system, which basically consists of a proprietary Dell GUI running on top of, at the moment, FreeBSD 12 (they’re moving to FreeBSD 14 for the next ThinOS release). Well, this got me interested – I’ve always been fascinated by thin clients, and a Dell/Wyse FreeBSD ‘distribution’ is just wild enough to be interesting – so I went onto eBay, and bought a Dell thin client. More specifically, I bought a Dell OptiPlex 3000 Thin Client, which comes with an Intel Pentium Silver N6005, a four core CPU without hyperthreading, 16 GB of RAM, a 32GB eMMC storage chip with room for a small M.2 SSD, WiFi 6, Ethernet, USB 3.0, 2.0, and C ports, Bluetooth, and so on. A low-power, but still quite capable little computer that I snagged for a mere €130, which is a steal compared to the full unit price; my configuration is sold new for like €700-800. Of course, these things are sold in batches of hundreds or maybe even thousands of units, and in such volumes corporate clients get massive discounts. Still, it’s a nice deal. My model came installed with Ubuntu 20.04 LTS, which I was not at all interested in. I immediately downloaded the latest ThinOS version for my model, used Dell’s tool and instructions to create a bootable USB, and got to work. The installation process was quick and easy, and does indeed look like an automated FreeBSD installation, TUI and all. After the installation is completed, you get guided through a first-run experience to configure things like the keyboard, WiFi, and so on, and it looks rather fancy. Once I completed the first-run experience, I hit the roadblock I was expecting: in order to use ThinOS, you need a ThinOS Activation License. Since my device was originally sold with (I think) Ubuntu preinstalled, it doesn’t have a TAL in its UEFI, and the only way to push a TAL to a device is to use the Dell Wyse Management Suite. Sadly, the Dell WMS only runs on Windows, and to make matters far worse, only on Windows Server. And it gets even worse – even if I created a Windows Server VM just to run WMS, I need the Pro version, which isn’t free (the free Standard version cannot push TALs), and I’d need to buy a TAL. Aside from the Windows Server restriction, I was aware of these limitations and requirements, so I’m not in the least bit surprised. I was curious to see if buying a TAL was an easy experience, or if it’s entirely geared towards enterprise customers and silly hobbyists like me need not apply. Without a license, I can use the proprietary Dell user interface, but it seems I can’t connect to any possible VDI providers, and I can’t tell what other features might be gated at the moment. With some admittedly very mild poking and prodding, I also haven’t been able to discover any ways of ‘leaving’ Dell’s proprietary GUI to get to a terminal. I’ll do some more prodding over the coming days. I’m not entirely sure where to go from here when it comes to seeing just how much you can do with ThinOS, which was my original goal for this project. I have a feeling the pro version of the Dell Wyse Management Suite is going to be rather expensive – I can’t find any pricing information, which confirms my suspicions – so I think the journey ends here. Unless any OSNews readers have experience with this stuff, and can point me to some tips and tricks to perhaps acquire and install a TAL some other way, there won’t be a more in-depth look at Dell’s weird version of FreeBSD on OSNews. Which sucks, but was to be expected when it comes to enterprise software. Mind you, this does not mean the hardware is going to waste. Not only are there other purpose-built thin client operating systems to experiment with, it is also a full-fledged tiny x86 computer with completely silent passive cooling and a free M.2 slot, so the possibilities are endless.
Several Dell products use ThinOS 9, such as the OptiPlex 3000 Thin Client, the OptiPlex All-In-One, and the Latitude series laptops, such as the Latitude 3440 and 5440. ThinOS is a ready-to-deploy solution that aims to improve virtual desktops while offering a secure platform for applications and services. It provides users with a seamless and integrated experience, whether remotely or from the office. It’s a software environment that optimizes virtual workspaces. The latest version, ThinOS 9, is built on FreeBSD 12 with other 3rd-party open source components and is well-known for its robust security and stability. This aligns with the requirements of modern enterprises that demand high performance and protection in their computing solutions. ↫ Dell case study While Dell and FreeBSD call this a ‘case study’ but while I see plenty of case, I see little study – it’s mostly just a load of marketing speak. That being said, there’s still interesting news in here about the future of ThinOS. The next release of ThinOS, version 10, will make the jump from FreeBSD 12 to the current FreeBSD 14 release, drastically improving hardware support in the process, while also bringing in the various other benefits of the latest FreeBSD release. It will also improve ThinOS’ compatibility with Linux applications, a feature of FreeBSD, which is something Dell is keen to highlight. It should come as no surprise that ThinOS 10 will also improve its security features, probably also mostly coming along for the ride from FreeBSD 14. Dell also mentions that it intends to continue using FreeBSD as the base for ThinOS, which could’ve easily gone differently as part of Dell’s acquisition of Wyze, where ThinOS originally comes from. This is good news for FreeBSD, but at the same time, when I look at thin clients on Dell’s website, ThinOS is just one of the options, and every photo shows the devices running Windows 10 IoT Enterprise LTSC 2021. I genuinely wonder what the spread is between buyers opting for ThinOS, Windows, and Linux. Thin clients have always fascinated me, so perhaps I should go onto eBay, figure out which Dell thin clients are still supported by the latest ThinOS release, buy one, and set up a simple thin client environment in my home – using ThinOS, of course.
FreeBSD is working on a graphical installer. Finally. The first hurdle to overcome when testing a new Operating System is to get it installed. What is more, the first impression new users gather from an Operating System is its installation process. The state of the art for Operating System installers nowadays definitely involves a graphical process. This is the case for mainstream systems but also for other UNIX systems comparable to FreeBSD: RedHat Enterprise Linux, Ubuntu, Debian GNU/Linux, or even Devuan GNU+Linux Regardless of the technical level of the actual user, this is how the platform will be compared in the public eye. Instead, with knowledge of the current bsdinstall(8) and bsdconfig(8) utilities, I envisioned a BSD-licensed replacement for Xdialog(1). Just like when invoking bsdconfig with the -X switch for graphical mode, it could be dropped in instead of bsddialog(1) and allow graphical installation – while sharing the infrastructure of the current installer. To avoid confusion with the current implementation of Xdialog from the x11/xdialog port, I have named its replacement gbsddialog(1). It also has to be said that Xdialog is quite obsolete (latest release in 2006) and this shows visually too. ↫ Pierre Pronchery in the FreeBSD status report I can’t believe it’s taken FreeBSD this long to both consider and build a graphical installer. Currently being enveloped in the world of OpenBSD, there’s clearly so much the BSD world has to offer to desktop users such as myself, but at the same time, there’s a lot of low-hanging fruit that the various BSDs can address to make the experience just that little bit more pleasant. They obviously don’t have to – not every project is aiming at desktop use – but it just makes onboarding so much nicer. The next step – perhaps in 2037 – would be to offer a desktop-oriented installation image, with a default desktop environment and settings optimised for desktop use. Right now, a lot of fiddling and optimisation for this use case is left to the user, and for newcomers such as myself this means a lot of reading, making sense of contradictory advice and suggestions, wading through endless, often outdated, online guides, and so on. Now, I don’t particularly mind doing this, but I’m sure it’s chasing people away who could end up making meaningful contributions. Meanwhile, after trying out FreeBSD for a while a few weeks ago but it not being a good fit for me, I’m now exploring and using OpenBSD and it’s been a great experience. Although unlikely, I hope OpenBSD, too, can perhaps consider making some minor affordances to desktop users – because as I’ve learnt, OpenBSD feels right at home on a desktop, more so than I ever expected.
A few weeks ago we talked about how iXsystems, the company behind TrueNAS CORE and SCALE, has all but confirmed that its FreeBSD-based CORE product will be put in maintenance mode, while the Linux-based SCALE product will get all the attention and focus from here on out. In an interview with Blocks & Files, the company gave more insight into this choice. “We had a huge chunk of our engineering staff spending time improving FreeBSD as opposed to working on features and functionalities. What’s happened now with the transition to having a Debian basis, the people I used to have 90 percent of their time working on FreeBSD, they’re working on ZFS features now … That’s what I want to see; value add for everybody versus sitting around, implementing something Linux had a years ago. And trying to maintain or backport, or just deal with something that you just didn’t get out of box on FreeBSD.” “It’s not knocking against FreeBSD. We love it. That’s our heritage. That’s our roots, I was on the CORE team elected twice. So believe me, if I felt like I could have stayed on FreeBSD for the next 20 years, I would have absolutely preferred to do that … But at some point, you gotta read the writing on the wall and say, well, all the the vendor supported-innovations are happening on the Linux side these days.” BSD aficionados don’t like this change. Moore said: “Talk is cheap and complaints are free. You know, everyone loves to complain about it. But … if people wanted to push FreeBSD forward for the last 15 years, they would have.” ↫ Chris Mellor at Blocks & Files Above all else, my personal north star is choice, especially in technology, and as such, I want iXsystems to keep focusing on FreeBSD so that not everyone is using Linux for server- and server-like workloads. The fact that TrueNAS was a FreeBSD-based product for this long was amazing, and I would definitely have preferred if it stayed that way for many, many more years to come. However, I don’t think the people of TrueNAS are saying anything wrong or outrageous here. They’ve got employees to feed, and the money is in Linux, not FreeBSD. If they spend more money, time, and resources on getting FreeBSD on par with features Linux has had for ages than on actually developing their own product – TrueNAS – then they’re fighting a losing battle. Honestly, I’m surprised it’s taken them this long to take this controversial step. All we can hope for is that the things they work on, the features they develop, will make it to FreeBSD regardless.
Bad news from BSD land – the oldest vendor of BSD systems is changing direction away from FreeBSD and toward Linux. NAS vendor iXsystems has been busy this year, but apart from some statements in online user communities, it hasn’t been talking about the big news. Back in 2022, we covered TrueNAS CORE 13, the new release of its FreeBSD-based turnkey OS for NAS servers, and in that article we mentioned its new product, the Debian-based TrueNAS SCALE, aimed at providing storage for Kubernetes users. Now it seems the company is betting its future on that Linux-based product, meaning the end is in sight for the FreeBSD offering. ↫ Liam Proven at The Register Very sad to read, as more monoculture is not exactly great, but at the same time, from a corporate perspective, it’s also not entirely unexpected to focus on the server operating system with by far the widest industry support. I hope the fork mentioned in the article gains some steam, because having competition in this space is crucially important.
FreeBSD 13.3 has been released, and as this is a point release of the stable branch, it’s not a major shake-up or overhaul of the platform. We’ve got the usual updated versions of LLVM, clang, OpenSSH, and so on, and there’s a number of stability fixes to native and LinuxKPI-based WiFi drivers. Of course, there’s much more, so head on over to the release notes for the full details.
NixBSD is an attempt to make a reproducible and declarable BSD, based on NixOS. Although theoretically much of this work could be copied to build other BSDs, all work thus far has been focused on building a FreeBSD distribution. ↫ NixBSD Github page It was only a matter of time before someone would try and build this.
FreeBSD is deprecating 32-bit platforms over the next couple of major releases. We anticipate FreeBSD 15.0 will not include the armv6, i386, and powerpc platforms, and FreeBSD 16.0 will not include armv7. Support for executing 32-bit binaries on 64-bit kernels will be retained through at least the lifetime of the stable/16 branch if not longer. (There is currently no plan to remove support for 32-bit binaries on 64-bit kernels.) ↫ John Baldwin on freebsd-announce I don’t think this is too egregious of a timeline, but there’s always someone with some weird edge case that gets bit hard by deprecations like these.
FreeBSD is discussing adding Rust to the FreeBSD base system. In a recent thread on src-committers, we discussed the costs and benefits of including Rust code in the FreeBSD base system. To summarize, the cost is that it would double our build times. imp suggested adding an additional step after buildworld for stuff that requires an external toolchain. That would ease the build time pain. The benefit is that some tools would become easier to write, or even become possible. ↫ Warner Losh on the freebsd-hackers mailing list From everything I’ve read and what you, the readers, have told me, someone who isn’t a programmer, languages like Rust really are a big improvement over older languages, and it’s probably not a good idea for a major, important project like FreeBSD to isolate its base system from such progress. Now, I’m not at all qualified to say whether Rust, specifically, is the right choice, but a language like Rust should probably be part of the base system. A big issue is FreeBSD’s architecture support. Rust is not well-supported or even supported at all on all the various platforms FreeBSD supports, which might prove to be a road block for now. That being said, letting barely used ISAs hamper your progress too much might not be a good idea either. Rust has already become a supported language for the development of the Linux kernel.
Having re-discovered my love for FreeBSD on the desktop for the past month or so, I embarked in yet another adventure with it: creating a portable installation of it a USB drive so I could carry it with me on the go. This would be a great addition to my everyday carry, and would also again put the OS in test against many situations I have not had faced yet with it. ↫ Klaus Zimmermann Always a useful tool to have.
FreeBSD UNIX system can be updated in many ways. You can use freebsd-update(8) command to fetch and install the official binary patches. You can download the FreeBSD sources and compile your new version. You can download and install base.txz and kernel.txz sets in a new ZFS Boot Environment along with copying over your config files there – Other FreeBSD Version in ZFS Boot Environment – as documented here. While for most users these three options will be more then enough – there is a small group or people that need something else. Companies. People that like to use custom FreeBSD version or enterprise corporate world that needs to fulfill many compliance regulations. For their multiple reasons – including but not limited to – security – they want to have their own trusted FreeBSD update infra under their control. ↫ vermaden It’s from vermaden, so if you’re a FreeBSD user, you know you’re getting good information. Their website is a treasure trove of incredibly detailed information about pretty much everything related to installing, running, and living with FreeBSD.
FreeBSD has supported nesting of jails natively since version 8.0, which dates back to 2009. Looking at the jail(8) man page, there is an entire paragraph named Hierarchical Jails that explains the concept of jail hierarchy well. It’s one of the many gems of FreeBSD that, although not widely known or used, is, in my opinion, extremely useful. BastilleBSD plays a central role in this article, and that’s a project I’ve been hearing a lot about recently. I feel like the various BSDs are currently hitting a stride, and there seems to be a lot of movement from Linux to BSD at the moment.
After a few minor delays, FreeBSD 14.0 has officially been released. The highlights according to the FreeBSD team itself: For more details, you can dive into the release notes, and if you’re already using FreeBSD you know exactly how to upgrade.
I encountered yet another discussion about OpenBSD PF versus FreeBSD PF. For those who are new to the discussion: OpenBSD developers created PF in 2001, and it rapidly improved to become the most approachable open source packet filter. FreeBSD ported PF over to its kernel in 2004, with occasional updates since. Today a whole bunch of folks who don’t program echo cultish wisdom that one or the other version of PF has fallen behind, not kept up on improvements, or otherwise betrayed their community. My subtler comments have been misinterpreted, so let’s try this. These claims are garbage. Contrary to what the peanut gallery of open source thinks, in general, the rule is that open source teams work together all the time, more often than not across project lines. Of course the OpenBSD developers are working together and sharing code when it comes to things like PF – they most likely share a lot of features and code, and while one of the two versions of PF might get a certain feature first, it will make its way to the other soon enough. These are professionals – not forum posters.
In June 2022, I started work on porting FreeBSD to run on Firecracker. My interest was driven by a few factors. First, I had been doing a lot of work on speeding up the FreeBSD boot process and wanted to know the limits that could be reached with a minimal hypervisor. Second, porting FreeBSD to new platforms always helps to reveal bugs — both in FreeBSD and on those platforms. Third, AWS Lambda only supports Linux at present; I’m always eager to make FreeBSD more available in AWS (although adoption in Lambda is out of my control, Firecracker support would be a necessary precondition). The largest reason, however, was simply because it’s there. Firecracker is an interesting platform, and I wanted to see if I could make it work. Firecracker is Amazon’s virtual machine monitor. This article goes in great detail about the process of porting FreeBSD to run on Firecracker.
FreeBSD developers are looking at using the open-source NVIDIA kernel driver being developed by NVIDIA as an open-source Direct Rendering Manager driver that is out-of-tree, but not to be confused with Nouveau. With that kernel driver they are able to provide this nvidia-drm-kmod driver on their own and within the ports collection for better integration with the kernel and those wanting one less kernel binary blob. Excellent news for FreeBSD users with NVIDIA cards.
FreeBSD is a compelling and cutting-edge operating system that provides a wealth of features and advantages. FreeBSD’s deep OpenZFS integration, completely customizable packaging, and the ability to manage a huge fleet with a small team make it a clear contender for consideration in your next infrastructure build. This one’s written by a company that, among other things, sells FreeBSD and OpenZFS support, so take that into account when reading the article.
One of my old home automation boards running ebusd is still using Raspberry PI 2 B SoC. FreeBSD is still perfectly supporting this hardware, however, due to being a Tier-2 platform, binary updates freebsd-update are not supported. Of course, one can download the new image, but this will mean re-installing and reconfiguring all the software, which is time-consuming and painful. Also, the traditional “build from source” way will probably take forever on this tiny board and also could potentially destroy the SD card. So the obvious alternative was cross-compilation. If you’re in this very specific niche – you’re very happy this guide exists.
