'FreeBSD 15.0-RELEASE arrived this week, notes this report from The
Register, which calls it the latest release "of the Unix world's
leading alternative to Linux."
As well as numerous bug fixes and upgrades to many of its components,
the major changes in this version are reductions in the number of
platforms the OS supports, and in how it's built and how its component
software is packaged.
FreeBSD 15 has significantly reduced support for 32-bit platforms.
Compared to FreeBSD 14 in 2023, there are no longer builds for x86-32,
POWER, or ARM-v6. As the release notes put it:
"The venerable 32-bit hardware platforms i386, armv6, and 32-bit
powerpc have been retired. 32-bit application support lives on via the
32-bit compatibility mode in their respective 64-bit platforms. The
armv7 platform remains as the last supported 32-bit platform. We thank
them for their service."
Now FreeBSD supports five CPU architectures — two Tier-1 platforms,
x86-64 and AArch64, and three Tier-2 platforms, armv7 and up,
powerpc64le, and riscv64.
Arguably, it's time. AMD's first 64-bit chips started shipping 22
years ago. Intel launched the original x86 chip, the 8086 in 1978.
These days, 64-bit is nearly as old as the entire Intel 80x86 platform
was when the 64-bit versions first appeared. In comparison, a few
months ago, Debian 13 also dropped its x86-32 edition — six years
after Canonical launched its first x86-64-only distro, Ubuntu 19.10.
Another significant change is that this is the first version built
under the new pkgbase system, although it's still experimental and
optional for now. If you opt for a pkgbase installation, then the core
OS itself is installed from multiple separate software packages,
meaning that the whole system can be updated using the package
manager. Over in the Linux world, this is the norm, but Linux is a
very different beast... The plan is that by FreeBSD 16, scheduled for
December 2027, the restructure will be complete, the old distribution
sets will be removed, and the current freebsd-update command and its
associated infrastructure can be turned off.
Another significant change is reproducible builds, a milestone the
project reached in late October. This change is part of a
multi-project initiative toward ensuring deterministic compilation: to
be able to demonstrate that a certain set of source files and
compilation directives is guaranteed to produce identical binaries, as
a countermeasure against compromised code. A handy side-effect is that
building the whole OS, including installation media images, no longer
needs root access.
There are of course other new features. Lots of drivers and subsystems
have been updated, and this release has better power management,
including suspend and resume. There's improved wireless networking,
with support for more Wi-Fi chipsets and faster wireless standards,
plus updated graphics drivers... The release announcement calls out
the inclusion of OpenZFS 2.4.0-rc4, OpenSSL 3.5.4, and OpenSSH 10.0
p2, and notes the inclusion of some new quantum-resistant encryption
systems...
In general, we found FreeBSD 15 easier and less complicated to work
with than either of the previous major releases. It should be easier
on servers too. The new OCI container support in FreeBSD 14.2, which
we wrote about a year ago, is more mature now. FreeBSD has its own
version of Podman, and you can run Linux containers on FreeBSD. This
means you can use Docker commands and tools, which are familiar to
many more developers than FreeBSD's native Jail system.
"FreeBSD has its own place in servers and the public cloud, but it's
getting easier to run it as a desktop OS as well," the article
concludes. "It can run all the main Linux desktops, including GNOME on
Wayland."
"There's no systemd here, and never will be — and no Flatpak or Snap
either, for that matter.'
-- source: https://tech.slashdot.org/story/25/12/07/0627214
Cheers, Peter
'It runs locally, a free/open source home automation platform
connecting all your devices together, regardless of brand. And
GitHub's senior developer calls it "one of the most active, culturally
important, and technically demanding open source ecosystems on the
planet," with tens of thousands of contributors and millions of
installations.
That's confirmed by this year's "Octoverse" developer survey...
Home Assistant was one of the fastest-growing open source projects by
contributors, ranking alongside AI infrastructure giants like vLLM,
Ollama, and Transformers. It also appeared in the top projects
attracting first-time contributors, sitting beside massive developer
platforms such as VS Code... Home Assistant is now running in more
than 2 million households, orchestrating everything from thermostats
and door locks to motion sensors and lighting. All on users' own
hardware, not the cloud. The contributor base behind that growth is
just as remarkable: 21,000 contributors in a single year...
At its core, Home Assistant's problem is combinatorial explosion. The
platform supports "hundreds, thousands of devices... over 3,000
brands," as [maintainer Franck Nijhof] notes. Each one behaves
differently, and the only way to normalize them is to build a
general-purpose abstraction layer that can survive vendor churn, bad
APIs, and inconsistent firmware. Instead of treating devices as
isolated objects behind cloud accounts, everything is represented
locally as entities with states and events. A garage door is not just
a vendor-specific API; it's a structured device that exposes
capabilities to the automation engine. A thermostat is not a cloud
endpoint; it's a sensor/actuator pair with metadata that can be
reasoned about.
That consistency is why people can build wildly advanced automations.
Frenck describes one particularly inventive example: "Some people
install weight sensors into their couches so they actually know if
you're sitting down or standing up again. You're watching a movie, you
stand up, and it will pause and then turn on the lights a bit brighter
so you can actually see when you get your drink. You get back, sit
down, the lights dim, and the movie continues." A system that can
orchestrate these interactions is fundamentally a distributed
event-driven runtime for physical spaces. Home Assistant may look like
a dashboard, but under the hood it behaves more like a real-time OS
for the home...
The local-first architecture means Home Assistant can run on hardware
as small as a Raspberry Pi but must handle workloads that commercial
systems offload to the cloud: device discovery, event dispatch, state
persistence, automation scheduling, voice pipeline inference (if
local), real-time sensor reading, integration updates, and security
constraints. This architecture forces optimizations few consumer
systems attempt.
"If any of this were offloaded to a vendor cloud, the system would be
easier to build," the article points out. "But Home Assistant's
philosophy reverses the paradigm: the home is the data center..."
As Nijhof says of other vendor solutions, "It's crazy that we need the
internet nowadays to change your thermostat."'
-- source: https://news.slashdot.org/story/25/12/07/1955259
Cheers, Peter
