This week’s This Week in GNOME mentions that Blueprint will become part of GNOME. Blueprint is now part of the GNOME Nightly SDK and is expected to be part of the GNOME 49 SDK. This means, apps relying on Blueprint won’t have to install it manually anymore. Blueprint is an alternative to defining GTK/Libadwaita user interface via .ui XML-files (GTK Builder files). The goal of blueprint is to provide UI definitions that require less boilerplate than XML and are easier to learn. Blueprint also provides a language server for IDE integration. ↫ Sophie Herold Quite a few applications already make use of Blueprint, and even some Core GNOME applications use it, so it seems logical to make it part of the default GNOME installation.

OSle is an incredibly small operating system, coming in at only 510 bytes, so it fits entirely into a boot sector. It runs in real-mode, and is written in assembly. Despite the small size, it has a shell, a read and write file system, process management, and more. It even has its own tiny SDK and some pre-built programs. The code’s available under the MIT license.

Back in the late ’90s and early 2000s, if you installed a comprehensive office suite on Windows, such as Microsoft’s own Office or something like WordPerfect Office or IBM Lotus SmartSuite, it would often come with a little icon in the system tray or a floating toolbar to ensure the applications were preloaded upon logging into Windows. The idea was that this preloading would ensure that the applications would start faster. It’s 2025, and Microsoft is bring it back. In a message in the Microsoft 365 Message Center Archive, which is a real thing I didn’t make up, the company announced a new Startup Boost task that will preload Office applications on Windows to reduce loading times for the individual Office applications. We are introducing a new Startup Boost task from the Microsoft Office installer to optimize performance and load-time of experiences within Office applications. After the system performs the task, the app remains in a paused state until the app launches and the sequence resumes, or the system removes the app from memory to reclaim resources. The system can perform this task for an app after a device reboot and periodically as system conditions allow. ↫ MC1041470 – New Startup Boost task from Microsoft Office installer for Office applications This new task will automatically be added to the Task Scheduler, but only on PCs with 8GB of RAM or more and at least 5GB of available disk space. The task will run 10 minutes after logging into Windows, will be disabled if the Energy Saves feature is enabled, and will be removed if you haven’t used Office in a while. The initial rollout of this task will take place in May, and will cover Word only for now. The task can be disabled manually through Task Scheduler or in Word’s settings. Since this is Microsoft, every time Office is updated, the task will be re-enabled, which means that users who disable the feature will have to disable it again after each update. This particular behaviour can be disabled using Group Policy. Yes, the sound you’re hearing are all the “AI” text generators whirring into motion as they barf SEO spam onto the web about how to disable this feature to speed up your computer. I’m honestly rather curious who this is for. I have never found the current crop of Office applications to start up particularly slowly, but perhaps corporate PCs are so full of corpo-junkware they become slow again?

It has been well over two years since the last release of DragonFlyBSD, version 6.4.0, and today the project pushed out a small update, DragonFlyBSD 6.4.1. It fixes a few small, longstanding issues, but as the version number suggests, don’t expect any groundbreaking changes here. The legacy IDE/NATA driver had a memory leak fixed, the ca_root_nss package has been updated to support newer Let’s Encrypt certificates, the package update command will no longer delete an important configuration file that rendered the command unusable, and more small fixes like that. Existing users can update the usual way.

If RISC-V ever manages to take off, this is going to be an important tool in RISC-V users’ toolbox: felix86 is an x86-64 userspace emulator for RISC-V. felix86 emulates an x86-64 CPU running in userspace, which is to say it is not a virtual machine like VMware, rather it directly translates the instructions of an application and mostly uses the host Linux kernel to handle syscalls. Currently, translation happens during execution time, also known as just-in-time (JIT) recompilation. The JIT recompiler in felix86 is focused on fast compilation speed and performs minimal optimizations. It utilizes extensions found on the host system such as the vector extension for SIMD operations, or the B extension for emulating bit manipulation extensions like BMI. The only mandatory extensions for felix86 are G, which every RISC-V general purpose computer should already have, and v1.0 of the standard vector extension. ↫ felix86 website The project is still in early development, but a number of popular games already work, which is quite impressive. The code’s on GitHub under the MIT license.

Way back in 2021, in the Epic v. Apple court case, judge US District Judge Yvonne Gonzalez Rogers ordered Apple to allow third-party developers to tell users how to make payments inside iOS applications without going through Apple’s App Store. As we have come to expect from Apple, the company maliciously complied, lowering the commission on purchases outside of its ecosystem from 30% to 27%, while also adding a whole bunch of hoops and hurdles, like scare screens with doom-and-gloom language to, well, scare consumers into staying within Apple’s ecosystem for in-app payments. Well, it turns out Judge Yvonne Gonzalez Rogers is furious, giving Apple, Tim Cook, and its other executives what can only be described as a beatdown – even highlighting how one of Apple’s executives, under orders from Tim Cook, lied under oath several times. Gonzalez is referring this to the District Attorney for Northern California “to investigate whether criminal contempt proceedings are appropriate.” In stark contrast to Apple’s initial in-court testimony, contemporaneous business documents reveal that Apple knew exactly what it was doing and at every turn chose the most anticompetitive option. To hide the truth, Vice-President of Finance, Alex Roman, outright lied under oath. Internally, Phillip Schiller had advocated that Apple comply with the Injunction, but Tim Cook ignored Schiller and instead allowed Chief Financial Officer Luca Maestri and his finance team to convince him otherwise. Cook chose poorly. The real evidence, detailed herein, more than meets the clear and convincing standard to find a violation. The Court refers the matter to the United States Attorney for the Northern District of California to investigate whether criminal contempt proceedings are appropriate. ↫ US District Judge Judge Yvonne Gonzalez Rogers Gonzalez’ entire ruling is scathing, seething with rage, and will probably do more reputational damage to Apple, Tim Cook, and his executive team than any bendgate or antennagate could ever do. Judge Gonzalez: This is an injunction, not a negotiation. There are no do-overs once a party willfully disregards a court order. Time is of the essence. The Court will not tolerate further delays. As previously ordered, Apple will not impede competition. The Court enjoins Apple from implementing its new anticompetitive acts to avoid compliance with the Injunction. Effective immediately Apple will no longer impede developers’ ability to communicate with users nor will they levy or impose a new commission on off-app purchases. Apple willfully chose not to comply with this Court’s Injunction. It did so with the express intent to create new anticompetitive barriers which would, by design and in effect, maintain a valued revenue stream; a revenue stream previously found to be anticompetitive. That it thought this Court would tolerate such insubordination was a gross miscalculation. As always, the cover-up made it worse. For this Court, there is no second bite at the apple. ↫ US District Judge Judge Yvonne Gonzalez Rogers Gonzalez effectively destroyed any ability for Apple to charge commissions on purchases made inside iOS applications but outside Apple’s App Store, and this order will definitely find its way to the European Union as well, where it will serve as further evidence of Tim Cook’s and Apple’s continuous, never-ending contempt for the law and courts that uphold it. For its part, Apple has stated they’re going to appeal. Good luck with that.

Time for another story from Raymond Chen, about why, in Windows 7, logging in took 30 seconds if you had set a solid colour as your background. Windows 7’s logon system needs to wait for a number of tasks to be completed, like creating the taskbar, populating the desktop with icons, and setting the background. If all of those tasks are completed or 30 seconds have passed, the welcome screen goes away. As you can guess by the initial report mentioning having to wait for 30 seconds, one of the tasks that need to be completed isn’t reporting in, so the welcome screen is displayed for the full 30 seconds. In the case of this bug, that task is obviously setting the background. The code to report that the wallpaper is ready was inside the wallpaper bitmap code, which means that if you don’t have a wallpaper bitmap, the report is never made, and the logon system waits in vain for a report that will never arrive. ↫ Raymond Chen It turns out that people who enabled the setting the hide desktop icons were experiencing the same delay, and that, too, was caused by the lack of a report from, in this case, the desktop icons. Interestingly, it seems especially settings changed through group policies can cause issues like this. Group policies are susceptible to this problem because they tend to be bolted on after the main code is written. When you have to add a group policy, you find the code that does the thing, and you put a giant “if policy allows” around it. Oops, the scope of the “if” block extended past the report call, so if the policy is enabled, the icons are never reported as ready, and the logon system stays on the Welcome screen for the full 30 seconds. ↫ Raymond Chen These issues were fixed very quickly after the release of Windows 7, and they disappear from the radar within a few months after the release of everyone’s favourite Windows version.

When Google released the fourth beta of Android 16 this month, many users were disappointed by the lack of major UI changes. As Beta 4 is the final beta, it’s likely the stable Android 16 release won’t look much different than last year’s release. However, that might not hold true for subsequent updates. Google recently confirmed it will unveil a new version of its Material Design theme at its upcoming developer conference, and we’ve already caught glimpses of these design changes in Android—including a notable increase in background blur effects. Ahead of I/O next month, here’s an early look at Google’s upcoming Android redesign. ↫ Mishaal Rahman at Android Authority With Android, it’s hard to really care about changes like these because it will take forever and a day for the Android ecosystem to catch up, and in general in mobile computing, most people use applications that have zero respect for platform integration anyway, preferring their own shit branding and UI “design” over that of the platform they’re running on. In other words, most people will never really encounter many of these changes, unless they’re Pixel users. That being said, these changes seem to basically replace a lot of “window” backgrounds with a blur, which makes everything feel more airy and brighter – so much so that in screenshots purporting to show dark mode, it looks like light mode. This doesn’t really seem like the “big UI overhaul” the linked article claims it to be, but there might be more changes on the way we haven’t seen yet. Instead of UI changes, I’m much more concerned about how much worse Google will be making Android by shoving Clippy into every corner of the operating system.

The majority of the traffic on the web is from bots. For the most part, these bots are used to discover new content. These are RSS Feed readers, search engines crawling your content, or nowadays AI bots crawling content to power LLMs. But then there are the malicious bots. These are from spammers, content scrapers or hackers. At my old employer, a bot discovered a wordpress vulnerability and inserted a malicious script into our server. It then turned the machine into a botnet used for DDOS. One of my first websites was yanked off of Google search entirely due to bots generating spam. At some point, I had to find a way to protect myself from these bots. That’s when I started using zip bombs. ↫ Ibrahim Diallo I mean, when malicious bots harm your website, isn’t combating them with something like zip bombs simply just self-defense?

Late last year, I went on a long journey to rid myself of as much of my remaining ties to the big technology giants as I could. This journey is still ongoing, with only a few thin ties remaining, but there’s one big one I can scratch off the list: mobile in-store payments with NFC tap-to-pay. I used Google Pay and a WearOS smartwatch for this, but neither of those work on de-Googled Android – I opted for GrapheneOS – and it seemed like I was just going to have to accept the loss of this functionality. That is, until I stumbled upon a few forum posts here and there suggesting a solution: Garmin, maker of fitness trackers and smartwatches with a strong focus on sports, health, and the outdoor lifestyle, has its own mobile NFC tap-to-pay service that supposedly worked just fine on any Android device, de-Googled or not. In fact, people claimed you could even remove the companion Garmin application from your phone entirely after setting up the payment functionality, and it would still keep working. This seemed like something I should look into, because the lack of NFC tap-to-pay is a recurring concern for many people intending to switch to de-Googled Android. So, late last year, many of you chipped in, allowing me to buy a Garmin smartwatch to try this functionality out, for which I’m incredibly grateful, of course. Here’s how all of this works, and if it’s a good alternative for Google Pay. The Garmin Instinct 2S Solar First, let’s dive into which watch I chose to buy. Garmin has a wide variety of fitness trackers and smartwatches in its line-up, from basic trackers, to Apple Watch/WearOS-like devices, to outdoor-focused rugged devices. I opted for one of the outdoor-focused rugged devices, because not only would it give me the Garmin Pay functionality, but also a few other advantages and unique features I figured OSNews readers would be interested in: a simple black-and-white transflective memory-in-pixel display, a battery life measured in weeks (!), a solar panel built into the display glass, and a case constructed out of lightweight but durable plastics instead of heavy, scratch-prone metal. The specific model I opted for was the Instinct 2S Solar in Mist Grey. I wasn’t intending for this to become a review of the watch as a whole, but I figured I might as well share some notes about my experiences with this particular watch model. It’s important to note though that Garmin offers a wide variety of smartwatches, from models that look and feel mostly like an Apple Watch or wearOS device, to mechanical models with ‘invisible’ OLED displays on the dial, to ruggedised, button-only watches for hardcore outdoor people. If you’re interested in a Garmin device, there’s most likely a type that fits your wishes. The Instinct 2S is definitely not the most beautiful or attractive watch I’ve ever had on my wrist. It has that “rugged” look some people are really into, but for me, I definitely had to get used to it. I do really like the colour combination I opted for, though, as it complements the black/white transflective memory-in-pixel display really well. I’ve grown to… Appreciate the look over time. The case and bezel of the watch are made out of what Garmin calls “fiber-reinforced polymer”, which is probably just a form of fiber-reinforced plastic. Regardless of the buzzwords, it feels nice and sturdy, with a great texture, and not at all plasticy or cheap. Using a material like this over the metals the Apple Watch and most WearOS devices are made of has several advantages; first, it makes the device much lighter and thus more pleasant to wear, and it’s a lot sturdier and resilient than metals. I’ve banged this watch into door sills and countertops a few times now, and there’s not a scratch, dent, or discoloration on it – a far cry from the various metal Apple Watches and WearOS devices I own, which accumulated dings and scratches within weeks of buying them. The case material is one of the many ways in which this watch chooses function over form. Sure, metals might feel premium, but a high-quality plastic is cheaper to make, lasts longer, is more resilient, and also happens to be lighter – it’s simply the objectively better choice for something you wear on wrist every day, exposed to the elements. I understand why people want their smartwatch to be made out of metal, but much like how the orange-red plastic of the Nexus 5 is still the best smartphone material I’ve ever experienced (the white and black models uses inferior plastics), this Garmin tops all of the metal watches I own. The strap is made of silicone, and has an absurd amount of tightly-spaced adjustment holes, which makes it very easy to adjust to changing circumstances, like a bit of extra slack for when you’re working out. It also has a nice touch in that the second loop has a little peg that slots into an adjustment hole, keeping it in place. Ingenious. Other than that, it’s just a silicone band with the clasp made out of the same sturdy, pleasant “fiber-reinforced polymer” as the case. The lens over the display is made out of something Garmin calls “Power Glass™”, and I have no idea what that means. It just feels like a watch lens to me – solid, glassy, and… I don’t know, round? The unique aspect of the display glass is, of course, the built-in solar panel. It’s hard for me to tell what kind of impact – if any – the solar panel has on the battery life of the device. What quite obviously does not help is that I live in the Arctic where sun hours come at a bit of a premium, so it’s been impossible for me to stand outside and hold out my arm for a while to see if it had an effect on the charge level. There’s a software

Another six months have passed, so it’s time for a new OpenBSD release: OpenBSD 7.7 to be exact. Browsing through the long, detailed list of changes, a few important bits jump out. First, OpenBSD 7.7 adds support for Ryzen AI 300 (Strix Point, Strix Halo, Krackan Point), Radeon RX 9070 (Navi 48), and Intel’s Arrow Lake, adding support for the latest x86 processors to OpenBSD. There seems to be quite a few entries in the list related to power management, from work on hibernation and suspend, to more fine-grained control over performance profiles when on battery or plugged in. There’s also the usual long list of driver improvements, new drivers, and tons and tons of other fixes and changes. OpenBSD 7.7 also ships with the latest GNOME and KDE releases, and contains fixes and improvements for a whole slew of obscure and outdated architectures.

The Wii homebrew community has been dealt a pretty serious blow, as developers of The Homebrew Channel for the Wii have discovered that not only does an important library most Wii homebrew software rely on use code stolen straight from Nintendo, that same library also uses code taken from an open source real-time operating system without giving proper attribution. Most Wii homebrew software is built atop a library called libogc. This library apparently contains code stolen from Nintendo’s SDK as well as from games using this SDK, decompiled and cleaned. This has been known for a while, but it was believed that large, important parts of libogc were at least original, but that, too, turns out to be untrue. Recently it has been discovered that libogc’s threading/OS implementation has been stolen from RTEMS, an open source real-time operating system. The developers of libogc have indicated that they do not care, intend to do nothing about it, and deleted any issues reporting the stolen code. What’s wild about the code stolen from RTEMS is that it’s an open source operating system with a nice, permissive license; there was no need to steal the code at all, and all it would take to address it is proper attribution. As such, the fail0verflow group, which develops The Homebrew Channel for the Wii, has ceased all development on The Homebrew Channel, and archived the code repository. The Wii homebrew community was all built on top of a pile of lies and copyright infringement, and it’s all thanks to shagkur (who did the stealing) and the rest of the team (who enabled it and did nothing when it was discovered). Together, the developers deceived everyone into believing their work was original. Please demand that the leaders and major contributors to console or other proprietary device SDKs and toolkits that you use and work with do things legally, and do not tolerate this kind of behavior. ↫ The Homebrew Channel GitHub page Considering Nintendo is on a crusade to shutdown emulators, stuff like this is really not helping anyone trying to argue that consoles should be open devices, that emulators play an important role in preservation, and that people have a right to play the games they own on a device other than the console it’s intended for. I’m sure this isn’t the last we’ll hear about this development.

RetrOS-32 is a 32bit operating system written from scratch, with graphics, multitasking and networking capabilities. The kernel is written in C and assembly, while the userspace applications are written in C++, using Make for compilation, all licensed under the MIT license. It runs on Qemu, of course, but a variety of real hardware is also supported, which is pretty cool and relatively unique for a small hobby project like this. The UI is delightfully retro – as the name obviously implies – and it comes with a set of basic applications, as well as games like Wolfenstein 3D.

We’ve had a lot of fun with VTech’s computers in the past on this blog. Usually, they’re relatively spartan computers with limited functionality, but they did make something very interesting in the late 80s. The Socrates is their hybrid video game console/computer design from 1988, and today we’ll start tearing into it. ↫ Leaded Solder web log Now we’re in for the good stuff. A weird educational computer/game console/toy thing from the late ’80s, by VTech. I have a massive soft spot for these toy-like devices, because they’re always kind of a surprise – will it be a stupidly simple hardcoded device with zero input/output, or a weirdly capable computer with tons of hidden I/O and a full BASIC ROM? You won’t know until you crack it open and take a peek! VTech still makes things like this, and I still find them ever as fascinating.