On Friday afternoon, The Wall Street Journal reported Intel had been approached by fellow chip giant Qualcomm about a possible takeover. While any deal is described as “far from certain,” according to the paper’s unnamed sources, it would represent a tremendous fall for a company that had been the most valuable chip company in the world, based largely on its x86 processor technology that for years had triumphed over Qualcomm’s Arm chips outside of the phone space.

↫ Richard Lawler and Sean Hollister at The Verge

Either Qualcomm is only interested in buying certain parts of Intel’s business, or we’re dealing with someone trying to mess with stock prices for personal gain. The idea of Qualcomm acquiring Intel seems entirely outlandish to me, and that’s not even taking into account that regulators will probably have a thing or two to say about this. The one thing such a crazy deal would have going for it is that it would create a pretty strong and powerful all-American chip giant, which is a PR avenue the companies might explore if this is really serious.

One of the most valuable assets Intel has is the x86 architecture and the associated patents and licensing deals, and the immense market power that comes with those. Perhaps Qualcomm is interested in designing x86 chips, or, more likely, perhaps they’re interested in all that sweet, sweet licensing money they could extract by allowing more companies to design and sell x86 processors. The x86 market currently consists almost exclusively of Intel and AMD, a situation which may be leaving a lot of licensing money on the table.

Pondering aside, I highly doubt this is anything other than an overblown, misinterpreted story.

Can you run Linux on the Intel 4004, the first commercially produced microprocessor, released to the world in 1971? Well, Dmitry Grinberg, the genius engineer who got Linux to run on all kinds of incredibly underpowered hardware, sought to answer this very important question. In short, yes, you can run Linux on the 4004, but much as with other extremely limited and barebones chips, you have to get… Creative. Very creative.

Of course, Linux cannot and will not boot on a 4004 directly. There is no C compiler targeting the 4004, nor could one be created due to the limitations of the architecture. The amount of ROM and RAM that is addressable is also simply too low. So, same as before, I would have to resort to emulation. My initial goal was to fit into 4KB of code, as that is what an unmodified unassisted 4004 can address. 4KB of code is not much at all to emulate a complete system. After studying the options, it became clear that MIPS R3000 would be the winner here. Every other architecture I considered would be harder to emulate in some way. Some architectures had arbitrarily-shifted operands all the time (ARM), some have shitty addressing modes necessitating that they would be slow (RISCV), some would need more than 4KB to even decode instructions (x86), and some were just too complex to emulate in so little space (PPC). … so … MIPS again… OK!

↫ Dmitry Grinberg

This is just one very small aspect of this massive undertaking, and the article and videos accompanying his success are incredibly detailed and definitely not for the faint of heart. The amount of skill, knowledge, creativity, and persistence on display here is stunning, and many of us can only dream of being able to do stuff like this. I absolutely love it.

Of course, the Linux kernel had to be slimmed down considerably, as a lot of stuff currently in the kernel are of absolutely no use on such an old system. Boot time is measured in days, still, but it helped a lot. Grinberg also turned the whole setup into what is effectively an art piece you can hang on the wall, where you can have it run and, well, do things – not much, of course, but he did include a small program that draws mandelbrot set on the VFD and serial port, which is a neat trick.

He plans on offering the whole thing as a kit, but a lot of it depends on getting enough of the old chips to offer a complete, ready-to-assemble kit in the first place.

Nintendo, together with The Pokémon Company, filed a patent infringement lawsuit in the Tokyo District Court against Pocketpair, Inc. on September 18, 2024.

This lawsuit seeks an injunction against infringement and compensation for damages on the grounds that Palworld, a game developed and released by the Defendant, infringes multiple patent rights.

↫ Nintendo press release

Since the release of Palworld, which bears a striking resemblance to the Pokémon franchise, everybody’s been kind of expecting a reaction from both Nintendo and The Pokémon Company, and here it is. What’s odd is that it’s not a trademark, trade dress, or copyright lawsuit, but a patent one, which is not what you’d expect when looking at how similar the Palworld creatures look to Pokémon, to the point where some people even suggest the 3D models were simply lifted wholesale from the latest Nintendo Switch Pokémon games.

There’s no mention of which patents Pocketpair supposedly infringes upon, and in a statement, the company claims it, too, has no idea which patents are supposedly in play. I have to admit I never even stopped to think game patents were a thing at all, but now that I spent more than 2 seconds pondering this concept, of course they exist.

This lawsuit will be quite interesting to follow, because the games industry is one of the few technology sectors out there where copying each others ideas, concepts, mechanics, and styles is not only normal, it’s entirely expected and encouraged. New ideas spread through the games industry like wildfires, and if some new mechanic is a hit with players, it’ll be integrated into other games within a few months, and games coming out a year later are expected to have the hit new mechanics from last year.

It’s a great example of how beneficial it is to have ideas freely spread, and how awesome it is to see great games take existing mechanics and apply interesting twists, or use them in entirely different genres than where they originated from. Demon’s Souls and the Dark Souls series are a great example of a series of games that not only established a whole new genre other games quickly capitalised on, but also introduced the gaming world to a whole slew of new and unique mechanics that are now being applied in all kinds of new and interesting ways.

Lawsuits like this one definitely pose a threat to this, so I hope that either this fails spectacularly in court, or that the patents in question are so weirdly specific as to be utterly without merit in going after any other game.

As we look to the future, maintaining a proprietary IR format (even one based on an open-source project) is counter to our commitments to open technologies, so Shader Model 7.0 will adopt SPIR-V as its interchange format. Over the next few years, we will be working to define a SPIR-V environment for Direct3D, and a set of SPIR-V extensions to support all of Direct3D’s current and future shader programming features through SPIR-V. This will allow developers to take better advantage of existing tools and unify the ecosystem around investing in one IR.

↫ Chris Bieneman and Cassie Hoef at the DirectX Developer Blog

SPIR-V is developed by the Khronos Group and is an “intermediate language for parallel computing and graphics by Khronos Group”. I don’t know what any of this means, but any adoption of Khronos technologies is a good thing, especially by a heavyweight like Microsoft.

The GNOME project has released their newest major version, GNOME 47, and while it’s not the most groundbreaking release, there’s still a ton of good stuff in here. Two features really stand our, with the first one being the addition of accent colours. Instead of being locked into the default GNOME blue accent colour, you can now choose between a variety of colours, which is a very welcome addition. I use the accent colour feature on all my computers, and since I run KDE, I also have this nifty KDE feature where it’ll select an accent colour automatically based on your wallpaper.

No, this isn’t a groundbreaking feature, but considering GNOME’s tendency towards not allowing any customisation, this is simply very welcome.

A much more substantial feature comes in the form of brand new open/save file dialogs, and I’m sure even the GNOME developers themselves are collectively sighing in relief about this one. GNOME’s open/save dialogs were so bad they became a meme, and now they’re finally well and truly fixed, thanks to effectively removing the old ones and adding new ones based on the GNOME Files file manager.

GNOME 47 comes with brand new file open and save file dialogs. The new dialogs are a major upgrade compared with the previous versions, and are based on the existing Files app rather than being a separate codebase. This results in the new dialogs having a much more complete set of features compared with the old open and save dialogs. With the new dialogs you can zoom the view, change the sort order in the icon view, rename files and folders, preview files, and more.

↫ GNOME 47 release notes

And yes, this includes thumbnails.

There’s tons more in GNOME 47, like a new design for dialog windows that look and feel more like they belong on a mobile UI, tons of improvements to Files, the Settings application, GNOME Online Accounts, Web, and more. GNOME 47 will make its way to your distribution of choice soon enough, but of course, you can always build and install it yourself if you’re so inclined.

Intel’s woes are far from over. Pat Gelsinger, the company’s CEO, has announced that Intel’s chipmaking business will be spun off and turned into a separate company.

A subsidiary structure will unlock important benefits. It provides our external foundry customers and suppliers with clearer separation and independence from the rest of Intel. Importantly, it also gives us future flexibility to evaluate independent sources of funding and optimize the capital structure of each business to maximize growth and shareholder value creation.

There is no change to our Intel Foundry leadership team, which continues to report to me. We will also establish an operating board that includes independent directors to govern the subsidiary. This supports our continued focus on driving greater transparency, optimization and accountability across the business.

↫ Pat Gelsinger

This is a big move, and illustrated the difficulties Intel is facing. Its foundry business lost $7 billion last year, and it’s cutting 15% of its workforce – 15000 people – indicating it needs to do something to turn the ship around. Intel is also pausing construction on two additional plants in Europe, but will continue its expansion efforts in the United States. Bitter note is that Intel received a massive cash injection from the US Biden administration, yet then proceeds to fire 15000 people.

Socialism for the rich, capitalism for the poor.

Are you developing a game for Windows, and are you working on input handling?

At first, it could reasonably be assumed that mouse and keyboard should be the simplest parts of this to deal with, but in reality, they are not – at least if we are talking about Windows. In fact, several extremely popular AAA games ship with severe mouse input issues when specific high-end mice are used, and some popular engines have issues that are still extant.

In this article we’ll explore a few reasons why that is the case, and end up with a solution that works but is still unsatisfactory. I assume that there is a whole other level of complexity involved in properly dealing with accessories like steering wheels, flight sticks, and so on in simulators, but so far I never had the pleasure of working on a game that required this, and this article will not cover those types of input devices.

↫ Peter ‘Durante’ Thoman

So, what is the problem? Basically, there are two ways to handle mouse input in Windows: if you use batched raw input processing, which is pretty much a requirement, you need to also choose whether or not to keep legacy input enabled. If you keep it enabled, the legacy input will add so much junk to your message queue it can negatively impact the performance of your game quite harshly. If you disable it, however, something really fun happens: you can no longer move the game window… Because the Windows UI uses legacy input.

Thoman has a solution that he and his company uses, and he considers it an ugly hack, but they just don’t know of a better way to solve this issue. Thoman keeps legacy input enabled, but just limits the number of message queue events per frame that are being processed (they limit it to 5). As far as they can tell, this doesn’t seem to have any negative side effects, but it’s clearly a bit of an ugly hack that shouldn’t be necessary.

I found this a rather interesting niche topic, and I wonder how many people have struggled with this before, and what kind of other solutions exist.

We all know about the Desktop Publishing revolution that the first Macs and their PostScript LaserWriter printers brought in the late 1980s, but many have now forgotten the Desktop Video revolution that followed in the next decade. At its heart was support for multimedia in Apple’s QuickTime.

QuickTime isn’t a single piece of software, or even an API in Classic Mac OS, but a whole architecture to support almost any media format you could conceive of. It defines container and file formats for multiple media types, forming the basis for the MPEG-4 standard, extensible encoding and decoding of a wide variety of media using Codecs, and more.

↫ Howard Oakley

As a Windows users before I switched to the Mac somewhere in 2003 or 2004 or so, I mostly associated QuickTime with an annoying piece of crapware I sometimes had to install to watch videos, despite my Windows installation being perfectly capable of playing a whole slew of video codecs just fine. To make matters worse, Apple eventually started forcing Windows users to also install their auto-update tool that ran in the background, which would occasionally just… Install stuff without your permission.

Of course, QuickTime was a whole lot more than that, especially on the Mac, where it was simply a core technology of the Mac operating system and the name of the built-in video player. It also served as underpinnings for a whole slew of related technologies, from movie editors like iMovie to the QuickTime streaming tools included in Mac OS X Server, so odds are that somehow, somewhere, you’ve used QuickTime in your life time.

I’m not entirely ashamed to admit I had to check if QuickTime was still part of macOS today – I haven’t actively used macOS since, I think, the Snow Leopard days in 2009 – but it obviously has been sunset quite a while ago in favour of AVFoundation, which macOS still uses today.

It’s Apple operating system release day, so if you’re in the Apple ecosystem, it’s like Christmas morning, but for your devices. The two major platforms are, of course, iOS/iPadOS 18:

‌iOS 18‌ adds new customization options for the Home Screen, with the option to arrange apps and widgets with open spaces and add new tints to app icons. Control Center has been entirely overhauled with support for multiple pages, third-party controls, and the option to put controls on the Lock Screen and activate them with the Action Button.

↫ Juli Clover at MacRumors

And macOS 15:

‌macOS Sequoia‌ features iPhone Mirroring, which allows you to control and monitor your ‌iPhone‌ right from your Mac. You can use your ‌iPhone‌’s apps and get your ‌iPhone‌’s notifications all while your ‌iPhone‌ is tucked away and locked.

Window tiling has been improved to make it easier to arrange multiple windows on your Mac’s display, and there are new keyboard and menu shortcuts for organizing your windows. In Safari, Highlights will now show you the information you want most from websites, and there’s a new Viewer mode for watching videos without distractions.

↫ Juli Clover at MacRumors

It doesn’t stop there, though, as Apple also released watchOS 11, visionOS 2, tvOS 18, and the most import ant most hotly anticipated out of all of Apple’s platforms, HomePod Software 18. It’s genuinely kind of staggering how Apple manages to update all of these various platforms at the same time, each coming with a ton of new features and bugfixes, and ship them out to consumers – generally without any major issues or showstoppers. Especially in the case of iOS and macOS, that’s definitely a major difference with the Windows and Android worlds, where users are confronted with strict hardware requirements, lack of update availability altogether, or just stick with previous versions because the new versions contain tons of privacy or feature regressions.

Do note that Apple’s AI/ML features announced during WWDC aren’t shipping yet, and that iPhone Mirroring is not available in the EU because someone told Tim Cook “no” and he threw a hissy fit.

It’s one of the most pervasive common wisdoms shared all over the web, no matter where you go – it’s one of those things everybody seems to universally agree on: Chrome will absolutely devastate your battery life on the Mac, and you should really be using Safari, because Apple’s special integration magic pixie dust sprinkles ensures Safari sips instead of gulps electricity. Whether you read random forum posters, Apple PR spokespeople, or Apple’s own executives on stage during events, this wisdom is hard to escape.

Is it true, though?

Well, Matt Birchler decided to do something entirely revolutionary and entirely unheard of: a benchmark. Back in the olden days of yore, we would run benchmarks to test the claims from companies and their PR departments, and Birchler decided to dust off this old technique and develop a routine to put the Chrome battery claims to the test. After 3 days of continuous testing on a freshly installed 14” MacBook Pro with an M2 Pro processor and 16 GB RAM running the latest stable releases of both browsers, Birchler came to some interesting conclusions.

In my 3-hour tests, Safari consumed 18.67% of my battery each time on average, and Chrome averaged 17.33% battery drain. That works out to about 9% less battery drain from Chrome than Safari. Yes, you read that right, I found Chrome was easier on my battery than Safari.

While I did experience some variability in each 3 hour test run, Chrome came out on top in 5 of the 6 direct comparisons.

↫ Matt Birchler

His methodology seems quite sound and a good representation of what most laptop users will use their browser for: YouTube, social media, a few news websites, and editing a Google Doc, in a 20 minute loop that was repeated for three hours per test. Multiple of these three hour tests were then ran to counter variability. I highly doubt using different websites will radically change the results, but I obviously am curious to see a similar test ran on Windows and Linux, x86 and ARM, for a more complete picture that goes beyond just the Mac.

Conventional wisdom is sometimes wrong, and I think we have a classic case of that here. While there may have been a time in the past where Chrome on the Mac devastated battery life, it seems Chrome and Chromium engineers have closed the gap, and in some cases even beat Safari. Now, this doesn’t mean everybody should rush and switch to Chrome, since there are countless other reasons to use Safari over Chrome other than supposed battery life advantages.

With Apple PR arguing that alternative browser engines should not be allowed on iOS because Chrome would devastate iOS’ battery life, tests like these are more important than ever, and I hope we’re going to see more of them. Tech media always just seems to copy/paste whatever manufacturers and corporations claim without so much as a hint of skepticism, and this benchmark highlights the dangers of doing so, in case you didn’t already know believing corporations was a terribly idea.

It’s always a lovely day when it’s a Haiku release day – and sadly, those don’t come very often. Of course, Haiku’s nightlies tend to be rather solid so an official release isn’t really a must if you want to use Haiku, but if you were holding out for something more stable: Haiku has just released its fifth beta, Haiku R1/beta5. We’ve covered most of the new features and changes as they were developed, but since it’s been so long since the previous beta, we should cover some of the highlights.

One of the collection of improvements that’s impossible to put in a screenshot is the performance improvements the successor to BeOS has received since the release of R1/beta4, and there are many. There’s a ton of general performance improvements, of course, covering everything from the kernel to applications, including much better throughput in TCP, the network stack, which should lift Haiku’s network performance much closer to that of other, more mature operating systems. There’s also an overhaul of the user_mutex system, and much more.

A great many performance optimizations were done to the kernel and drivers, including batching many more I/O operations, avoiding unnecessary locks on application startup, improved pre-mapping of memory mapped files, reduced lock contention in page mapping, batched modification of the global memory areas table (and a different implementation of its underlying data structure), changes to keep page lists in-order to ease allocations, temporary buffer allocation performance improvements in hot I/O paths, support for DT_GNU_HASH in the ELF loader, and more.

↫ Haiku R1/beta5 release notes

Looking at the end user side of things, the Appearance dialog has been simplified without removing any features or capabilities, and Haiku now also comes with a dark mode. The little power/battery widget in Deskbar has also been overhauled to provide more accurate battery information, and it’ll load automatically if a battery is detected in the system. Tracker (the file manager) and Icon-O-Matic have seen improvements, there’s a rewritten FAT driver, a brand new UFS2 driver, and much more.

There’s also a ton of new application ports from the Qt and GTK world, especially if the last time you’ve tried Haiku was one of the previous betas. Thanks to all of these ports, it’s much more realistic now to use Haiku as a daily driver. Haiku now also offers experimental support for .NET and FLTK, which provides further avenues for ports.

This is just a small selection, as there is so much more contained in this new beta release. If you’ve been running the nightlies this new beta won’t mean much to you, but if you’ve been out of the running for a while, Haiku R1/beta5 is a great place to start to see what the platform has to offer.

To empower tablet users to get more done, we’re enhancing freeform windowing, allowing them to run multiple apps simultaneously and resize windows for optimal multitasking. Today, we’re excited to share that desktop windowing on Android tablets is available in developer preview.

For app developers, the concept of Android apps running in freeform windows has already existed with solutions like Samsung DeX and ChromeOS. Updating your apps to support adaptive layouts, more robust multitasking, and adaptive inputs will ensure your apps work well on large screens across the Android ecosystem.

↫ Francesco Romano on the Android Developers Blog

The long-running saga of Google trying to develop proper freeform windowing support for Android seems to finally be bearing fruit. Countless attempts came and went, usually in developer releases, hidden behind flags, rarely, if ever talked about, but now it’s finally not only part of an Android beta release anyone with a Pixel Tablet can install and try out, Google is also openly talking about and touting it as a feature, so we might actually perhaps maybe see this in a non-beta release at some point.

The way it works is both surprising and rather unsurprising. Instead of the Apple approach, which seems to entail a deep disdain for traditional windowing, Google is pretty much embracing the things we expect a windowing system to have, from window titlebars with close and maximise widgets, to a traditional dock-like taskbar permanently available at the bottom of the screen. If you click or tap on a little downward arrow on the titlebar, you can choose options like displaying windows side-by-side, much like on Windows. A very welcome ‘feature’ is the ability to tear off Chrome tabs and turn them into their own windows, just like in a traditional desktop environment.

Google also opted for an interesting approach that reminds me somewhat of the “desktop” mode on Windows RT. Since Windows RT was ARM-based and entirely locked-down, the only classic Win32 applications you could run were those bundled with Windows as well as Microsoft Office. To access these, Windows RT would launch a full-screen tablet application that contained the entire traditional Windows desktop, and you’d run your classic Win32 applications in there.

Android’s new windowing system seems to be doing something similar: once you enter the freeform windowing mode, all future applications will also launch as windows. In the task switcher, however, they’re all contained within a single “desktop” entry that you can close if you want to. That desktop entry seems to take the shape of a live view of the “desktop”, including the various windows you have opened. This way, you can have a dedicated “desktop” with freeform windows alongside any fullscreen tablet applications you also happen to be running. It’s perhaps not the most integrated or elegant approach, but it’s dead-simple and easy to grasp.

This new windowing environment also provides application developers with the option of allowing multiple instances of a single application to be launched, say launching two text editor windows side-by-side. This seems to be a specific property developers need to enable, though, and considering Android’s tablet adoption history, that’s anything but a given at this point. Of course, it shouldn’t come as a surprise that applications need to be able to resize gracefully, too.

If you want to play with it, you’ll need a Pixel Tablet running Android 15 QPR1 Beta 2, or just use the simulator. I really hope this takes off and developers support the various APIs for optimal integration (I’m not getting my hopes up), since proper freeform windowing that doesn’t feel like an ugly, barely functional hack is something I’ve been wanting on Android for a long time.

It seems Google is hell-bent on removing anything from Android that makes the platform stand apart from iOS. One of the features of Android and the Play Store that users of rooted and/or de-Googled phones will be familiar with is SafetyNet Attestation, something that Android applications can use to check, among other things, if the device it’s running on is rooted or not, and take any action from there based on that information. Notoriously, some banking applications on Android will refuse to work on rooted and/or de-Googled devices because of this.

Earlier this year, at Google I/O, the company unveiled the successor of SafetyNet Attestation, called the Google Play Integrity API, and it comes with a whole lot more functionality for developers to control what their application can do on devices based on the status of the device and the application binary in question. Play Integrity will let the developer’s application know if its binary has been tampered with, if Google Play Protect is enabled, if the Android device it’s running on is “genuine”, and a whole lot more.

Based on that information, the application could decide to warn users when they’re about to do something sensitive that their device is rooted, or it could just throw up its hands entirely and refuse to function at all – and there’s really not much the user can do about this. A new capability of the Play Integrity API is that developers can now also determine where it came from – i.e., if it was sideloaded or installed through a non-Play application store – and then throw up a dialog allowing the user to switch to the version from the Play Store instead. Doing so will delete the original binary and all its data, and replace it with the Play Store version.

The problem here is that the only other option is to cancel, and not have the application load at all.

As you can see, the remediation dialog tells you to “get this app from Play” in order to continue using it. There’s an option to close the dialog, but there’s no way to bypass it entirely. If you close the dialog, a response is sent to the app that lets the developer know so they can decide whether to continue blocking access.

↫ Mishaal Rahman at Android Authority

Several applications appear to already be using this new capability, and while it won’t mean much for people running Google’s, Samsung’s, or any other “blessed by Google” version of Android on unrooted devices, people running, say, /e/OS, GrapheneOS, LineageOS, or any other de-Googled and/or rooted device is going to be having a very bad time if more and more applications adopt this capability. If you’re running a device without Play Services, relying solely on the vast and varied library of applications from F-Droid, for instance, while also sideloading a few applications only available in the Play Store, you could very well be running into problems.

We’ll have to see just how widespread this capability becomes, but I can already foresee this becoming yet another major headache for anyone trying to use a smartphone that isn’t from blessed by Apple or Google. Personally, I’m lucky in that Swedish banking and ID applications worked on de-Googled Android phones, but with the expanding reach of the Play Integrity API, as well as possible “let’s enable this by default” shenanigans by Google, I’m definitely worried about this remaining so in the future.

This summer, I embarked on a side project to create a brand-new Palm OS game, and after less than two months of intermittent coding, I’m excited to announce that it’s ready to be released to the public!

↫ Captain’s Quarters

The game in question is a top-down minigolf game, and works on devices running Palm OS 3.5 and higher, in both monochrome and colour, and there’s high-resolution support for devices running Palm OS 5.0 and higher. Sadly, my own Palm OS devices were all drained of battery so I couldn’t quickly load it up and play it on real hardware in time for this post (rest assured, my T|X is currently charging), but you can play it in your browser if you want to. Like any other top-down minigolf game, it’s simple and fun to play.

The game’s creator, whose real name I can’t find so I’ll just refer to them by their blog’s name Captain’s Quarters, also wrote a published a post about the process of developing a Palm OS game in 2024. Especially the section on what is needed to code for Palm OS today is important if you’re also interested in picking this up.

The best news is that developing a Palm OS game can be done on modern hardware, that saves me a lot of time not having to deal with virtual machines or having to set up an old PC running Linux.

For getting a working compiler, I used prc-tools-remix, which is the same old compiler as in the old days, but it’s updated to work on a modern day Linux or OS X system.

↫ Captain’s Quarters

People in general are often oblivious to just how advanced and capable both Palm OS and Windows PocketPC PDAs really were – most people never had one – and even more people are oblivious to just how vibrant the gaming scene on Palm OS was. My Palm OS devices were some of the best gaming handhelds I’ve ever had, and my love for jewel-matching games still goes strong today on Android, but it all started on Palm OS, the original mobile home of the original Bejeweled. Palm OS games got me through quite a few boring lectures and classes in university.