A page loads in under a second. A payment clears before you’ve put your phone down. A video starts without a single buffering pause. These moments feel effortless, and that’s exactly the point. But behind every seamless digital interaction sits an enormous stack of infrastructure, logic, and verification that most users will never see.  The faster something feels, the more engineering it usually took to get there. Speed is not simplicity. It is the result of removing visible friction while absorbing enormous invisible complexity. What “Instant” Actually Demands from a System When a system promises instant results, it is making a commitment that requires every connected component to perform at peak reliability simultaneously. A single slow database query, an overloaded server node, or a poorly optimized API call can break the entire illusion.  Latency is the enemy of instant. Reducing it requires decisions made at the architecture level, long before any user interacts with the product. This means choosing the right data centers, caching strategies, and content delivery configurations. It also means anticipating traffic spikes and building systems that scale horizontally without degrading performance. None of this is visible to the end user, but all of it determines whether the product feels instant or merely fast. Consistency matters as much as speed. A system that responds in 200 milliseconds ninety percent of the time but stalls for two seconds on the remaining ten percent is not truly instant; it is unpredictable. Engineering teams measure this with percentile-based performance metrics rather than averages, because averages hide the worst-case scenarios that users remember most. Compliance Verification and the Weight of Real-Time Security Speed alone is not enough. Every transaction or data exchange that happens in real time must also be verified, authenticated, and checked against compliance rules, often within the same window of milliseconds that the user experiences as instant. This involves identity validation, fraud detection algorithms, anti-money laundering checks, and regulatory screening, all running in parallel without slowing the visible response. The engineering required to do this without creating delays is substantial. For digital services operating across borders, compliance layers multiply. Different jurisdictions carry different legal requirements, and the system must identify where a user is operating from and apply the correct ruleset automatically. A transaction that is permitted in one country may require additional verification in another.  Online gambling is one area where this intersection of speed and compliance is especially pronounced. Across Europe, and particularly in Finland, regulators hold digital gambling platforms to strict standards around identity verification, responsible gaming controls, and transaction transparency.  A pikakasino operating in the Finnish market must meet these national standards precisely, delivering instant deposits and withdrawals while simultaneously satisfying the framework that governs local play standards. The compliance work behind that instant transaction is far more complex than what the player ever sees. E-Commerce and the Logistics Behind One-Click Purchases Online retail has trained consumers to expect that clicking “buy” should result in an immediate confirmation, a reserved inventory slot, and a dispatched order, sometimes within hours. What looks like a single action triggers a chain of systems: payment processors, inventory databases, warehouse management software, and logistics APIs, all communicating in real time.  If any one of these handoffs is slow or fails silently, the experience breaks down at a point the customer was never supposed to notice. Fraud prevention in e-commerce adds another layer. Every purchase is assessed by risk-scoring models that evaluate the transaction against historical patterns, device fingerprints, and behavioral signals, all before the checkout confirmation screen appears.  Merchants who skip or delay these checks lose money to fraud. Those who run them too slowly lose customers to abandoned carts. The margin between secure and instant is narrow, and hitting it consistently requires careful system design. Crypto Transactions and the Speed of Trustless Verification Cryptocurrency introduced a new model for instant digital value transfer, one that replaces centralized authority with distributed consensus. But consensus takes time. Early blockchain networks processed transactions slowly, and users waiting for confirmations learned quickly that “instant” in crypto was relative.  Newer networks and layer-two solutions have compressed confirmation times dramatically, but they do so by making the underlying consensus mechanism more complex, not simpler. Wallet applications that display real-time balance updates are running continuous synchronization processes behind the scenes. Gas fee estimation, mempool monitoring, and smart contract execution all contribute to what the user perceives as a straightforward send-and-receive interaction.  The decentralized nature of these systems means there is no single point of control to optimize; speed improvements require coordination across distributed nodes, which is an entirely different engineering challenge than traditional server infrastructure.

It shouldn’t be a surprise that companies – and for our field, technology companies specifically – working with the defense industry tends to raise eyebrows. With things like the genocide in Gaza, the threats of genocide and war crimes against Iran, the mass murder in Lebanon, it’s no surprise that western companies working with the militaries and defense companies involved in these atrocities are receiving some serious backlash. With that in mind, it seems Red Hat, owned by IBM, is desperately trying to scrub a certain white paper from the internet. Titled “Compress the kill cycle with Red Hat Device Edge”, the 2024 white paper details how Red Hat’s products and technologies can make it easier and faster to, well, kill people. Links to the white paper throw up 404s now, but it can still easily be found on the Wayback Machine and other places. It’s got some disturbingly euphemistic content. The find, fix, track, target, engage, assess (F2T2EA) process requires ubiquitous access to data at the strategic, operational and tactical levels. Red Hat Device Edge embeds captured, analyzed, and federated data sets in a manner that positions the warfighter to use artificial intelligence and machine learning (AI/ML) to increase the accuracy of airborne targeting and mission-guidance systems. Delivering near real-time data from sensor pods directly to airmen, accelerating the sensor-to-shooter cycle. Sharing near real-time sensor fusion data with joint and multinational forces to increase awareness, survivability, and lethality. The new software enabled the Stalker to deploy updated, AI-based automated target recognition capabilities. If the target is an adversary tracked vehicle on the far side of a ridge, a UAS carrying a server running Red Hat Device Edge could transmit video and metadata directly to shooters. ↫ Red Hat white paper titled “Compress the kill cycle with Red Hat Device Edge” I don’t think there’s something inherently wrong with working together with your nation’s military or defense companies, but that all hinges on what, exactly, said military is doing and how those defense companies’ products are being used. The focus should be on national defense, aid during disasters, and responding to the legitimate requests of sovereign, democratic nations to come to their defense (e.g. helping Ukraine fight off the Russian invasion). There’s always going to be difficult grey areas, but any military or defense company supporting the genocide in Gaza or supplying weapons to kill women and children in Iran is unequivocally wrong, morally reprehensible, and downright illegal on both an international and national level. It clearly seems someone at Red Hat feels the same way, as the company has been trying really hard to memory-hole this particular white paper, and considering its word choices and the state of the world today, it’s easy to see why. Of course, the internet never forgets, and I certainly don’t intend to let something like this slide. We all know companies like Microsoft, Oracle, and Google have no qualms about making a few bucks from a genocide or two, but it always feels a bit more traitorous to the cause when it’s an open source company doing the profiting. It feels like Red Hat is trying to have its cake and eat it too, by, as an IBM subsidiary, trying to both profit from the vast sums of money sloshing around in the US military industrial complex as well as maintain its image as a scrappy open source business success story shitting bunnies and rainbows. It’s a long time ago now that Red Hat felt like a genuine part of the open source community. Most of us – both outside and inside of Red Hat, I’m sure – have been well aware for a long time now that those days are well behind us, and I guess Red Hat doesn’t like seeing its kill cycle this compressed.

It may sound unbelievable to some, but not everyone has a datacenter beast with 128GB of VRAM shoved in their desktop PCs. Around the world people tell the tale of a particularly fierce group of Linux gamers: Those who dare attempt to play games with only 8 gigabytes of VRAM, or even less. Truly, it takes exceedingly strong resilience and determination to face the stutters and slowdowns bound to occur when the system starts running low on free VRAM. Carnage erupts inside the kernel driver as every application fights for as much GPU memory as it can hold on to. Any game caught up in this battle for resources will surely not leave unscathed. That is, until now. Because I fixed it. ↫ Natalie Vock The solution is to use cgroups to control the kernel’s memory eviction policies, so that applications that should get priority when it comes to VRAM allocation – like games – don’t get their memory evicted from VRAM to system RAM. Basically, evict everything else from VRAM before touching the protected application. This way, something like a game will have much more consistent access to more VRAM, thereby reducing needless memory evictions that harm performance. It’s a clever solution that makes use of a ton of existing Linux tools, meaning it’s also much easier to upstream, implement, and support. Excellent work.

You might have seen this, one of the strangest and most primitive experiences in macOS, where you’re asked to press keys next to left Shift and right Shift, whatever they might be. Perhaps I can explain. ↫ Marcin Wichary It seems pretty obvious to me that’s what it was for, but I guess many normal, regular people have never seen anything but one particular keyboard configuration (ANSI for Americans, ISO for some Europeans, etc.) keyboards. Perhaps they don’t realise that not only are there ANSI keyboards with other layouts, but also entirely different keyboard configurations (mainly ISO and JIS). Interestingly, my home country of The Netherlands uses a US English layout on an ANSI configuration, but of course, it’s the US International variant, either with deadkeys or using AltGr for the various accented/special characters we use. In my current country of residence, Sweden, they use this utterly wild and incomprehensible ISO layout where Shift unlocks characters on the bottom of keys, while AltGr unlocks characters at the top, the exact opposite of literally every other keyboard I’ve ever used (US Int’l, classic Dutch (no longer used), German, French, etc.). It’s utterly bizarre, but entirely normal to my Swedish wife. We cannot use each other’s keyboards.

The months keep coming, and thus, the monthly progress reports keep coming, too, for Redox, the new general purpose operating system written in Rust. This past month, there’s been considerable graphics improvements, better deadlock detection in the kernel, improved Unicode support thanks to switching over to ncurses library variant with Unicode support, and much more. Alongside these, you’ll find the usual long list of kernel, driver, and relibc changes, bugfixes, and improvements. This month also covered three topics we’ve already discussed individually: Redox’ new no-“AI” code policy, capability-based security in Redox, and the brand-new CPU scheduler.

Since its launch in 2007, the Wii has seen several operating systems ported to it: Linux, NetBSD, and most-recently, Windows NT. Today, Mac OS X joins that list. In this post, I’ll share how I ported the first version of Mac OS X, 10.0 Cheetah, to the Nintendo Wii. If you’re not an operating systems expert or low-level engineer, you’re in good company; this project was all about learning and navigating countless “unknown unknowns”. Join me as we explore the Wii’s hardware, bootloader development, kernel patching, and writing drivers – and give the PowerPC versions of Mac OS X a new life on the Nintendo Wii. ↫ Bryan Keller And all of this, because someone on Reddit said it couldn’t be done. It won’t surprise you to learn that the work required was extensive, from writing a custom bootloader to digging through the XNU source code, applying binary patches to the kernel during the boot process, building a device tree, writing the necessary drivers, and so much more. Even just setting up a development environment was a pretty serious undertaking. Especially writing the drivers posed an interesting and unique challenge, as the Wii doesn’t use PCI to connect and expose its hardware components. Instead, components are connected to a dedicated SoC with its own ARM processor that talks to the main Wii PowerPC processor, exposing hardware that way. This meant that Keller had to write a driver for this chip first, before moving on to the device drivers for devices connected to this ARM SoC – graphics drivers, input drivers, and so on. After a ton more work and overcoming several complex roadblocks, we now have Mac OS X 10.0 Cheetah on the Nintendo Wii. Amazing.

Anos is a modern, opinionated, non-POSIX operating system (just a hobby, won’t be big and professional like GNU-Linux) for x86_64 PCs and RISC-V machines. Anos currently comprises the STAGE3 microkernel, SYSTEM user-mode supervisor, and a base set of servers implementing the base of the operating system. There is a (WIP) toolchain for Anos based on Binutils, GCC (16-experimental) and Newlib (with a custom libgloss). ↫ Anos GitHub page It’s written in C, runs on both x86-64 and RISC-V, and can run on real hardware too (but this hasn’t been tested on RISC-V just yet). For the x86 side of things, it’s strictly 64 bit, and requires a Haswell (4th Gen) chip or higher.

This year sees 35 years since 2.11BSD was announced on March 14, 1991 – itself a slightly late celebration of 20 years of the PDP-11 – and January 2026 brought what looks to be the venerable 16-bit OS’s biggest ever patch! Much of the 1.3 MB size is due to Anders Magnusson, well-known for his work on NetBSD and the Portable C Compiler. Since 2.11BSD’s stdio was not ANSI compliant, he’s ported from 4.4BSD. ↫ BigSneakyDuck at Reddit There’s an incredible amount of work in here on this old variant of BSD, including fixes for old bugs and tons of other changes. This, the 499th patch for 2.11BSD, is so big, in fact, that vi on 2.11BSD can’t handle the size of the files, so you’re going to need to cut them up with sed, for which instructions are included. It’s quite unique to see such a big update on the 35th anniversary of an operating system.

This is a great post, but obviously it hasn’t convinced me: The folks waving their arms and yelling about recent models’ capabilities have a point: the thing works. This project finished in three weeks. Compare that to Ringspace, a similarly-sized project that took me about six months of nights and early mornings to complete, while not doing my day job or being Dad to an amazing, but demanding toddler. I simply could not have built this project as well or as quickly without help. And as other developers have noted, this is the help that’s showing up. I’m not entirely onboard with Mike Masnick’s optimistic view of this technology’s democratizing power. I don’t think it’s as easy to separate the tech from its provenance or corporate control. But CertGen, my certificate application, exists now. It didn’t and couldn’t without the help of a tool like Claude Code. Open source in particular needs to reckon with this, because the current situation of demanding developers starve and bleed themselves dry without support isn’t tenable. We need to grapple with this. I’m not yet sure how it all breaks down, and anyone who says they do is lying, foolish, or fanatical. ↫ Michael Taggart If you disregard that “AI” models are trained on stolen data, that such data was prepared by exploited workers, that “AI” data centres have a hugely negative impact on the environment, that “AI” data centers are distorting the entire computing market, that “AI” models they feed the endless firehose of intentional misinformation, that they are wreaking havoc in education, that they increase your reliance on American big tech companies, that you pay “AI” companies for taking your work, that “AI” models are a vital component in the technofascist wet dreams of their creators, that they are the cornerstone of politicians’ dream of ending anonymity, and that they contribute to racist and abusive policing, then yes, sometimes, they produce code that works and isn’t total horseshit. It’s a deeply depressing reversed “what have the Romans ever done for us?” that makes me sad, more than anything. I’ve seen so many otherwise smart, caring, and genuine people just shove all of these massive downsides aside for the mere novelty, the peer pressure, the occasional sense that their “lines of code” metric is going up. It’s the digital equivalent of rolling coal.

If you’re using Windows or macOS and have Adobe Creative Cloud installed, you may want to take a peek at your hosts file. It turns out Adobe adds a bunch of entries into the hosts file, for a very stupid reason. They’re using this to detect if you have Creative Cloud already installed when you visit on their website. When you visit https://www.adobe.com/home, they load this image using JavaScript: https://detect-ccd.creativecloud.adobe.com/cc.png If the DNS entry in your hosts file is present, your browser will therefore connect to their server, so they know you have Creative Cloud installed, otherwise the load fails, which they detect. They used to just hit http://localhost:<various ports>/cc.png which connected to your Creative Cloud app directly, but then Chrome started blocking Local Network Access, so they had to do this hosts file hack instead. ↫ thenickdude at Reddit At what point does a commercial software suite become malware?

An ultra-lightweight real-time operating system for resource-constrained IoT and embedded devices. Kernel footprint under 10 KB, 2 KB minimum RAM, preemptive priority-based scheduling. ↫ TinyOS GitHub page Written in C, open source, and supports ARM and RISC-V.

Another major improvement in Redox: a brand new scheduler which improves performance under load considerably. We have replaced the legacy Round Robin scheduler with a Deficit Weighted Round Robin scheduler. Due to this, we finally have a way of assigning different priorities to our Process contexts. When running under light load, you may not notice any difference, but under heavy load the new scheduler outperforms the old one (eg. ~150 FPS gain in the pixelcannon 3D Redox demo, and ~1.5x gain in operations/sec for CPU bound tasks and a similar improvement in responsiveness too (measured through schedrs)). ↫ Akshit Gaur Work is far from over in this area, as they’re now moving on to “replacing the static queue logic with the dynamic lag-calculations of full EEVDF“.

This is the first of a series of articles in which you will learn about what may be one of the silliest, most preventable, and most costly mishaps of the 21st century, where Microsoft all but lost OpenAI, its largest customer, and the trust of the US government. ↫ Axel Rietschin It won’t take long into this series of articles before you start wondering how anyone manages to ship anything at Microsoft. If even half of this is accurate, this company should be placed under some sort of external oversight.

I assume I don’t have to explain the difference between big-endian and little-endian systems to the average OSNews reader, and while most systems are either dual-endian or (most likely) little-endian, it’s still good practice to make sure your code works on both. If you don’t have a big-endian system, though, how do you do that? When programming, it is still important to write code that runs correctly on systems with either byte order (see for example The byte order fallacy). But without access to a big-endian machine, how does one test it? QEMU provides a convenient solution. With its user mode emulation we can easily run a binary on an emulated big-endian system, and we can use GCC to cross-compile to that system. ↫ Hans Wennborg If you want to make sure your code isn’t arbitrarily restricted to little-endian, running a few tests this way is worth it.