Windows NT 4.0 ported to run on certain Apple PowerPC Macs

The most fascinating time for Windows NT were its first few years on the market, when the brand new operating system supported a wide variety of architectures, from default x86, all the way down to stuff like Alpha, MIPS, and exotic things like Intel i860, and even weirder stuff like Clipper (even a SPARC port was planned, but never released). One of the more conventional architectures that saw a Windows NT port – one that was actually released to the public, no less – was PowerPC. The last version of Windows NT to support exotic architectures was 4.0, with Windows 2000 only supporting x86, dropping everything else, including PowerPC (although Windows 2000 for Alpha reached RC1 status).

The PowerPC version of Windows NT only supported IBM and Motorola systems using the PowerPC Reference Platform, and never the vastly more popular PowerPC systems from Apple. Well, it’s 2024, and that just changed: Windows NT 4.0 can now be installed and run on certain Apple New World Power Macintosh systems.

This repository currently contains the source code for the ARC firmware and its loader, targeting New World Power Macintosh systems using the Gossamer architecture (that is, MPC106 “Grackle” memory controller and PCI host, and “Heathrow” or “Paddington” super-I/O chip on the PCI bus).

[…]

NT4 only, currently. NT 3.51 may become compatible if HAL and drivers get ported to it. 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.)

↫ maciNTosh GitHub page

This is absolutely wild, and one of the most interesting projects I’ve seen in a long, long time. The deeply experimental nature of this effort does mean that NT 4.0 is definitely not stable on any of the currently supported machines, and the number of drivers implemented is the absolute bare minimum to run NT 4.0 on these systems. It does, however, support dual-booting both NT 4.0 and Mac OS8, 9, and X, which would be quite something to set up.

I’m not definitely going to keep an eye on eBay for a supported machine, because running NT on anything other than x86 has always been a bit of a weird fascination for me. Sadly, period-correct PowerPC machines that support NT are extremely rare and thus insanely expensive, and will often require board-level repairs that I can’t perform. Getting a more recent Yikes PowerMac G4 should be easy, since those just materialise out of thin air randomly in the world.

I’m incredibly excited about this.

    Package AmigaOS software for Linux and Windows with AxRuntime

    This solution lets developers compile their Amiga API-based applications as Linux binaries. Once the features are implemented, tested and optimized using the runtime on Linux or Windows, developers re-compile their applications for their Amiga-like system of choice and perform final quality checking.

    Applications created with AxRuntime can be distributed to Linux or Windows communities, giving developers a much broader user base and a possibility to invite developers from outside general Amiga community to contribute to the application.

    ↫ AxRuntime website

    I had never considered this as an option, but with AmigaOS 3.x basically being frozen in time, it’s a relatively easy target for an effort such as this. It won’t surprise you to learnt hat AxRuntime is using code from AROS, which itself is fully compatible with AmigaOS 3.1. This should technically mean that any AmigaOS application that runs on AROS should be able to be made to run using this runtime, which is great news for Amiga developers.

    Why? Well, the cold, harsh truth is that the number of Amiga users is probably still dwindling as the sands of time cause people to, well, die, and the influx of new users, who also happen to possess the skillset to develop AmigaOS software, must be a very, very slow trickle, at best. This runtime will allow AmigaOS developer to package their software to run on Linux and Windows machines, getting a lot more eyes on the software in the process. Amiga devices are not exactly cheap or easy to come by, so this is a great alternative.

    Google is ending support for Lacros, the experimental version of Chrome for ChromeOS

    Back in August 2023, we previewed our work on an experimental version of Chrome browser for ChromeOS named Lacros. The original intention was to allow Chrome browser on Chromebooks to swiftly get the latest feature and security updates without needing a full OS update.

    As we refocus our efforts on achieving similar objectives with ChromeOS embracing portions of the Android stack, we have decided to end support for this experiment. We believe this will be a more effective way to help accelerate the pace of innovation on Chromebook.

    ↫ ChromeOS Beta Tester Community

    To refresh your memory, Lacros was an attempt by Google to decouple the Chrome browser from ChromeOS itself, so that the browser could be updated indepdnently from ChromeOS as a whole. This would obviously bring quite a few benefits with it, from faster and easier updates, to the ability to keep updating the Chrome browser after device support has ended. This was always an experimental feature, so the end of this experiment really won’t be affecting many people.

    The interesting part is the reference to the recent announcement that ChromeOS’ Linux kernel and various subsystems will be replaced by their Android counterparts. I’m not entirely sure what this means for the Chrome browser on ChromeOS, since it seems unlikely that they’re going to be using the Android version of Chrome on ChromeOS. It’s generally impossible to read the tea leaves when it comes to whatever Google does, so I’m not even going to try.

    Ubuntu security updates are a confusing mess

    I’ve read this article several times now, and I’m still not entirely sure how to properly summarise the main points without leaving important details out. If you really boil it down to the very bare essentials, which packages get updates on which Ubuntu release is a confusing mess that most normal users will never be able to understand, potentially leaving them vulnerable to security flaws that have already been widely patched and are available on Ubuntu – just not your specific Ubuntu version, your specific customer type, or the specific package type in question.

    So, in the case of McPhail here, they needed a patched version of tomcat 9 for Ubuntu 22.04. This patched version was available for Ubuntu 18.04 users because not only is 18.04 an LTS release – meaning five years of support – Canonical also offers a commercial Extended Security Maintenance (ESM) subscription for 18.04, so if you’re paying for that, you get the patched tomcat9. On Ubuntu 20.04, another LTS release, the patched version of tomcat9 is available for everyone, but for the version McPhail is running, the newer LTS release 22.04, it’s only available for Ubuntu Pro subscribers (24.04 is not affected, so not relevant for this discussion). Intuitively, this doesn’t make any sense.

    The main cause of the weird discrepancy between 20.04 and 22.04 is that Canonical’s LTS support only covers the packages in main (about 10% of the total amount of packages), whereas tomcat9 lives in universe (90% of packages). LTS packages in universe are only supported on a “best effort” basis, and one of the ways a patched universe package can be made available to non-paying LTS users is if it is inhereted from Debian, which happens to be the case for tomcat9 in 20.04, while in 22.04, it’s considered part of an Ubuntu Pro subscription.

    So, there’s a fixed package, but 22.04 LTS users, who may expect LTS to truly mean LTS, don’t get the patched version that exists and is ready to go without issues. Wild.

    This is incredibly confusing, and would make me run for the Debian hills before my next reboot. I understand maintaining packages is a difficult, thankless task, but the nebulousness here is entirely of Canonical’s own making, and it’s without a doubt leaving users vulnerable who fully expect to be safe and all patched up because they’re using an LTS release.

    Qualcomm’s Oryon core: a long time in the making

    In 2019, a startup called Nuvia came out of stealth mode. Nuvia was notable because its leadership included several notable chip architects, including one who used to work for Apple. Apple chips like the M1 drew recognition for landing in the same performance neighborhood as AMD and Intel’s offerings while offering better power efficiency. Nuvia had similar goals, aiming to create a power efficient core that could could surpass designs from AMD, Apple, Arm, and Intel. Qualcomm acquired Nuvia in 2021, bringing its staff into Qualcomm’s internal CPU efforts.

    Bringing on Nuvia staff rejuvenated Qualcomm’s internal CPU efforts, which led to the Oryon core in Snapdragon X Elite. Oryon arrives nearly five years after Nuvia hit the news, and almost eight years after Qualcomm last released a smartphone SoC with internally designed cores. For people following Nuvia’s developments, it has been a long wait.

    ↫ Chips and Cheese

    Now that the Snapdragon X Elite and Pro chips are finally making their way to consumers, we’re also finally starting to see proper deep-dives into the brand new hardware. Considering this will set the standard for ARM laptops for a long time to come – including easy availability of powerful ARM Linux laptops – I really want to know every single quirk or performance statistic we can find.

    Iconography of the X Window System: the boot stipple

    For the uninitiated, what are we looking at? Could it be the Moiré Error from Doom? Well, no. You are looking at (part of) the boot up screen for the X Window System, specifically the pattern it uses as the background of the root window. This pattern is technically called a stipple.

    What you’re seeing is pretty important and came to symbolize a lot for me as a computer practitioner.

    ↫ Matt T. Proud

    The X bootup pattern is definitely burnt onto my retina, as it probably is for a lot of late ’90s, early 2000s Linux users. Setting up X correctly, and more importantly, not breaking it later, was almost an art at the time, so any time you loaded up your PC and this pattern didn’t greet you, you’d get this sinister feeling in the pit of your stomach. There was now a very real chance you were going to have to debug your X configuration file, and nobody – absolutely nobody – liked doing that, and if you did, you’re lying.

    Matt T. Proud dove into the history of the X stipple, and discovered it’s been part of X since pretty much the very beginning, and even more esoteric X implementations, like the ones used by Solaris or the various commercial versions, have the stipple. He also discovered several other variants of the stipple included in X, so there is a chance your memory might be just a tiny bit different.

    The stipple eventually disappeared at around 2008 or so, it disappeared as part of the various efforts to modernise, sanitise, and speed up the Linux boot process on desktops. On modern distributions still using X, you won’t encounter it anymore by default, but in true X fashion, the code is still there and you can easily bring it back using a flag specifically designed for it, -retro, that you can use with startx or your X init file.

    There’s a ton more information in Proud’s excellent article, but this one paragraph made me smile:

    I will remark that in spite of my job being a software engineer, I had never spent a lot of time looking at the source code for the X Server (XFree86 or X.Org) before. It’s really nuts to see that a lot of the architecture from X10R3 and X11R1 still persists in the code today, which is a statement that can be said in deep admiration for legacy code but also disturbance from the power of old decisions. Without having looked at the internals of any Wayland implementation, I can sympathize sight unseen with the sentiments that some developers have toward the X Window System: the code is a dead end. I say that with the utmost respect to the X Window System as a technology and an ecosystem. I’ll keep using X, and I will be really sad when it’s no longer possible for me to do so for one reason or another, as I’m extremely attached to it quirks. But it’s clear the future is limited.

    ↫ Matt T. Proud

    We all have great – and not so great – memories of X, but I am really, really happy I no longer have to use it.

    Palestinians say Microsoft unfairly closing their accounts

    Palestinians living abroad have accused Microsoft of closing their email accounts without warning – cutting them off from crucial online services.

    They say it has left them unable to access bank accounts and job offers – and stopped them using Skype, which Microsoft owns, to contact relatives in war-torn Gaza.

    Microsoft says they violated its terms of service – a claim they dispute.

    ↫ Mohamed Shalaby and Joe Tidy at the BBC

    Checking up on your family members to see if they survived another day of an ongoing genocide doesn’t seem like something that should be violating any terms of any services, but that’s just me.

    “Majority of websites and mobile apps use dark patterns”

    A global internet sweep that examined the websites and mobile apps of 642 traders has found that 75,7% of them employed at least one dark pattern, and 66,8% of them employed two or more dark patterns.

    Dark patterns are defined as practices commonly found in online user interfaces and that steer, deceive, coerce, or manipulate consumers into making choices that often are not in their best interests.

    ↫ International Consumer Protection and Enforcement Network

    Dark patterns are everywhere, and it’s virtually impossible to browse the web, use certain types of services, or install mobile applications, without having to dodge and roll just to avoid all kinds of nonsense being thrown at you. It’s often not even ads that make the web unusable – it’s all the dark patterns tricking you into viewing ads, entering into a subscription, enabling notifications, sharing your email address or whatever, that’s the real reason.

    This is why one of the absolute primary demands I have for the next version of OSNews is zero dark patterns. I don’t want any dialogs begging you to enable ads, no modal windows demanding you sign up for a newsletter, no popups asking you to enable notifications, and so on – none of that stuff. My golden standard is “your computer, your rules”, and that includes your right to use ad blockers or anything else to change the appearance or functioning of our website on your computer.

    It’d be great if dark patterns became illegal somehow, but it would be incredibly difficult to write any legislation that would properly cover these practices.

    AmigaKit launches a new Amiga that’s not an Amiga at all

    I try to keep tabs on a huge number of operating system projects out there – for obvious reasons – but long ago I learned that when it comes to the world of Amiga, it’s best to maintain distance and let any important news find its way out of the Amiga bubble, lest one loses their sanity. Keeping up with the Amiga world requires following every nook and cranny of various forums and websites with different allegiances to different (shell) companies, with often barely coherent screeching and arguments literally nobody cares about.

    It’s a mess is what I’m trying to say.

    Anyway, it seems one of the many small companies still somehow making a living in the Amiga world, AmigaKit, has recently released a new device, the A600GS. It’s a retrogaming-oriented Amiga computer, but it does come with something called AmiBench, that’s apparently a weird hybrid between bits of Amiga OS 4 and AROS, so it does also support running a proper desktop and associated applications, but only AmigaOS 3.x applications (I think? It’s a bit unclear). It has HDMI at up to 1080p, and even WiFi and Bluetooth support, which is pretty neat.

    Wait, Wifi and Bluetooth support? What are we really dealing with here? Once again the information is hard to find because AmigaKit is incredibly stingy with specifications – I had to read goddamn YouTube comments to get some hints – but it seems to be a custom board with an Orange Pi Zero 3 stuck on top doing most of the work. In other words, the meat of this thing is just an emulator, which in and of itself isn’t a bad thing, it’s just weird to me that they’re not upfront and direct about this.

    While this answers some questions, it also raises a whole bunch more. If this is running on low-end Allwinner ARM hardware from 2022, how is this AmiBench desktop environment (or operating system?) a “fork of OS4 with AROS code in it“? AmigaOS 4 is PowerPC-only, which may explain why AmigaKit only mentions AmigaOS 3.x and 68K compatibility, and not AmigaOS 4 compatibility. And what’s AROS doing in there?

    I mean, this is an interesting product in the sense that it’s a relatively cheap turnkey solution for classic Amiga enthusiasts, but a new Amiga this is definitely not. At about €130, this is not a bad deal, but other than hardcore fans of the classic 68K Amiga, I don’t see many people being interested in this. The Apollo Standalone V4+ piques my interest way more, but at €700-800, it’s also a lot more expensive, but at least they’re much clearer about what the Apollo is, what software it’s running, and that they’re giving back their work to AROS.

    “I fixed a 6-year-old .deb installation bug in Ubuntu MATE and Xubuntu”

    I love a good bug hunting story, and this one is right up there as a great one. Way back in 2018, Doug Brown discovered that after installing Ubuntu MATE 18.04, if he launched Firefox from the icon in the default panel arrangement to install Chrome from the official Chrome website, the process was broken. After downloading the .deb and double-clicking it, GDebi would appear, but after clicking “Install”, nothing happened.

    What was supposed to happen is that after clicking “Install”, an authentication dialog should appear where you enter your root password, courtesy of gksu. However, this dialog did not appear, and without thinking too much of it, Brown shrugged and just installed the downloaded Chrome .deb through the terminal, which worked just fine. While he didn’t look any deeper into the cause of the issue, he did note that as the years and new Ubuntu releases progressed, the bug would still be there, all the way up until the most recent release.

    Finally, 2.5 years ago, he decided to dive into the bug. It turned out there were lots of reports about this issue, but nobody stepped up to fix it. While workarounds were made available through wrapper scripts, and deeper investigations into the cause revealed helpful information. The actual error message was a doozy: “Refusing to render service to dead parents”, which is quite metal and a little disturbing.

    In summary, the problem was that GDebi was using execv() to replace itself with an instance of pkexec, which was intended to bring up an authentication dialog and then allow GDebi to run as a superuser. pkexec didn’t like this arrangement, because it wants to have a parent process other than init. Alkis mentioned that you could recreate the problematic scenario in a terminal window by running gdebi-gtk with setsid to run it in a new session.

    ↫ Doug Brown

    Backing up a few steps, if the name “gksu” rings a bell for you, you might have already figured out where the problem most likely originated from. Right around that time, 2018, Ubuntu switched to using PolicyKit instead, and gksu was removed from Ubuntu. GDebi was patched to work with PolicyKit instead, and this was what introduced the actual bug.

    Sadly, despite having a clear idea of the origin of the bug, as well as where to look to actually fix it, nobody picked it up. It sat there for years, causing problems for users, without a fix in sight. Brown was motivated enough to fix it, submitted the patch, but after receiving word it would be looked at within a few days, he never heard anything back for years, not helped by the fact that GDebi has long been unmaintained. It wasn’t until very recently that he decided to go back again, and this time, after filling out additional information required for a patch for an unmaintained package, it was picked up, and will become available in the next Ubuntu release (and will most likely be backported, too).

    Brown further explains why it took so long for the bug to be definitely fixed. Not only is GDebi unmaintained, the bug also only manifested itself when launching Firefox from the panel icon – it did not manifest when launching Firefox from the MATE menu, so a lot of people never experienced it. On top of that, as we all sadly know, Ubuntu replaced the Firefox .deb package with the SNAP version, which also doesn’t trigger the bug.

    It’s a long story for sure, but a very interesting one. It shows how sometimes, the stars just align to make sure a bug does not get fixed, even if everyone involved knows how to fix it, and even if fixes have been submitted. Sometimes, things just compound to cause a bug to fall through the cracks.

    Google extends Linux kernel support to keep Android devices secure for longer

    Android, like many other operating systems, uses the open-source Linux kernel. There are several different types of Linux kernel releases, but the type that’s most important to Android is the long-term support (LTS) one, as they’re updated regularly with important bug fixes and security patches. Starting in 2017, the support lifetime of LTS releases of Linux was extended from two years to six years, but early last year, this extension was reversed. Fortunately, Google has announced that moving forward, they’ll support their own LTS kernel releases for four years. Here’s why that’s important for the security of Android devices.

    ↫ Mishaal Rahman at Android Authority

    I fully support the Linux kernel maintainers dropping the LTS window from six to two years. The only places where such old kernels were being used were embedded devices and things like smartphones vendors refused to update to newer Android releases, and it makes no sense for kernel maintainers to be worrying about that sort of stuff. If an OEM wants to keep using such outdated kernels, the burden should be on that OEM to support that kernel, or to update affected devices to a newer, supported kernel.

    It seems Google, probably wisely, realised that most OEMs weren’t going to properly upgrade their devices and the kernels that run on them, and as such, the search giant decided to simply create their own LTS releases instead, which will be supported for four years. Google already maintains various Android-specific Linux kernel branches anyway, so it fits right into their existing development model for the Android Linux kernel.

    Some of the more popular OEMs, like Google itself or Samsung, have promised longer support life cycles for new Android versions on their devices, so even with this new Android-specific LTS policy, there’s still going to be cases where an OEM will have to perform a kernel upgrade where they didn’t have to before with the six year LTS policy. I wonder if this is going to impact any support promises made in recent years.

    Mozilla opts to extended Windows 7/8/8.1 support

    Among them, Byron Jourdan, Senior Director, Product Management of Mozilla, under the Reddit username ComprehensiveDoor643 revealed that Mozilla plans to support Firefox on Windows 7 for longer. When asked separately about whether it also included Windows 8 and 8.1 too, Jourdan added that it was certainly the plan, though for how long the extended support would last was still undecided.

    ↫ Sayan Sen at Neowin

    Excellent move by Mozilla. I doubt there’s that many new features and frameworks in Windows 10 or 11 that are absolutely essential to Firefox working properly, so assuming it can gracefully disable any possible Windows 10/11-exclusive features, it should be entirely possible to use Firefox as an up-to-date, secure, and capable browser on Windows 7/8.x.

    Windows 7 and 8.x users still make up about 2.7% of Windows users worldwide, and with Windows’ popularity, that probably still translates to millions and millions of people. Making sure these people have access to a safe and secure browser is a huge boon, and I’m very happy Mozilla is going to keep supporting these platforms as best they can, at least for now.

    For those of us who already consider especially Windows 7 a retrocomputing platform – I sure do – this is also great news, as any retro box or VM we load up with it will also get a modern browser. Just excellent news all around.

    No more boot loader: please use the kernel instead

    Most people are familiar with GRUB, a powerful, flexible, fully-featured bootloader that is used on multiple architectures (x86_64, aarch64, ppc64le OpenFirmware). Although GRUB is quite versatile and capable, its features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes. On the other hand, the Linux kernel, which has a large developer base, benefits from fast feature development, quick responses to vulnerabilities and greater overall scrutiny.

    We (Red Hat boot loader engineering) will present our solution to this problem, which is to use the Linux kernel as its own bootloader. Loaded by the EFI stub on UEFI, and packed into a unified kernel image (UKI), the kernel, initramfs, and kernel command line, contain everything they need to reach the final boot target. All necessary drivers, filesystem support, and networking are already built in and code duplication is avoided.

    ↫ Marta Lewandowska

    I’m not a fan of GRUB. It’s too much of a single point of failure, and since I’m not going to be dual-booting anything anyway I’d much rather use something that isn’t as complex as GRUB. Systemd-boot is an option, but switching over from GRUB to systemd-boot, while possible on my distribution of choice, Fedora, is not officially supported and there’s no guarantee it will keep working from one release to the next.

    The proposed solution here seems like another option, and it may even be a better option – I’ll leave that to the experts to discuss. It seems like to me that the ideal we should be striving for is to have booting the operating system become the sole responsibility of the EUFI firmware, which usually already contains the ability to load any operating system that supports UEFI without explicitly installing a bootloader. It’d be great if you could set your UEFI firmware to just always load its boot menu, instead of hiding it behind a function key or whatever.

    We made UEFI more capable to address the various problems and limitations inherent in BIOS. Why are we still forcing UEFI to pretend it still has the same limitations?

    Design and build the next version of OSNews

    Despite being live since 1997, OSNews has had fairly few redesigns in the grand scheme of things. If my memory serves me correctly, we’ve had a grand total of 6 designs, and we’re currently on version 6, introduced about 5 years ago because of unpleasant reasons. It’s now 2024, and for a variety of reasons, we’re looking to work towards version 7 of our almost 30 year old website, and we need help.

    I have a very clear idea of what I want OSNews 7 to be like – including mockups. The general goals are making the site visually simpler, reducing our dependency on WordPress extensions, and reducing the complexity of our theme and website elements to make it a bit easier for someone like me to change small things without breaking anything. Oh and a dark mode that works. Note that we’re not looking to change backends or anything like that – WordPress will stay.

    If you have the WordPress, design, and developer skills to make something like this a reality, and in the process shape the visual identity of one of the oldest continuously running technology news websites in the world, send me an email.

    Getting the most out of TWM, X11’s default window manager

    Graham’s TWM page has been around for like two decades or so and still isn’t even remotely as old as TWM itself, and in 2021 they published an updated version with even more information, tips, and tricks for TWM. The Tab Window Manager finds its origins in the lat 1980s, and has been the default window manager for the X Windowing System for a long time, now, too. Yet, few people know it exists – how many people even know X has a default window manager? – and even fewer people know you can actually style it, too.

    OK, so TWM is fairly easy to configure but alot of people, upon seeing the default config, scream ‘Ugh, thats awful!’ and head off to the ports tree or their distro sources in search of the latest and greatest uber desktop environment.

    There are some hardcore TWM fans and mimimalists however who stick around and get to liking the basic feel of TWM. Then they start to mod it and create their own custom dekstop. All part of the fun in Unix :).

    ↫ Graham’s TWM page

    I’ll admit I have never used TWM properly, and didn’t know it could be themed at all. I feel very compelled to spend some time with it now, because I’ve always liked the by-now classic design where the right-click desktop menu serves as the central location for all your interactions with the system. There are quite a few more advanced, up-to-date forks of TWM as well, but the idea of sticking to the actual default X window manager has a certain charm.

    I almost am too afraid to ask, because the answer on OSNews to these sorts of questions is almost always “yes” – do we have any TWM users in the audience? I’m extremely curious to find out if TWM actually has a reason to exist at this point, or if, in 2024, it’s just junk code in the X.org source repository, because I’m looking at some of these screenshots and I feel a very strong urge to give it a serious go.

    A brief summary of click-to-raise and drag-and-drop interaction on X11 and Wayland

    The goal is to be able to drag an icon from a background window without immediately raising that window and obscuring the drop target window when using the click-to-focus mode. This is a barebones description of what needs to happen. It assumes familiarity with code, protocols, etc. as needed.

    ↫ Quod Video

    The articles describes how to get there using both X and Wayland, and it’s clear there’s still quite a bit of work to do. At least on my KDE Wayland setups, the way it works now is that when I click to drag an icon from a lower Dolphin window to a higher one, it brings the lower window forward, but then, when I hover for a bit over the other window, it brings it back up. Of course, this only works if the destination window remains at least partially visible, which might not always be the case.

    For usability’s sake, there needs to be an option to start a drag operation from one window to the next without altering the Z-order.

    Android 15 could include a desktop mode — but what for?

    If there was ever a “will they, won’t they?” love story in mobile computing, it’s definitely Google’s on and off again relationship with Android’s desktop mode. There have been countless hints, efforts, and code pertaining to the mythical desktop mode for Android, but so far, Google has never flipped the switch and made it available. It’s 2024, Android 15 development is in full swing, and it seems Google and Android’s desktop mode are dating again.

    This past spring, Google added DisplayPort support to the Pixel 8 and Pixel 8 Pro in a Feature Drop update, allowing for easy wired connections to external monitors. Then, tinkering in Android 14 QPR3 Beta 2.1, Mishaal Rahman was able to get a new desktop interface up and running, complete with Android apps running in resizeable floating windows. It’s not confirmed that Android 15 will ship with a built-in desktop mode, but the bones are there. It does make me wonder, though: why? What would a desktop interface add to Android?

    ↫ Taylor Kerns at Android Police

    I’m actually fairly convinced Android could, indeed, serve as an excellent desktop operating system, but without any official backing by Google, it’s always been a massive hack to use Android with a mouse and keyboard. It’s not so much the hardware support – it’s all there – but rather the software support, and the clunky way common Android UI tasks feel when performing them with a mouse. I’ve installed Android desktop ‘distributions’ countless times, and the third-party hacks they use, like clunky taskbars and custom menus and so on, make for a horrid user experience.

    Samsung DEX seems to be the only somewhat successful attempt at adding a desktop mode to Android, but it can’t be installed on any regular PC or laptop, and requires cumbersome cabling or expensive docks, making it more of a curiosity than a true desktop mode in the sense most of us are thinking of. This feature needs to come from Google itself, and it needs to be something third parties can use in their ROMs and x86 builds so we can truly use Android on a desktop.

    I don’t believe that’s going to happen, though. It’s clear Google is more interested in pushing Chrome OS for desktop and laptop use, and it seems more likely that any desktop mode that gets added to Android is going to be similar in nature to DEX – something you can only use by hooking up your phone to a display and configuring wireless input devices. Cool, but not exactly something that will turn Android into a desktop contender.

    Google is bringing Fuchsia OS to Android devices, but not in the way you’d think

    To evolve Fuchsia beyond smart home devices, Google has been working on projects such as Starnix to run unmodified Linux binaries on Fuchsia devices. In addition, since late April of this year, Google has been working on a new project called “microfuchsia” that aims to make Fuchsia bootable on existing devices via virtualization. Microfuchsia, according to Google, is a Fuchsia OS build that targets virtual machines and is designed to be bootable in virtualization solutions such as QEMU and pKVM.

    ↫ Mishaal Rahman at Android Authority

    The goal here might be, according to Mishaal Rahman, might be to use this new microfuchsia thing to replace the stripped-down Android version that’s currently being used inside Android’s pKVM to run certain secured workloads. Relevant patches have been submitted to both the Fuchsia and Android side of things for this very purpose.

    At this point, it really seems that Google’s grand ambitions with Fuchsia simply didn’t survive the massive employee culling, with leadership probably reasoning that Android and Chrome OS are good enough, and that replacing them with something homegrown and possibly more suited – speculation, of course – simply isn’t worth the investment in both time and money.

    It probably makes sense from a financial standpoint, but it’s still sad.

    Apple bows to Russian censorship once more, removes VPN apps from Russian App Store

    A few weeks ago, I broke the news that Mozilla had removed several anti-censorship Firefox extensions from its store in Russia, and a few days later I also broke the news they reversed course on their decision and reinstated the extensions. Perhaps not worthy of a beauty prize, as a Dutch saying goes, but at least the turnaround time was short, and they did the right thing in the end.

    Well, let’s see how Apple is going to deal with the exact same situation. Novaya Gazeta Europe reports that bowing under pressure from the same Russian censors that targeted Mozilla, the company has removed a whole slew of VPN applications used by Russians to evade the stringent totalitarian censorship laws in the warmongering nation.

    Apple has removed several apps offering virtual private network (VPN) services from the Russian AppStore, following a request from Roskomnadzor, Russia’s media regulator, independent news outlet Mediazona reported on Thursday.

    The VPN services removed by Apple include leading services such as ProtonVPN, Red Shield VPN, NordVPN and Le VPN. Those living in Russia will no longer be able to download the services, while users who already have them on their phones can continue using them, but will be unable to update them.

    ↫ Novaya Gazeta Europe

    Apple has a long history of falling in line with the demands from dictators and totalitarian regimes, and Russia is no stranger to telling Apple what to do. Earlier this year, Apple was ordered to remove an application developed by the team of the murdered opposition figure Alexey Navalny, and of course, Apple rolled over and complied. Much like Apple’s grotesque suck-up behaviour in China, This stands in stark contrast to Apple’s whining, complaining, and tantrums in the European Union.

    It seems Apple finds it more comfortable to operating under dictators than in democracies.