We have probably all seen the marketing blurbs on packaging and elsewhere promoting the amazing lifespan of LED lighting solutions. Theoretically you should be able to install a LED bulb in a fixture that used to hold that incandescent lightbulb which had to be replaced annually and have it last a decade or longer. Yet we seem to replace these LED bulbs much more often than that, with them suffering a range of issues. To get to the root cause of this, [The Doubtful Technician] decided to perform an autopsy on a range of dead lightbulbs which he got from a variety of sources and brands.

One lamp is an Amazon-bought one by a seller who seems to have vanished, but was promised over 3 years of constant use. Other than the fun blinding of oneself while testing, this one was easy to diagnose, with a dodgy solder joint on a resistor in a MELF package. The next one from Lowes was very dim, and required popping open with some gentle force, which revealed as likely culprit a shorted SMD resistor. Finally a more substantial (i.e. heavier) bulb was tested which had survived about 7 years in the basement until it and its siblings began to suddenly die. Some might consider this the normal lifespan, but what really failed in them?

The electronics in this last bulb were the most impressive, with a full switch mode power supply (SMPS) that appears to have suffered a failure. Ultimately the pattern with these three bulbs was that while the LEDs themselves were still fine, it were things like the soldering joints and singular components on the LED driver PCB that had failed. Without an easy way to repair these issues, and with merely opening the average LED lightbulb being rather destructive, this seems like another area where what should be easy repairs are in fact not, and more e-waste is created.

With the latest release of Raspberry Pi OS (formerly Raspbian) the end of the X Window System has become reality, completing a years-long transition period. Although this change between display servers is not something which should be readily apparent to the casual user, the change from the client-server-based X11 protocol to the monolithic Wayland protocol has a number of implications. A major change is that with the display server and window manager no longer being separate units, features such as network transparency (e.g. remote X-sessions) are no longer a native feature, but have to be implemented separately by e.g. the Wayland compositor.

For Raspberry Pi the transition to Wayland was based on the perceived efficiency and security benefits of the monolithic architecture, with the 2021 release of Raspbian (based on Debian Bullseye) testing the waters using the hybrid X11 window manager/Wayland compositor Mutter. This allowed for switching between X11 and Wayland without committing. In 2023 Mutter was replaced with the Wayfire compositor with Wayland becoming the default on Raspberry Pi 4 and 5 platforms. Along the way it was found that the Wayfire project wasn’t developing in a way that would benefit Raspberry Pi OS, which led to what should now be the final Wayland compositor in the form of Labwc.

One advantage of Labwc is that it is more lightweight than Wayfire and Raspberry Pi has judged that this means that it should be the default across all Raspberry Pi systems. Compatibility with X11-based software is maintained with the XWayland library, so that users should ideally not notice any difference after switching to Labwc even on lower-end boards. Unless you’re one one of those people who use features such as (remote) X-sessions, nothing should feel markedly different.

In addition to this big change, the new Raspberry Pi OS release also improves touch screen support with the integrated Squeekboard virtual keyboard popping up when a touch screen is detected. Finally, the remote access Raspberry Pi Connect feature sees a few tweaks, which is the feature that effectively replaces remote X-sessions. Considering how glacially slow X desktop sessions can be, this is something which can be considered an improvement, but it would be nice if there was an alternative that didn’t rely on Raspberry Pi-provided services to work.

Probably not too many people around the world celebrated November 1st, 2023, but on this momentous date FreeBSD celebrated its 30th birthday. As the first original fork of the first complete and open source Unix operating system (386BSD) it continues the legacy that the Berkeley Software Distribution (BSD) began in 1978 until its final release in 1995. The related NetBSD project saw its beginnings somewhat later after this as well, also forking from 386BSD. NetBSD saw its first release a few months before FreeBSD’s initial release, but has always followed a different path towards maximum portability unlike the more generic nature of FreeBSD which – per the FAQ – seeks to specialize on a limited number of platforms, while providing the widest range of features on these platforms.

This means that FreeBSD is equally suitable for servers and workstations as for desktops and embedded applications, but each platform gets its own support tier level, with the upcoming version 15.x release only providing first tier support for x86_64 and AArch64 (ARMv8). That said, if you happen to be a billion-dollar company like Sony, you are more than welcome to provide your own FreeBSD support. Sony’s Playstation 3, Playstation 4 and Playstation 5 game consoles namely all run FreeBSD, along with a range of popular networking and NAS platforms from other big names. Clearly, it’s hard to argue with FreeBSD’s popularity.

Despite this, you rarely hear people mention that they are running FreeBSD, unlike Linux, so one might wonder whether there is anything keeping FreeBSD from stretching its digital legs on people’s daily driver desktop systems?

In The Beginning There Was UNIX

Once immortalized on the silver screen with the enthusiastically spoken words “It’s a UNIX system. I know this.”, the Unix operating system (trademarked as UNIX) originated at Bell Labs where it initially was only intended for internal use to make writing and running code for systems like the PDP-11 easier. Widespread external use started with Version 6, but even before that it was the starting point for what came to be known as the Unix-based OSes:

After FreeBSD and NetBSD forked off the 386BSD codebase, both would spawn a few more forks, most notable being OpenBSD which was forked off NetBSD by Theo de Raadt when he was (controversially) removed from the project. From FreeBSD forked the Dragonfly BSD project, while FreeBSD is mostly used directly for specific applications, such as GhostBSD providing a pleasant desktop experience with preconfigured desktop and similar amenities, and pfSense for firewall and router applications. Apple’s Darwin that underlies OS X and later contains a significant amount of FreeBSD code as well.

Overall, FreeBSD is the most commonly used of these OSS BSDs and also the one you’re most likely to think of when considering using a BSD, other than OS X/MacOS, on a desktop system.

Why FreeBSD Isn’t Linux

The Linux kernel is described as ‘Unix-like’, as much like Minix it does not directly derive from any Unix or BSD but does provide some level of compatibility. A Unix OS meanwhile is the entirety of the tools and applications (‘userland’) that accompany it, something which is provided for Linux-based distributions most commonly from the GNU (‘GNU is Not Unix’) project, ergo these Linux distributions are referred to as GNU/Linux-based to denote their use of the Linux kernel and a GNU userland. There is also a version of Debian which uses GNU userland and the FreeBSD kernel, called Debian GNU/kFreeBSD, alongside a (also Unix-like) Hurd kernel-based flavor of Debian (Debian GNU/Hurd).

In terms of overall identity it’s thus much more appropriate to refer to ‘Linux kernel’ and ‘GNU userland’ features in the context of GNU/Linux, which contrasts with the BSD userland that one finds in the BSDs, including modern-day MacOS. It is this identity of kernel- and userland that most strongly distinguishes these various operating systems and individual distributions.

These differences result in a number of distinguishing features, such as the kernel-level FreeBSD jail feature that can virtualize a single system into multiple independent ones with very little overhead. This is significantly more secure than a filesystem-level chroot jail, which was what Unix originally came with. For other types of virtualization, FreeBSD offers bhyve, which can be contrasted with the kernel-based virtualization machine (KVM) in the Linux kernel. Both of these are hypervisor/virtual machine managers that can run a variety of guest OSes. As demonstrated in a comparison by Jim Salter, between bhyve and KVM there is significant performance difference, with bhyve/NVMe on FreeBSD 13.1 outperforming KVM/VirtIO on Ubuntu 22.04 LTS by a large margin.

What this demonstrates is why FreeBSD for storage and server solutions is such a popular choice, and likely why Sony picked FreeBSD for its customized Playstation operating systems, as these gaming consoles rely heavily on virtualization, as with e.g. the PS5 hypervisor.

OpenZFS And NAS Things

A really popular application of FreeBSD is in Network-Attached Storage (NAS), with originally FreeNAS (now TrueNAS) running the roost here, with iXsystems providing both development and commercial support. Here we saw some recent backlash, as iXsystems announced that they will be adding a GNU/Linux-based solution (TrueNAS SCALE), while the FreeBSD-based version (TrueNAS CORE) will remain stuck on FreeBSD version 13. Here The Register confirmed with iXsystems that this effectively would end TrueNAS on FreeBSD. Which wouldn’t be so bad if performance on Linux wasn’t noticeably worse as covered earlier, and if OpenZFS on Linux wasn’t so problematic.

Unlike with FreeBSD where the ZFS filesystem is an integral part of the kernel, ZFS on Linux is more of an afterthought, with a range of different implementations that each have their own issues, impacting performance and stability. This means that TrueNAS on Linux will be less stable, slower and also use more RAM. Fortunately, as befits an open source ecosystem, an alternative exists in the form of XigmaNAS which was forked from FreeNAS and follows current FreeBSD fairly closely.

So what is the big deal with ZFS? Originally developed by Sun for the Solaris OS, it was released under the open source CDDL license and is the default filesystem for FreeBSD. Unlike most other filesystems, it is both the filesystem and volume manager, which is why it natively handles features such as RAID, snapshots and replication. This also provides it with the ‘self-healing’ ability where some degree of data corruption is detected and corrected, without the need for dedicated RAID controllers or ECC RAM.

For anyone who has had grief with any of the Ext*, Reiserfs or other filesystems (journaled or not) on Linux, this probably sounds pretty good, and its tight integration into FreeBSD again explains why it’s it’s such a popular choice for situations where data integrity, performance and stability are essential.

FreeBSD As A Desktop

It’s probably little surprise that FreeBSD-as-a-desktop is almost boringly similar to GNU/Linux-as-a-desktop, running the Xorg server and one’s desktop environment (DE) of choice. Which also means that it can be frustratingly broken, as I found out while trying to follow the instructions in the FreeBSD handbook for setting up Xfce. This worked about as well as my various attempts over the years to get to a working startx on Debian and Arch. Fortunately trying out another guide on the FreeBSD Foundation site quickly got me on the right path. This is where using GhostBSD (using the Mate DE by default) is a timesaver if you want to use a GUI with your FreeBSD but would like to skip the ‘deciphering startx error messages’ part.

After installation of FreeBSD (with Xfce) or GhostBSD, it’s pretty much your typical desktop experience. You got effectively the same software as on a GNU/Linux distro, with FreeBSD even providing binary (user-space) compatibility with Linux and with official GPU driver support from e.g. NVidia (for x86_64). If you intend to stick to the desktop experience, it’s probably quite unremarkable from here onwards, minus the use of the FreeBSD pkg (and source code ports) package manager instead of apt, pacman, etc.

Doing Some Software Porting

One of my standard ways to test out an operating system is to try and making some of my personal open source projects run on it, particularly NymphCast as it takes me pretty deep through the bowels of the OS and its package management system. Since NymphCast already runs on Linux, this should be a snap, one would think. As it turns out, this was mostly correct. From having had a play with this on FreeBSD a few years ago I was already aware of a few gotchas, such as the difference between GNU make and BSD make, with the former being available as the gmake package and command.

Another thing you may want to do is set up sudo (also a package) as this is not installed by default. After this it took me a few seconds to nail down the names of the dependencies to install via the FreeBSD Ports site, which I added to the NymphCast dependencies shell script. After this I was almost home-free, except for some details.

These details being that on GhostBSD you need to install the GhostBSD*-dev packages to do any development work, and after some consulting with the fine folks over at the #freebsd channel on Libera IRC I concluded that using Clang (the system default) to compile everything instead of GCC would resolve the quaint linker errors, as both apparently link against different c++ libraries (clang/libc++ vs gcc/libstdc++).

This did indeed resolve the last issues, and I had the latest nightly of NymphCast running on FreeBSD 14.1-RELEASE, playing back some videos streaming from Windows & Android systems. Not that this was shocking, as the current stable version is already up on Ports, but that package’s maintainer had make similar tweaks (gmake and use of clang++) as I did, so this should make their work easier for next time.

FreeBSD Is Here To Stay

I’ll be the first to admit that none of the BSDs really were much of a blip on my radar for much of the time that I was spending time with various OSes. Of course, I got lured into GNU/Linux with the vapid declarations of the ‘Year of the Linux Desktop’ back in the late 90s, but FreeBSD seems to always have been ‘that thing for servers’. It might have been just my fascination with porting projects like NymphCast to other platforms that got me started with FreeBSD a few years ago, but the more you look into what it can do and its differences with other OSes, the more you begin to appreciate how it’s a whole, well-rounded package.

At one point in time I made the terrible mistake of reading the ‘Linux From Scratch’ guide, which just reinforced how harrowingly pieced together Linux distributions are. Compared to the singular code bases of the BSDs, it’s almost a miracle that Linux distributions work as well as they do. Another nice thing about FreeBSD is the project structure, with no ‘Czar for life’, but rather a democratically elected core leadership. In the 30-year anniversary reflection article (PDF) in FreeBSD Journal the way this system was created is described. One could say that this creates a merit-based system that rewards even newcomers to the project. As a possible disadvantage, however, it does not create nearly the same clickbait-worthy headlines as another Linus Torvalds rant.

With widespread industry usage of FreeBSD and a strong hobbyist/enthusiast core, it seems fair to say that FreeBSD’s future looks brighter than ever. With FreeBSD available for easy installation on a range of SBCs and running well in a virtual machine, it’s definitely worth it to give it a try.

Over the years, Apple has gone all-in on parts pairing. Virtually every component in an iPhone and iPad has a unique ID that’s kept in a big database over at Apple, which limits replacement parts to only those which have their pairing with the host system officially sanctified by Apple. With iOS 18 there seems to be somewhat of a change in how difficult getting a pairing approved, in the form of Apple’s new Repair Assistant. According to early responses by [iFixit] and in a video by [Hugh Jeffreys] the experience is ‘promising but flawed’.

As noted in the official Apple support page, the Repair Assistant is limited to the iPhone 15+, iPad Pro (M4) and iPad Air (M2), which still leaves many devices unable to make use of this feature. For the lucky few, however, this theoretically means that you can forego having to contact Apple directly to approve new parts. Instead the assistant will boot into its own environment, perform the pairing and calibration and allow you to go on your merry way with (theoretically) all functionality fully accessible.

The bad news here is that parts whose IDs show up as being locked (Activation Lock) are ineligible, which is something you cannot tell when you’re buying replacement parts. During [iFixit]’s testing involving swapping logic boards between two iPhone 15 Pros they found many issues, ranging from sudden reboots during calibration and boot looping. Some of these issues were due to the captive-portal-based WiFi network at [iFixit] HQ, but after eliminating that variable features like Face ID still refused to calibrate among other issues.

Meanwhile [Hugh]’s experiences have been more positive, but the limited nature of this feature, and the issues surrounding used and third-party parts, mean that the practical use of this Repair Assistant will remain limited, with tons of perfectly fine Activation Locked parts scrapped each year and third-party parts requiring pairing hacks to make basic features work, even on Apple’s MacBooks.

IOS 18 also adds battery monitoring for third-party batteries, which is a nice touch, but one cannot help but get the feeling that Apple is being dragged kicking and screaming into the age of easy repairs and replacements with Apple devices.

Featured image: A stack of Activation Locked MacBooks destined for the shredder in refurbisher [John Bumstead]’s workshop.

In 2020 international shipping saw itself faced with new fuel regulations for cargo ships pertaining to low sulfur fuels (IMO2020). This reduced the emission of sulfur dioxide aerosols from these ships across the globe by about 80% practically overnight and resulting in perhaps the biggest unintentional geoengineering event since last century.

As detailed in a recent paper by [Tianle Yuan] et al. as published in Nature, by removing these aerosols from the Earth’s atmosphere, it also removed their cooling effect. Effectively this change seems to have both demonstrated the effect of solar engineering, as well as sped up the greenhouse effect through radiative forcing of around 0.2 Watt/m² of the global ocean.

The inadvertent effect of the pollution by these cargo ships appears to have been what is called marine cloud brightening (MCB), with the increased reflectivity of said clouds diminishing rapidly as these pollution controls came into effect. This was studied by the researchers using a combination of satellite observations and a chemical transport model, with the North Atlantic, the Caribbeans and South China Sea as the busiest shipping channels primarily affected.

Although the lesson one could draw from this is that we should put more ships on the oceans burning high-sulfur fuels, perhaps the better lesson is that MCB is a viable method to counteract global warming, assuming we can find a method to achieve it that doesn’t also increase acid rain and similar negative effects from pollution.

Featured image: Time series of global temperature anomaly since 1980. (Credit: Tianle Yuan et al., Nature Communications Earth Environment, 2024)

A joke in networking circles is that the switch from IPv4 to IPv6 is always a few years away. Although IPv6 was introduced in the early 90s as a result of the feared imminent IPv4 address drought courtesy of the blossoming Internet. Many decades later, [Geoff Huston] in an article on the APNIC blog looks back on these years to try to understand why IPv4 is still a crucial foundation of the modern Internet while IPv6 has barely escaped the need to (futilely) try to tunnel via an IPv4-centric Internet. According to a straight extrapolation by [Geoff], it would take approximately two more decades for IPv6 to truly take over from its predecessor.

Although these days a significant part of the Internet is reachable via IPv6 and IPv6 support comes standard in any modern mainstream operating system, for some reason the ‘IPv4 address pool exhaustion’ apocalypse hasn’t happened (yet). Perhaps ironically, this might as [Geoff] postulates be a consequence of a lack of planning and pushing of IPv6 in the 1990s, with the rise of mobile devices and their use of non-packet-based 3G throwing a massive spanner in the works. These days we are using a contrived combination of TLS Server Name Indication (SNI), DNS and Network Address Translation (NAT) to provide layers upon layers of routing on top of IPv4 within a content-centric Internet (as with e.g. content distribution networks, or CDNs).

While the average person’s Internet connection is likely to have both an IPv4 and IPv6 address assigned to it, there’s a good chance that only the latter is a true Internet IP, while the former is just the address behind the ISP’s CG-NAT (carrier-grade NAT), breaking a significant part of (peer to peer) software and services that relied on being able to traverse an IPv4 Internet via perhaps a firewall forwarding rule. This has now in a way left both the IPv4 and IPv6 sides of the Internet broken in their own special way compared to how they were envisioned to function.

Much of this seems to be due to the changes since the 1990s in how the Internet got used, with IP-based addressing of less importance, while giants like Cloudflare, AWS, etc. have now largely become ‘the Internet’. If this is the path that we’ll stay on, then IPv6 truly may never take over from IPv4, as we will transition to something entirely else. Whether this will be something akin to the pre-WWW ‘internet’ of CompuServe and kin, or something else will be an exciting revelation over the coming years and decades.

Header: Robert.Harker [CC BY-SA 3.0].

As natural as walking is to us tail-less bipedal mammals, the fact of the matter is that it took many evolutionary adaptations to make this act of controlled falling forward work (somewhat) reliably. It’s therefore little wonder that replicating bipedal walking (and running) in robotics is taking a while. Recently a Chinese humanoid robot managed to bump up the maximum running speed to 3.6 m/s (12.96 km/h), during a match between two of Robot Era’s STAR1 humanoid robots in the Gobi desert.

For comparison, the footspeed of humans during a marathon is around 20 km/h and significantly higher with a sprint. These humanoid robots did a 34 minute run, with an interesting difference being that one was equipped with running shoes, which helped it reach these faster speeds. Clearly the same reasons which has led humans to start adopting footwear since humankind’s hunter-gatherer days – including increased grip and traction – also apply to humanoid robots.

That said, it looks like the era when humans can no longer outrun humanoid robots is still a long time off.