Back when Java was still a new programming language, Sun had the idea of building a computer specifically designed for Java, unique processor running byte-code as its native machine code and all. This whole endeavour proved to be more complicated than Sun had hoped, and as such, they eventually abandoned the idea of a Java processor in favour of plain SPARC. When the JavaStation shipped, it was a regular SPARC workstation without a hard drive, running something called JavaOS from flash memory.

Since JavaOS is, of course, long gone, what can you do with JavaStation today? Well, you apparently can run NetBSD on it, but it’s quite an ordeal. The JavaStation needs to boot from the network using a combination of RARP, NFS, and more, and surprisingly, this entire setup, including the computer acting as the ‘server’ for the JavaStation, is well-documented and supported by NetBSD. Once you’ve gone through all the steps, you’ll end up with a JavaStation running the latest release of NetBSD, which is pretty cool.

Obviously there is still a lot to do; as you can see postfix isn’t happy, and the swapfile security needs tightening up for a start. But we do now have a functional NetBSD system running on a vintage network computer!

↫ Old Fart’s Almanac

NetBSD’s continued support for the most arcane of hardware will never cease to amaze me.

Now that we have examined the vulnerability that enables arbitrary microcode patches to be installed on all (un-patched) Zen 1 through Zen 4 CPUs, let’s discuss how you can use and expand our tools to author your own patches. We have been working on developing a collection of tools combined into a single project we’re calling zentool. The long-term goal is to provide a suite of capabilities similar to binutils, but targeting AMD microcode instead of CPU machine code. You can find the project source code here along with documentation on how to use the tools.

↫ Google’s Bug Hunters website

I just read a whole bunch of words, but I barely understand what’s going on. The general, very simplified gist is that the researchers discovered a way for an attacker with local administrator privileges to load arbitrary microcode onto AMD Zen 1-4 processors.

How much faster is fastDOOM than regular Doom on a decked-out 486 from 1993?

30% faster without cutting any features! On a demanding map like doom2’s demo1, the gain is even higher, from 16.8 fps to 24.9 fps. That is 48% faster!

I did not suspect that DOOM had left that much on the table. Obviously shipping within one year left little time to optimize. I had to understand how this magic trick happened.

↫ Fabien Sanglard

What follows is an incredibly detailed exploration of why, exactly, fastDOOM is so much faster, by building and benchmarking every version, and even going git commit by git commit to really understand how fastDOOM’s developer, Victor “Viti95” Nieto, achieved these impressive results.

These months are coming and going way too fast, for a whole variety of reasons, so we’ve got another month of improvements for Redox, the operating system written in Rust. I February, January’s work on dynamic linking continued, adding support for it to the recipes for Cargo, LLVM, Rust, libssh2, OpenSSL, zlib, COSMIC Terminal, NetSurf, libpng, bzip2, DevilutionX, and LuaJIT, as well as to the project’s Rust and OpenSSL forks. Relibc also saw its usual slew of improvements, as did the build system and documentation.

The Intel HD Audio driver initialization has been fixed, and PS/2 touchpad support has been fixed as well – you’d be surprised to find out how many laptops use PS/2 internally, so this is an important function to maintain. And as always, there’s a whole slew of smaller changes and fixes, too.

Bjarne Stroustrup, creator of C++, has issued a call for the C++ community to defend the programming language, which has been shunned by cybersecurity agencies and technical experts in recent years for its memory safety shortcomings.

C and C++ are built around manual memory management, which can result in memory safety errors, such as out of bounds reads and writes, though both languages can be written and combined with tools and libraries to help minimize that risk. These sorts of bugs, when they do crop up, represent the majority of vulnerabilities in large codebases.

↫ Thomas Claburn at The Register

I mean, it makes sense to me that those responsible for new code to use programming languages that more or less remove the most common class of vulnerabilities. With memory-safe languages like Rust having been around for quite a while now, it’s almost wilful negligence to write new code where security is a priority in anything but such memory-safe languages. Of course, this doesn’t mean you delete any and all existing code – it just means you really need to start writing any new code in safer languages. After all, research shows that even when you only write new code in memory-safe languages, the reduction in vulnerabilities is massive.

This reminds me a lot of those old videos of people responding to then-new laws mandating the use of seat belts in cars. A lot of people didn’t want to put them on, saying things to the tune of “I don’t need one because I’m a good driver”. Even if you are a good driver – which statistically you aren’t – everyone else on the road isn’t. When we see those old videos now, they feel quaint, archaic, and dumb – of course you wear a seat belt, you’d be an irresponsible idiot not to! – but only a few decades ago, those arguments made perfect sense to people.

It won’t be long before the same will apply to people doggedly refusing to use memory-safe languages or libraries/extensions that introduce such safety to existing languages, and Bjarne Stroustrup seems to understand that. Are you really smarter than Bjarne Stroustrup?

About two weeks ago, there was a bit of confusion about the system requirements for Windows 11 24H2, because Intel’s 8th Gen, 9th Gen, and 10th Gen processors had disappeared from the list of supported hardware. This seemed rather drastic, even by Windows 11 standards. I skipped posting about it on OSNews because I kind of assumed it must’ve been an error instead of actual policy, and it turns out that’s indeed the case.

A page update made on February 13, 2025 did not reflect accurate offerings. It has since been updated, including the addition of Intel processor models 8th, 9th, and 10th generation Intel CPUs, and the reclassification for select Intel processor models to support Windows 11.

↫ Windows 11 version 24H2 supported Intel processors

Good news for people still stuck on the Windows 11 train.

For the past several years my desktop has also had a disk dedicated to maintaining a Windows install. I’d prefer to use the space in my PC case for disks for Linux. Since I already run a home NAS, and my Windows usage is infrequent, I wondered if I could offload the Windows install to my NAS instead. This lead me down the course of netbooting Windows 11 and writing up these notes on how to do a simplified “modern” version.

↫ Terin Stock

The setup Terin Stock ended up with is rather ingenious, to be honest. They had to create not just an environment in which netbooting through iXPE using iSCSI, but also a customised Windows PE ISO that included the necessary drivers to make installing Windows onto a iSCSI-connected remote drive possible in the first place, because they’re not included in the Windows installation ISO. This isn’t exactly a standard setup, of course, so there were a few roadblocks to clear before getting there.

They now have Windows 11 booting from a drive in their NAS, and it seems it doesn’t affect gaming – the reason why they did this in the first place is an online game that hard-requires Windows – at all. Installing the game through Steam took a bit longer, sure, but regular gameplay seems unaffected, and there’s no saturation on the network or disk. You’d think this would be wholly too slow to be suitable for gaming, but I guess at least some games handle this just fine. My uneducated guess is that more demanding games that rely on a ton of disk activity to load textures and so on will have a much more difficult time running.

In any event, this intrigues me, and I’m kind of curious to try and set this up myself, if only for the memes. It looks like fun.

The hits just keep on coming. Mozilla not only changed its Privacy Notice and introduced a Terms of Use for Firefox for the first time with some pretty onerous terms, they also removed a rather specific question and answer pair from their page with frequently asked questions about Firefox, as discovered by David Gerard. The following question and answer were removed:

Does Firefox sell your personal data?

Nope. Never have, never will. And we protect you from many of the advertisers who do. Firefox products are designed to protect your privacy. That’s a promise.

↫ David Gerard detailing what has been removed

This promise is now gone from the website, a removal which tells you all you need to know about what Mozilla has in mind. Combine it with the much broadened data collection and buying and claiming to be an online advertising company, and what I have been predicting and warning everyone about has come to pass: Firefox has become a mere tool to collect user data, user data to be sold by Mozilla for the purposes of advertising.

For years I’ve been warning about this inevitable outcome, and for just as many years people told me I was overreacting, that it wouldn’t happen, that I was crazy. The problem is especially dire for the desktop Linux world, who soon might not have a browser they can safely include in their ISOs and base installations. A desktop Linux installation with Chromium where you have to manually drag and drop extensions to install them, and set up a Google API key just to get browser sync, isn’t exactly a great experience.

At this point I have no idea where to go. Chrome and its various skins are a no-go, obviously, and relatively soft forks like LibreWolf are still dependent on Firefox and Mozilla. Alternatives like Falkon also use the Chromium engine deep down, and have their own set of issues and lack of manpower to deal with. Apple users are somewhat lucky to have the WebKit-based Safari to work with, but I’d rather publish my personal data in The New York Times than trust Apple and Tim Cook.

We’re right back where we started. Lovely.

I installed Void on my current laptop on the 10th of December 2021, and there has never been any reinstall.

The distro is absurdly stable. It’s a rolling release, and yet, the worst update I had in those years was one time, GTK 4 apps took a little longer to open on GNOME. Which was reverted after a few hours. Not only that, I sometimes spent months without any update, and yet, whenever I did update, absolutely nothing went wrong. Granted, I pretty much only did full upgrades, and never partial upgrades, which generally help a lot. Still.

↫ Sarah Mathey

Void is love, Void is life. It’s such an absurdly good distribution, and if it wasn’t for the fact that I prefer Fedora KDE by a hair, I’d be using Void on all of my machines. The only reason I’m not is that I would set up Void very close to what I get from Fedora KDE out of the box anyway, so my laziness gets the better of me there. I used to run Void on my POWER9 hardware, but that architecture is no longer supported by Void.

If you’re looking for a Linux distribution free of systemd, there’s little out there that can equal or top Void, and even if you don’t care much about init systems, Void still has a lot to offer. The documentation is decent, its package manager is a joy to use, the repositories are loaded and up-to-date, and it strikes a great balance between building an entire Linux system from scratch on the one hand, and complete desktop distributions like Fedora on the other. The best way I can describe it is that Void feels like the most BSD-y of Linux distributions.

Void is my fallback, in case Fedora for whatever reason slips up and dies. IBM, Red Hat, “AI” – there’s a lot of pits Fedora can fall into, after all.

Windows was an early adopter of Unicode, and its file APIs use UTF‑16 internally since Windows 2000-used to be UCS-2 in Windows 95 era, when Unicode standard was only a draft on paper, but that’s another topic. Using UTF-16 means that filenames, text strings, and other data are stored as sequences of 16‑bit units. For Windows, a properly formed surrogate pair is perfectly acceptable. However, issues arise when string manipulation produces isolated or malformed surrogates. Such errors can lead to unreadable filenames and display glitches—even though the operating system itself can execute files correctly. But we can create them deliberately as well, which we can see below.

↫ Zafer Balkan

What a wild ride and an odd corner case. I wonder what kind of odd and fun shenanigans this could be used for.

Remember about half a year ago, when the PowerPC versions of Windows NT were made to run on certain models of PowerPC Macs? The same developer responsible for that work, Rairii, took all of this to the next level, and it’s now possible to run the PowerPC version of Windows NT on the GameCube, Wii, Wii U, and a few related development boards.

NT 3.51 RTM and higher. NT 3.51 betas (build 944 and below) will need kernel patches to run due to processor detection bugs. NT 3.5 will never be compatible, as it only supports PowerPC 601. (The additional suspend/hibernation features in NT 3.51 PMZ could be made compatible in theory but in practise would require all of the additional drivers for that to be reimplemented.)

↫ Windows NT for GameCube/Wii GitHub page

As you may have expected, there are some issues, such as instability and random reboots, USB hotplugging doesn’t work, and some other, smaller issues, but none of that takes away from just how awesome and impressive this really is. There’s framebuffer support for the Flipper GPU, full support for the controllers ports and a ton of compatible controllers and related input devices, including support for the N64 mouse and keyboard, although said support is untested.

The GameCube and Wii (U) are PowerPC computers, after all, running IBM processors, so it shouldn’t be surprising that running Windows NT on them is possible. Still, it’s an impressive feat of engineering to get this to work at all, let alone in as complete a state as it appears to be.

I’m sure we can all have a calm, rational discussion about this, so here it goes: zlib-rs, the Rust re-implementation of the zlib library, is now faster than its C counterparts in both decompression and compression.

We’ve released version 0.4.2 of zlib-rs, featuring a number of substantial performance improvements. We are now (to our knowledge) the fastest api-compatible zlib implementation for decompression, and beat the competition in the most important compression cases too.

↫ Folkert de Vries

As someone who isn’t a programmer, looking at all the controversies and fallout around anything related to Rust is both fascinating and worrying. Fascinating because Rust clearly brings a whole slew of improvements over established and older languages, and worrying because the backlash from the establishment has been wildly irrational and bordering on the childish, complete with tamper tantrums and the taking of balls and going home. It shouldn’t surprise me that people get attached to programming languages the same way people get attached to operating systems, but surprisingly, it still does.

If Rust not only provides certain valuable benefits like memory safety, but can also be used to create implementations that are faster than those created in, say, C, it’s really only going to be a matter of time before it simply becomes an untenable position to block Rust from, say, the Linux kernel. Progress has a tendency to find a way, especially the more substantial the benefits get, and as studies show, even only writing new code in memory-safe languages provides substantial benefits. In other words, more and more projects will simply switch over to Rust for new code where it makes sense, whether Rust haters want it or not.

There will be enough non-Rust code to write and maintain, though, so I don’t think people will be out of a job any time soon because they refuse to learn Rust, but to me as an outsider, the Rust hate seems to grow more and more irrational by the day.

The Wayland color-management protocol extension has landed on Feb 13th, 2025, in upstream wayland-protocols repository in the staging directory. It was released with wayland-protocols 1.41. The extension enables proper interactions between traditional (sRGB), Wide Color Gamut (WCG), and High Dynamic Range (HDR) image sources and displays once implemented in Wayland compositors and used in applications.

[…]

Of course, a protocol is just a language. Two participants need to speak the same language for the language to be of any use: Wayland compositors and a component on the application side (e.g., a toolkit library). Major efforts have been going on in various projects to prove and take advantage of the protocol, including KWin, Mutter, Weston, wlroots, GStreamer, GTK, Qt, SDL, Mesa, and mpv. Support in Mesa means that applications will be able to render and display in HDR by using the relevant EGL and Vulkan features.

↫ Pekka Paalanen

Colour management has been an important missing piece of the Wayland puzzle, so it’s good to see this finally released and added to Wayland as a new protocol after so many years of work. It’s important to note that the work done so far focuses almost entirely on the entertainment side of things, like watching video or playing games. The other important side, professional colour management for things like photo editing or desktop publishing, is still missing, with the major holdup being measuring physical monitor response (measuring a reference image displayed on a monitor with a hardware device).

I’ve saved the worst for last. For some reason, Xcode phones home to appstoreconnect.apple.com every time I open an Xcode project. This also appears to be unnecessary, and I experience no problems after denying the connections in Little Snitch, so I do! I assume that the connections send identifying information about the Xcode project to Apple, otherwise why even make the connections when opening a project? And all of these connections from Xcode, to every domain, require login to your Apple Developer account, so Apple is definitely receiving identifying information about you in any case.

In effect, Xcode is a developer analytics collection mechanism, whether you like it or not, which I don’t.

↫ Jeff Johnson

If, at this point in time, you’re still surprised Apple doesn’t practice what it preaches, the fault lies pretty much entirely with you.

Anyway, it seems Xcode phones home to Apple quite a bit, which I doubt is all that unique in the world of commercial development environments. I honestly don’t think Apple itself doing anything particularly nefarious with this data, but the fact it’s collecting it in the first place should still make you think twice about using Xcode, especially if you’re developing anything even remotely sensitive. What should really worry you is the fact Tim Cook and Apple are close allies of Trump and his regime.

Xcode is required for iOS/iPadOS/etc. development, because the App Store requires applications be built and submitted with it. As such, every iOS developer is sending substantial amounts of data to Apple during development, which should be especially concerning for people outside of the US and people who aren’t straight white males; using Xcode requires an Apple Account, so Apple knows quite a bit about who is using it. With the breakdown of the rule of law in the US, all of this data is basically freely accessible to US authorities, and we’ve seen by now that people like self-styled genius Elon Musk don’t worry too much about pesky things like the rule of law.

If Musk wants this data, Apple will hand it over.

If you’re an Apple developer, you should stop and think every time you open Xcode. You’re sending your data straight to a hostile entity. If you’re claiming to use Apple products because of Apple’s privacy “promises”, Xcode’s data collection should be a huge worry for you.