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.

When I checked where Windows Defender had actually detected the threat, it was in the Fan Control app I use to intelligently cool my PC. Windows Defender had broken it, and that’s why my fans were running amok. For others, the threat was detected in Razer Synapse, SteelSeries Engine, OpenRGB, Libre Hardware Monitor, CapFrameX, MSI Afterburner, OmenMon, FanCtrl, ZenTimings, and Panorama9, among many others.

“As of now, all third-party/open-source hardware monitoring softwares are screwed,” Fan Control developer Rémi Mercier tells me.

↫ Sean Hollister at The Verge

Anyone reading OSNews can probably solve this puzzle. Many fan control and hardware monitoring applications for Windows make use of the same open source driver: WinRing0. Uniquely, this kernel-level driver is signed, since it’s from back in the days when developers could self-sign these sorts of drivers, but the signed version has a known vulnerability that’s quite dangerous considering it’s a kernel-level driver. The vulnerability has been fixed, but signing this new version – and keeping it signed – is a big ordeal and quite expensive, since these days, drivers have to be signed by Microsoft.

And it just so happens that Windows Defender has started marking this driver, and thus any tool that uses it, as dangerous, sending it to quarantine. The result is failing hardware monitoring and fan control applications for quite a few Windows users. Some companies have invested in developing their own closed-source alternatives, but they’re not sharing them. Luckily, Windows OEM iBuyPower says it’s trying to get the patched version of WinRing0 signed, and if that happens, they will share it back with the community. Classy.

For now, though, hardware monitoring and fan control on Windows might be a bit of an ordeal.

One of the biggest behind-the-scenes changes in the upcoming Plasma 6.4 release is the split of kwin_x11 and kwin_wayland codebases. With this blog post, I would like to delve in what led us to making such a decision and what it means for the future of kwin_x11.

↫ Vlad Zahorodnii

For the most part, this change won’t mean much for users of KWin on either Wayland or X11, at least for now. At least for the remainder of the Plasma 6.x life cycle, kwin_x11 will be maintained, and despite the split, you can continue to have both kwin_x11 and kwin_wayland installed and use them interchangeably. Don’t expect any new features, though; kwin_x11 will get the usual bug fixes, some backports, and they’ll make sure it keeps working with any new KDE frameworks introduced during the 6.x cycle, but that’s all you’re going to get if you’re using KDE on X11.

There’s one area where this split might cause problems, though, and that’s if you’re using a particular type of KWin extension. While KWin extensions written in JavaScript and QML are backend agnostic and can be used without issues on both variants of KWin, extensions written in C++ are not. These extensions need to be coded specifically for either kwin_x11 or kwin_wayland, and with Wayland being the default for KDE, this may mean some of these extensions will leave X11 users behind to reduce the maintenance burden.

It seems that very few people are still using KDE on X11, and kwin_x11 doesn’t receive much testing anymore, so it makes sense to start preparations for the inevitable deprecation. While I think the time of X11 on Linux has come and gone, it’s unclear what this will mean for KDE on the BSDs. While Wayland is available on all of the BSDs in varying states of maturity, I honestly don’t know if they’re ready for a Wayland-only KDE at this point in time.