It’s been over three years since the last ReactOS release, but today, in honour of the first commit to the project by the oldest, still active contributor, the project released ReactOS 0.4.15. Of course, there’s been a steady stream of nightly releases, so it’s not like the project stalled or anything, but having a proper release is always nice to have.

We are pleased to announce the release of ReactOS 0.4.15! This release offers Plug and Play fixes, audio fixes, memory management fixes, registry healing, improvements to accessories and system tools including Notepad, Paint, RAPPS, the Input Method Editor, and shell improvements.

↫ ReactOS 0.14.5 release announcement

There’s a lot in this one, as the long gap between releases indicates. Thanks to the major changes in the plug and play subsystem of the kernel, ReactOS now supports more third party drivers, and it can now boot from USB and chipsets with EHCI, OHCI, and UHCI controllers. The open source AC’97 driver from the Windows Driver Kit has also been ported to ReactOS to enable sound on VirtualBox and old motherboards. The open source FAT driver from the same WDK has also been ported, which is a massive improvement over the old one. ReactOS can now also make use of custom IMEs, ZIP archive support has been integrated into the shell, and a new default visual style has been chosen.

There’s a lot more in this release, though, and since it was branched over six months ago, there are a lot of improvements from since that time that are not yet part of this release, like a graphical installers, UEFI and SMP support, new NTFS driver, and a ton more. In other words – don’t let the long time between releases fool you; there’s a lot going on in the ReactOS world.

Nvidia releasing its Linux graphics driver as open source is already bearing fruit for alternative operating systems.

As many people already knows, Nvidia published their kernel driver under MIT license: GitHub – NVIDIA/open-gpu-kernel-modules: NVIDIA Linux open GPU kernel module source (I will call it NVRM). This driver is very portable and its platform-independent part can be compiled for Haiku with minor effort (but it need to implement OS-specific binding code to be actually useful). This is very valuable for Haiku because Linux kernel GPU drivers are very hard to port and it heavily depends on Linux kernel internals. Unfortunately userland OpenGL/Vulkan driver source code is not published. But as part of Mesa 3D project, new Vulkan driver “NVK” is being developed and is functional already. Mesa NVK driver is using Nouveau as kernel driver, so it can’t be directly used with NVRM kernel driver. NVK source code provides platform abstraction that allows to implement support of other kernel drivers such as NVRM.

I finally managed to make initial port NVRM kernel driver to Haiku and added initial NVRM API support to Mesa NVK Vulkan driver, so NVRM and NVK can work together. Some simple Vulkan tests are working.

↫ X512 on the Haiku forums

Incredibly impressive, and a huge milestone for the Haiku operating system. It supports any Nvidia GPU from the Turing architecture, which I think means Nvidia RTX 20xx and newer, since they have a required microcontroller older GPUs do not have. Of course, this is an early port and a lot of work remains to be done, but it could lead to huge things for Haiku.

What do SourceHut, GNOME’s GitLab, and KDE’s GitLab have in common, other than all three of them being forges? Well, it turns out all three of them have been dealing with immense amounts of traffic from “AI” scrapers, who are effectively performing DDoS attacks with such ferocity it’s bringing down the infrastructures of these major open source projects. Being open source, and thus publicly accessible, means these scrapers have unlimited access, unlike with proprietary projects.

These “AI” scrapers do not respect robots.txt, and have so many expensive endpoints it’s putting insane amounts of pressure on infrastructure. Of course, they use random user agents from an effectively infinite number of IP addresses. Blocking is a game of whack-a-mole you can’t win, and so the GNOME project is using a rather nuclear option called Anubis now, which aims to block “AI” scrapers with a heavy-handed approach that sometimes blocks real, genuine users as well.

The numbers are insane, as Niccolò Venerandi at Libre News details.

Over Mastodon, one GNOME sysadmin, Bart Piotrowski, kindly shared some numbers to let people fully understand the scope of the problem. According to him, in around two hours and a half they received 81k total requests, and out of those only 3% passed Anubi’s proof of work, hinting at 97% of the traffic being bots – an insane number!

↫ Niccolò Venerandi at Libre News

Fedora is another project dealing with these attacks, with infrastructure sometimes being down for weeks as a result. Inkscape, LWN, Frama Software, Diaspora, and many more – they’re all dealing with the same problem: the vast majority of the traffic to their websites and infrastructure now comes from attacks by “AI” scrapers. Sadly, there’s doesn’t seem to be a reliable way to defend against these attacks just yet, so sysadmins and webmasters are wasting a ton of time, money, and resources fending off the hungry “AI” hordes.

These “AI” companies are raking in billions and billions of dollars from investors and governments the world over, trying to build dead-end text generators while sucking up huge amounts of data and wasting massive amounts of resources from, in this case, open source projects. If no other solutions can be found, the end game here could be that open source projects will start to make their bug reporting tools and code repositories much harder and potentially even impossible to access without jumping through a massive amount of hoops.

Everything about this “AI” bubble is gross, and I can’t wait for this bubble to pop so a semblance of sanity can return to the technology world. Until the next hype train rolls into the station, of course.

As is tradition.

There’s no escaping Rust, and the language is leaving its mark everywhere. This time around, Chrome has replaced its use of FreeType with Skrifa, a Rust-based replacement.

Skrifa is written in Rust, and created as a replacement for FreeType to make font processing in Chrome secure for all our users. Skifra takes advantage of Rust’s memory safety, and lets us iterate faster on font technology improvements in Chrome. Moving from FreeType to Skrifa allows us to be both agile and fearless when making changes to our font code. We now spend far less time fixing security bugs, resulting in faster updates, and better code quality.

↫ Dominik Röttsches, Rod Sheeter, and Chad Brokaw

The move to Skrifa is already complete, and it’s being used now by Chrome users on Linux, Android, and ChromeOS, and as a fallback for users on Windows and macOS. The reasons for this change are the same as they always are for replacing existing tools with new tools written in Rust: security. FreeType is a security risk for Chrome, and by replacing it with something written in a memory-safe language like Rust, Google was able to eliminate a whole slew of types of security issues.

To ensure rendering correctness, Google performed a ton of pixel comparison tests to compare FreeType output to Skrifa output. On top of that, Google is continuously running similar tests to ensure no quality degradation sneaks into Skrifa as time progresses.

Whether anyone likes Rust or not, the reality of the matter is that using Rust provides tangible benefits that reduce cost and lower security risks, and as such, its use will keep increasing, and tried and true tools will continue to be replaced by Rust counterparts.

One of the two major open source desktop environments, GNOME, just released version 48, and it’s got some very big and welcome improvements. First and foremost there’s dynamic triple-buffering, a feature that took over five years of extensive testing to get ready. It will improve the smoothness and fluidity of animations and other movements on the screen, as it did for KDE when it landed there in the middle of last year.

GNOME 48 also brings notification stacking, combining notifications from the same source, improvements to the new default image viewer such as image editing features, a number of digital well-being options, as well as the introduction of a new, basic audio player designed explicitly for quickly playing individual audio files. There’s also a few changes to GNOME’s text editor, and following in KDE’s recent footsteps, GNOME 48 also brings HDR support.

Another major change are the new default fonts. Finally, Cantarell is gone, replaced by slightly modified versions of Inter and Iosevka. Considering I absolutely adore Inter and installing and setting it as my main font is literally the first thing I do on any system that allows me to, I’m fully behind this change. Inter is exceptional in that it renders great in both high and low DPI environments, and its readability is outstanding.

GNOME 48 will make its way to your distribution’s repositories soon enough.

Oracle, the company owned by a guy who purchased a huge chunk of the Kingdom of Hawaii from the Americans, has released Java 24. I’ll be honest and upfront: I just don’t care very much at all about this, as the only interaction I’ve had with Java over the past, I don’t know, 15 years or so, is either because of Minecraft, or because of my obsession with ancient UNIX workstations where Java programs pop up in the weirdest of places. I know Java is massive and used everywhere, but going through the list of changes and improvements does not spark any joy in me at all, and just makes me want to stick my pinky in an electrical socket to make something interesting happen.

If you work with Java, you know all of this stuff already anyway, as you’ve been excitedly trying to impress Nick from accounting with your knowledge of Flexible Constructor Bodies and Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanisms because he’s just so dreamy and you desperately want to ask him out for a hot cup of coffee, but you’re not sure if he’s married or has a boy or girlfriend so you’re just kind of scoping things out a bit too excitedly and now you’re worried you might be coming off as too desperate for his attention.

Anyway, that’s how offices work, right? I’ve never worked for anyone but myself and office settings induce a deep sense of existential dread in me, so my knowledge of office work, and Java if we’re honest, may be based a bit too much on ’90s sitcoms and dramas. Whatever, Java 24 is here. Do a happy dance.

It’s barely been two months after the announcement that Pebble would return with new watches, and they’re already here – well, sort of. Pebble has announced two new watches for preorder, the Core 2 Duo and the Core Time 2. The former is effectively a Pebble 2, upgraded with new internals, while the Core Time 2 is very similar, but comes with a colour e-ink display and a metal case. They’re up for preorder now at $149 and $225, respectively, with the Core 2 Duo shipping in July, and the Core Time 2 shipping in December.

Alongside this unveil, Eric Migicovsky, the creator of Pebble, also published a blog post detailing the trouble Pebble is and will have with making smartwatches for iOS users. Apple effectively makes it impossible for third parties to make a proper smartwatch for iOS, since access to basic functionality you’d come to expect from such a device are locked by Apple, reserved only for its own Apple Watch. As such, Migicovsky makes it explicitly clear that iOS users who want to buy one of these new Pebbles will are going to have a very degraded experience compared to Android users.

Not only will Android users with Pebble have access to a ton more functionality, any Pebble features that could exist for both Android and iOS users will always come to Android first, and possibly iOS later. In fact, Migicovksy goes as far as suggesting that if you want a Pebble, you should buy an Android phone.

I don’t want to see any tweets or blog posts or complaints or whatever later on about this. I’m publishing this now so you can make an informed decision about whether to buy a new watch or not. If you’re worried about this, the easiest solution is to buy an Android phone.

↫ Eric Migicovsky

I have to hand it to Migicovksy – I love the openness about this, and the fact he’s making this explicitly clear to any prospective buyers. There’s no sugarcoating or PR speak to try and please Tim Cook – he’s putting the blame squarely where it belongs: on Apple. It’s kind of unreal to see such directness about a new product, but as a Dutch person, it feels quite natural. We need more of this style of communication in the technology world, as it makes it much clearer that you’re getting – and not getting.

I do hope that Pebble’s Android support functions without the need for Google Play Services or other proprietary Google code, since it would be great to have a proper, open source smartwatch fully supported by de-Googled Android.

A few months after 0.27.0 was released, we’ve got a small update for Enlightenment today, version 0.27.1. It’s a short list of bugfixes, and one tiny new feature: you can now use the scroll wheel to change the volume when your cursor is hovering over the mixer controls.

That’s it. That’s the release.

Settle down children, it’s time for another great article by Cameron Kaiser. This time, they’re going to tell us about the DEC Professional 380 running PRO/VENIX.

The Pro 380 upgraded to the beefier J-11 (“Jaws”) CPU from the PDP-11/73, running two to three times faster than the 325 and 350. It had faster RAM and came with more of it, and boasted quicker graphics with double the vertical resolution built right into the logic board. The 380 still has its faults, notably being two-thirds the speed of the 11/73 and having no cache, plus all of the 325/350’s incompatibilities. Taken on its merits, though, it’s a tank of a machine, a reasonably powerful workstation, and the most practical PDP-adjacent thing you can actually slap on a (large) desk.

This particular unit is one of the few artifacts I have left from a massive DEC haul almost twelve years ago. It runs PRO/VENIX, the only official DEC Unix option for the Pros, but in its less common final release (we’ll talk about versions of Venix). I don’t trust the clanky ST-506 hard drive anymore, so today we’ll convert it to solid state and double its base RAM to make it even more professional, and then play around in VENIX some for a taste of old-school classic Unix — after, of course, some history.

↫ Cameron Kaiser

Detailed, interesting, fascinating, and full of photos as always.

In 1994, a single Macintosh Performa model, the 550, came from the factory with a dedicated, hidden recovery partition that contained a System 7 system folder and a small application that would be set as bootable if the main operating system failed to boot. This application would then run, allowing you to recover your Mac using the system folder inside the recovery partition. This feature was apparently so obscure, few people knew it existed, and nobody had access to the original contents of the recovery partition anymore.

It took Doug Brown a lot of searching to find a copy of this recovery partition. The issue is that nobody really knows how this partition is populated with the recovery data, so the only way to explore its contents was to somehow find a Performa 550 hard drive with a specific version of Mac OS that had never been reformatted after leaving the factory.

The thing is, this whole functionality was super obscure. It’s understandable that people weren’t familiar with it. Apple publicly stated it was only included with this one specific Performa model. Their own documentation also said that it would be lost if you reformatted the hard drive. It was hiding in the background, so nobody really knew it was there, let alone thought about saving it. Also, I can say that the first thing a lot of people do when they obtain a classic computer is erase it in order to restore it to the factory state. Little did anyone know, if they reformatted the hard drive on a Performa 550, they could have been wiping out rare data that hadn’t been preserved!

↫ Doug Brown

Brown found a copy, and managed to get the whole original functionality working again. It’s a fairly basic way of doing this, but we shouldn’t forget we’re talking 1994 here, and I don’t think any other operating system at the time had the ability to recover from an unbootable state like this. Like Brown, I wonder why it was abandoned so quickly. Perhaps Apple was unwilling to sacrifice the hard drive space?

Groundbreaking or not, it’s still great to have this recovered and preserved for the ages.

It’s been a while, but there’s a new release of Ironclad, the formally verified, hard real-time capable kernel written in SPARK and Ada. Aside from the usual bugfixes, this release moves Ironclad from multiboot to Limine, adds x86_64 ACPI support for poweroff and reboot, improvements to PTY support, the VFS layer, and much more.

The easiest way to try out Ironclad is to download Gloire, a distribution that uses Ironclad and the GNU tools. It can be installed in both a virtual machine and on real hardware.

Mozilla’s actions have been rubbing many Firefox fans the wrong way as of late, and inspiring them to look for alternatives. There are many choices for users who are looking for a browser that isn’t part of the Chrome monoculture but is full-featured and suitable for day-to-day use. For those who are willing to stay in the Firefox “family” there are a number of good options that have taken vastly different approaches. This includes GNU IceCat, Floorp, LibreWolf, and Zen.

↫ Joe Brockmeier

It’s a tough situation, as we’re all aware. We don’t want the Chrome monoculture to get any worse, but with Mozilla’s ever-increasing number of dubious decisions some people have been warning about for years, it’s only natural for people to look elsewhere. Once you decide to drop Firefox, there’s really nowhere else to go but Chrome and Chrome skins, or the various Firefox skins. As an aside, I really don’t think these browsers should be called Firefox “forks”; all they really do is change some default settings, add in an extension or two, and make some small UI tweaks. They may qualify as forks in a technical sense, but I think that overstates the differentiation they offer.

Late last year, I tried my best to switch to KDE’s Falkon web browser, but after a few months the issues, niggles, and shortcomings just started to get under my skin. I switched back to Firefox for a little while, contemplating where to go from there. Recently, I decided to hop onto the Firefox skin train just to get rid of some of the Mozilla telemetry and useless ‘features’ they’ve been adding to Firefox, and after some careful consideration I decided to go with Waterfox.

Waterfox strikes a nice balance between the strict choices of LibreWolf – which most users of LibreWolf seem to undo, if my timeline is anything to go by – and the choices Mozilla itself makes. On top of that, Waterfox enables a few very nice KDE integrations Firefox itself and the other Firefox skins don’t have, making it a perfect choice for KDE users. Sadly, Waterfox isn’t packaged for most Linux distributions, so you’ll have to resort to a third-party packager.

In the end, none of the Firefox skins really address the core problem, as they’re all still just Firefox. The problem with Firefox is Mozilla, and no amount of skins is going to change that.

Ted Unangst published dude, where are your syscalls? on flak yesterday, with a neat demonstration of OpenBSD’s pinsyscall security feature, whereby only pre-registered addresses are allowed to make system calls. Whether it strengthens or weakens security is up for debate, but regardless it’s an interesting, low-level programming challenge. The original demo is fragile for multiple reasons, and requires manually locating and entering addresses for each build. In this article I show how to fix it. To prove that it’s robust, I ported an entire, real application to use raw system calls on OpenBSD.

↫ Chris Wellons

Some light reading for the weekend.

Elon Musk’s Tesla is waving a red flag, warning that Donald Trump’s trade war risks dooming US electric vehicle makers, triggering job losses, and hurting the economy.

In an unsigned letter to the US Trade Representative (USTR), Tesla cautioned that Trump’s tariffs could increase costs of manufacturing EVs in the US and forecast that any retaliatory tariffs from other nations could spike costs of exports.

↫ Ashley Belanger at Ars Technica

Back in 2020, scientists at the University of Twente, The Netherlands, created the smallest string instrument that can produce tones audible by human ears when amplified. Its strings were a mere micrometer thin, or one millionth of a meter, and about half to one millimeter long. Using a system of tiny weights and combs producing tiny vibrations, tones can be created.

And yet, this tiny violin still isn’t small enough for Tesla.