With the release of Android 16, Google changed how it developed Android. Development is now taking place behind closed doors, with the code dropped after the corresponding version has been released to Pixel devices. Well, it turns out this wasn’t the only thing Google has changed about Android development. As the developers of CalyxOS, a popular de-Googled Android ROM, dove into the Android 16 AOSP source code, they realised something very important was missing: the device-specific source code for modern Pixel devices.

Android 16 was released to AOSP yesterday but with a one big difference than typical releases: Google did not publish any device-specific source code for supported, modern Pixel devices. In previous years, Google released full device trees alongside new Android versions. This allowed developers to build and boot AOSP on Pixel hardware relatively easily. With Android 16, only the platform/framework code has been released. The device trees are missing, at least for now.

This means AOSP 16 cannot currently be built or run on any recent Pixel device easily just using official source. It’s unclear whether this is a delay or a policy change. Either way, it seriously disrupts custom ROM development and our porting efforts.

↫ CalyxOS on Reddit

If this is truly a policy change, it’s a big one that affects custom ROM developers considerably. Pixel devices were “special” among custom ROM developers because support for them was part of AOSP releases, so they were well-supported by projects like CalyxOS, GrapheneOS, and LineageOS, including all the hardware components, and with quick updates. Without access to the Pixel-specific source code for the Pixel 6 to Pixel 9a, these devices will now have to be treated like any other Android phone as far as ROM developers go, meaning it’ll take a lot more work and time to get them to work properly with new major Android releases.

Google did not announce this potential policy change, and this has some in the custom Android ROM community on edge. I’ve been talking to people in the custom ROM community, and the story goes that a few months ago, at least one of these communities was approached by a journalist who wanted to talk to them. This journalist claimed that Google intends to discontinue the Android Open Source Project, with the first step Google would take being no longer releasing the device-specific Pixel source code (something nobody knew would happen until yesterday). The fact that this first step has now become a reality lends some credence to the journalist’s claim that Google is discontinuing AOSP. However, since such tips are not uncommon, and since there was no way to verify, the custom ROM developers in question didn’t really know what to do with it.

During the writing of this article over the past 12 hours, Google itself has also responded to what is apparently a growing, now public concern in the wider Android community. Seang Chau, Google VP and GM of Android Platform, published a Tweet, disclaiming Google has any intentions to close up shop for AOSP.

We’re seeing some speculation that AOSP is being discontinued. To be clear, AOSP is NOT going away. AOSP was built on the foundation of being an open platform for device implementations, SoC vendors, and instruction set architectures.

AOSP needs a reference target that is flexible, configurable, and affordable – independent of any particular hardware, including those from Google. For years, developers have been building Cuttlefish (available on GitHub as the reference device for AOSP) and GSI targets from source. We continue to make those available for testing and development purposes.

↫ Seang Chau

This seems like a solid denial from Google, but it leaves a lot of room for Google to make a wide variety of changes to Android’s development and open source status without actually killing off AOSP entirely. Since Android is licensed under the Apache 2.0 license, Google is free to make “Pixel Android” – its own Android variant – closed source, leaving AOSP up until that point available under the Apache 2.0 license. This is reminiscent of what Oracle did with Solaris. Of course, any modifications to the Linux kernel upon which Android is built will remain open source, since the Linux kernel is licensed under the GPLv2.

If Google were indeed intending to do this, what could happen is that Google takes Android closed source from here on out, spinning off whatever remains of AOSP up until that point into a separate company or project, as potentially ordered during the antitrust case against Google in the United States. This would leave Google free to continue developing its own “Pixel Android” entirely as proprietary software – save for the Linux kernel – while leaving AOSP in the state it’s in right now outside of Google. This technically means “AOSP is not going away”, as Chau claims.

Of course, other parties would then be free to continue working on and contributing to AOSP, but AOSP itself would no longer benefit from the work done by Google. Again, this feels very similar to how illumos and OpenIndiana are built atop the last open source release of Solaris from 2010, without any of the additional work Oracle has done on Solaris since then. As you can tell, there’s a lot of speculation here, because even if all of this is true, it seems the ongoing court case and any rulings that come of it will play a major role in Google’s decision-making process.

The Android Open Source Project has been gutted over the years, with Google leaving more and more parts of it to languish, while moving a lot of code and functionality into proprietary components like Google Mobile Services and Google Play Services. Taking “Pixel Android” closed source almost feels like the natural next step in the process of gutting AOSP that’s been ongoing for well over a decade. As it stands today, a default AOSP installation requires a lot of additional components and applications before it can be considered a complete mobile operating system, and if it were to be spun off into a separate, non-Google project to which Google itself contributes nothing, its future seems quite uncertain.

My own perception is that this is just one of the courses of action Google is considering in light of potentially being forced to spin off Android as part of the antitrust case in the United States. I doubt any decisions have been made yet, but if they go through with it, it would allow Google to develop “Pixel Android” in such a way that it wouldn’t benefit any of their Pixel competitors, unless these competitors specifically opt to license “Pixel Android” – assuming Google would even offer such licensing options. Regardless, it seems the Android world might be in for a shock.

GNOME has announced it’ll be increasing its dependency on systemd, the popular init system used by most (popular) Linux distributions. While GNOME already had a few relatively inconsequential dependencies on systemd, it was effectively not a huge problem to run GNOME on operating systems that don’t have systemd, which most notably includes the various flavours of BSD. That’s going to change.

There’s going to be two changes, one of which is relatively minor, and one of which will pose much bigger problems. The minor change involves GDM becoming dependent on systemd’s userdb infrastructure in order to clean up a lot of GDM’s code involved in multi-seat setups and remote login. Currently, this works through a series of hacks that the GDM developers are going to clean up, switching to using systemd-userdb to “dynamically allocate user accounts, and then runs each login screen as a unique user”.

To aid non-systemd environments during this transition, GDM will get a temporary alternate code path that enables you to run GDM without systemd-userdb. So if you compile GDM against elogind, GDM will use an alternative trick to enable multiple graphical sessions under the same user. This trick will remain in place at least until GNOME 50, but its future after that is uncertain.

The second change is much more involved.

Next, the bigger change. Since GNOME 3.34, gnome-session uses the systemd user instance to start and manage the various GNOME session services. When systemd is unavailable, gnome-session falls back to a builtin service manager. This builtin service manager uses .desktop files to start up the various GNOME session services, and then monitors them for failure. This code was initially implemented for GNOME 2.24, and is starting to show its age. It has received very minimal attention in the 17 years since it was first written. Really, there’s no reason to keep maintaining a bespoke and somewhat primitive service manager when we have systemd at our disposal. The only reason this code hasn’t completely bit rotted is the fact that GDM’s aforementioned hacks break systemd and so we rely on the builtin service manager to launch the login screen.

Well, that has now changed. The hacks in GDM are gone, and the login screen’s session is managed by systemd. This means that the builtin service manager will now be completely unused and untested. Moreover: we’d like to implement a session save/restore feature, but the builtin service manager interferes with that. For this reason, the code is being removed.

↫ Adrian Vovk

Mitigating this change will be a lot more involved for operating systems that don’t use systemd, and the blog post goes into detail into what, exactly, needs to be done in systemd-less environments. There’s quite a few systemd components and other little tidbits that you will need to find or create alternatives for, and considering you’ll need to have all of it in place roughly by GNOME 50, roughly a year from now, I can imagine this causing quite a few headaches for platforms like the BSDs and Linux distributions using init systems other than systemd.

With these changes, GNOME further solidifies itself as a Linux desktop only – and lest anyone forget, that’s entirely within their right to do. Systemd haters can jump up and down all they want, but in the end, they have no right to demand that GNOME developers spend precious time and resources testing GNOME on and developing it for platforms that they themselves do not use. They’re clearly targeting the trifecta of Linux, system, and Wayland, and that’s their choice to make, not anyone else’s.

Still, if operating systems like OpenBSD and FreeBSD, or Linux distributions without systemd intend to continue offering a fully functional GNOME desktop, they’re going to have some work to do.

Xeneva is an operating system for both x86_64 and ARM64 architectures, built from the ground up. The Kernel is known as ‘Aurora’ with hybrid kernel design and the entire operating system is known as ‘Xeneva’.

↫ XenevaOS GitHub page

It’s remarkably complete, with driver loading and linking, up to SSE 3 support, USB3 and Intel HD audio support, networking, and a whole lot more of the basics that make up a modern complete operating system. On top of all this, it also has a compositing window manager, a desktop environment, a terminal with VT100 support, Freetype2 font rendering, and much more. It also comes with a few basic applications like a file manager, calculator, audio player, and so on.

It’s written in C (and some C++), and uniquely, can only be built in a Windows environment, something you don’t see very often. It definitely looks quite impressive.

Today, we’re bringing you Android 16, rolling out first to supported Pixel devices with more phone brands to come later this year. This is the earliest Android has launched a major release in the last few years, which ensures you get the latest updates as soon as possible on your devices.

Android 16 lays the foundation for our new Material 3 Expressive design, with features that make Android more accessible and easy to use.

↫ Seang Chau at the Google blog

Android 16 doesn’t seem like a very big release, and that’s because for most users, it really isn’t. There’s some neat features in here, like improved notification grouping, live notifications, a slew of protection features for people who run increased risk (think journalists or victims of abuse), and proper desktop-style windowing on tablets, which seems like the tentpole feature for now. The Material 3 Expressive design is not really here yet, though as that will come in subsequent Android 16 updates.

The release for devices coincides with the release of the source code, which is no longer released as part of the development process, but dumped across the fence at release time. This means that those of us using a de-Googled Android ROM – I use GrapheneOS – will have to wait a bit longer than we’re used to before getting the new version.

macOS Tahoe is the final software update that Intel-based Macs will get, as Apple works to phase them out following its transition to Apple silicon.

During its Platforms State of the Union event, Apple said that Intel Macs won’t get macOS 27, coming next year, though there could still be updates that add security fixes.

↫ Juli Clover at MacRumors

Not particularly surprising, but definitely not great for someone who bought one of those ungodly expensive Intel Mac Pro only a few years ago – it wasn’t taken off the shelves until 2023. That’s a hard pill to swallow, and definitely something I do not think should be legal.

For years now – it feels more like decades, honestly – Apple has been trying a variety of approaches to make the iPad more friendly to power users, most notably by introducing, and subsequently abandoning, various multitasking models. After its most recent attempts – Stage Manager – fell on deaf ears, the company has thrown its hands up in the air and just implemented what we all wanted on the iPad anyway: a normal windowing environment.

Apple today revealed an overhaul of iPad multitasking, introducing a completely new windowing system, a macOS-style Menu Bar, a pointer, and more.

The centerpiece of the multitasking improvements is a new macOS-style windowing system. Apps still launch in full-screen by default, preserving the familiar ‌iPad‌ experience, but users can now resize apps into windows using a new grab handle. If an app was previously used in a windowed state, it will remember that layout and reopen the same way next time.

↫ Hartley Charlton at MacRumors

The new window manager includes tiling features, Exposé, support for multiple displays, and swiping twice on the home button will minimise all open windows. It’s literally the macOS way of managing windows transplanted onto the iPad, with some small affordances for touch input. This is excellent news, and should make the multitasking features of the iPad, which, at this point, is as powerful as a MacBook, much more accessible and effortless than all those hidden gesture-based features from before.

The amount of RAM in your iPad seems to determine how many active windows you can have open before the older ones get put to sleep, from four on the oldest iPad Pro models, to many more on the most recent models. Any windows above that limit will still be visible, but will just be a screenshot of their most recent state until you interact with them again. Any windows above a limit of twelve will be pushed to the recents screen instead.

In addition, and almost just as important, iPadOS 26 also introduces proper background processes, allowing applications to actually keep running in the background instead of being put to sleep. Anyone who has ever done any serious work on an iPad that involves long processes like exporting a video will consider this a godsend.

Now all we need is a proper terminal and Xcode and the iPad can be a real computer.

If you ever wanted to know what it was like to be an engineer at Google during the early to late 2000s, here you go.

Now even though Google is fundamentally a spyware advertising company (some 80% of its revenue is advertising; the proportion was even higher back then), we Engineers were kept carefully away from that reality, as much as meat eaters are kept away from videos of the meat industry: don’t think about it, just enjoy your steak. If you think about it it will stop being enjoyable, so we just churned along, pretending to work for an engineering company rather than for a giant machine with the sole goal of manipulating people into buying cruft. The ads and business teams were on different floors, and we never talked to them.

↫ Elilla

Even back then, Google knew full well that what they were doing and working towards was deeply problematic and ethically dubious, at best, and reading about how young, impressionable Google engineers at the time figured that out by themselves is kind of heartbreaking. In those days, Google tried really hard to cultivate an image of being different than Apple or Microsoft, a place where employees were treated better and had more freedom, working for a company trying to make the web a better place.

Of course, none of that was actually true, but for a short while back then, a lot of people fell for it – yes, including you, even if you now say you didn’t – and reading about the experiences from people on the inside at the time, it was never actually true.

Apple at WWDC announced iOS 26, introducing a comprehensive visual redesign built around its new “Liquid Glass” concept, alongside expanded Apple Intelligence capabilities, updates to core communication apps, and more.

Liquid Glass is a translucent material that reflects and refracts surroundings to create dynamic, responsive interface elements, according to Apple. The new design language transforms the Lock Screen, where the time fluidly adapts to available space in wallpapers, and spatial scenes add 3D effects when users move their iPhone. Meanwhile, app icons and widgets gain new customization options, including a striking clear appearance.

↫ Tim Hardwick at MacRumors

Apple also posted a video on YouTube where you can see the new design language in motion, which gives a bit of a better idea of what it’s actually like. Of course, before you believe anyone who’s writing about this new Liquid Glass design language, the only true way to form a coherent opinion of a user interface is through usage, so keep that in mind.

Looking at the video, the good part that immediately jumps out at me about this Liquid Glass stuff is the animations informing you where stuff is coming from and where it’s going. These are the sort of affordances I was writing about almost 20 years ago, when Compiz’ animations and effects made windows and virtual desktops feel like “real” objects that had a physical presence in a space. Apple’s Liquid Glass seems to have the same effect, and I’m here for it.

The transparency, though, I’m not a huge fan of. Depending on the content shown beneath the glass user interface elements, contrast can suffer, making things incredibly hard to read. While the glassy refraction effects looks neat, I would’ve much rather seen a focus on blurred glass, which makes a lack of contrast much less likely to occur. I think we’re going to be seeing a lot of screenshots, videos, and thinkpieces about how this much transparency is going to hurt readability.

I love it when an operating system gets a design language overhaul, and in this case, Apple is applying it across the board, to all of its operating systems. This may be the perfect moment for me to grit my teeth, hold my nose, and get my hands on a Mac just so I can write about Liquid Glass once it lands.

NetBSD is an OS that I installed only a couple of times over the years, so I’m not very familiar with its installer, sysinst. This fact was actually what led to this article (or the whole series rather): Talking to a NetBSD developer at EuroBSDcon 2023, I mentioned my impression that NetBSD was harder to install than it needed to be. He was interested in my perspective as a relative newcomer, and so I promised to take a closer look and write about it. While it certainly took me long enough, I finally get to do this. So let’s take a look at NetBSD’s installer, shall we? The version explored here is NetBSD 10.1 on amd64.

↫ Eerie Linux

An excellent deep, deep dive into the NetBSD installer. The two earlier installments cover FreeBSD’s and OpenBSD’s installers.

We’ve cleared another month by the skin of our teeth, so it’s time for another month of progress in Redox, the Rust-based operating system. They’ve got a big one for us this month, as Redox can now run X11 applications in its Orbital display server, working in much the same way as XWayland. This X11 support includes DRI, but it doesn’t yet fully support graphics acceleration. Related to the X11 effort is the brand new port of GTK3 and the arrival of Mesa3D EGL.

Moving on, there’s the usual massive list of bugfixes and low-level changes, such as the introduction of the /var directory and subdirectories for compliance with the FHS, a fix to make the live image work when there’s no other working storage driver, and a ton more. Of course, there’s the usual list of relibc fixes, as well as a ton of updated and improved ports.

London-based Builder.ai, once valued at $1.5 billion and backed by Microsoft and Qatar’s sovereign wealth fund, has filed for bankruptcy after reports that its “AI-powered” app development platform was actually operated by Indian engineers, said to be around 700 of them, pretending to be artificial intelligence.

The startup, which raised over $445 million from investors including Microsoft and the Qatar Investment Authority, promised to make software development “as easy as ordering pizza” through its AI assistant “Natasha.” However, as per the reports, the company’s technology was largely smoke and mirrors, human developers in India manually wrote code based on customer requests while the company marketed their work as AI-generated output.

↫ The Times of India

I hope those 700 engineers manage to get something out of this, but I doubt it. I wouldn’t be surprised if they were unaware they were part of the “AI” scam.

As part of Microsoft’s ongoing commitment to compliance with the Digital Markets Act, we are making the following changes to Windows 10, Windows 11, and Microsoft apps in the European Economic Area (EEA). We’ll update this post as these changes are shipped, first in Windows Insider builds and then in retail builds.

↫ Windows Insider Program Team

It’s time for more changes to make Windows suck just a little bit less, but only for those of us who live in the European Economic Area (the EU plus Iceland, Liechtenstein, and Norway), courtesy of basic consumer protection laws like the Digital Markets Act. Windows users in other parts of the world will not get these changes, so if you don’t live in the EU/EEA, feel free to look away to remain blissfully ignorant.

In the EU/EEA, Edge will no longer bug you to be set as the default browser, unless you actually open Edge. In addition, other Microsoft applications won’t bug you to install Edge if you’ve removed it from your system. Setting a browser as default will now also register more filetypes. Whereas in other parts of the world setting, say, Firefox as your default browser in Windows will only register it as the default for http, https, .htm, and .html, it will register the following additional defaults: ftp, read, .mht, .mhtml, .shtml, .svg, .xht, .xhtml, and .xml.

Users in the EU/EEA can now also remove the Microsoft Store, without affecting updates or the ability for developers to the Microsoft Store Web Installer for their applications. You can now also have multiple online search providers in Windows Search, and countless Microsoft applications and Windows components will no longer default to opening Edge for web content, opting to use your default browser instead.

These are all very welcome improvements for European Windows users. It’s almost like consumer protection laws work.

Fvwm3, the venerable, solid, configurable, no-nonsense window manager for X, has been updated: fvwm3 1.1.3 has been released. While the version number indicates that this is a minor release, there’s one reason why 1.1.3 is actually a much bigger deal than the version number suggests: it switches the build system from autotools to meson.

Fvwm is very old, and has been using autotools since 1996 (before then it was using handcrafted makefiles), but the release of autotools 2.70, which came eight years after the previous release, the amount of changes in autotools proved to be a major headache for fvwm. Since the amount of work would be considerable, the project decided to look at alternatives to autotools, and after considering CMake and meson, the latter was chosen.

This was chosen primary because X11 itself is transitioning its projects from autotools to meson. Additionally, there has been good help from the wider community around meson’s adoption.

In terms of “speed”, the parallelised nature of not using make does mean compilation speeds are improved, even on lower-end systems.

↫ Thomas Adam

To ensure you don’t need Python 3 just to build fvwm3, you can use muon starting with muon version 0.13. Muon is written in C, and only requires a C compiler to be built. Fvwm3’s transition from autotools to Meson started with version 1.1.1, and with 1.1.3 autotools has been completely deprecated. As for actual changes to fvwm3 itself, this point release is exactly what you’d expect – a few bug fixes, as well as some minor changes to FvwmRearrange.

The first prototype was ready in just six months. By October 1986, the project was announced, and in January 1987, the first NEWS workstation, the NWS 800 series, officially launched. It ran 4.2BSD UNIX and featured a Motorola 68020 CPU. Its performance rivaled that of traditional super minicomputers, but with a dramatically lower price point ranging from ¥950,000 to ¥2.75 million (approximately $6,555 to $18,975 USD in 1987). Competing UNIX workstations typically cost closer to ¥10 million (around $69,000 USD). NEWS caught on quickly in universities and R&D labs, where cost sensitive researchers needed real performance. The venture team had invested ¥400 million into development (about $2.76 million USD), and remarkably, they recouped those costs within just two months of launch.

That same year, Sony introduced a lower cost version called POP NEWS (PWS 1550). With a GUI shell named NEWS Desk, a document sharing format called CDFF (Common Document File Format), and a focus on Japanese language desktop publishing, PopNEWS aimed to make UNIX more accessible to general business users. Targeted at the Desktop Publishing market, it showed Sony’s desire to bridge consumer and professional segments in ways no other UNIX vendor was trying at the time.

↫ Obsolete Sony’s Newsletter

I’ve been fascinated by Sony’s NEWS workstations, and especially the NEWS-OS operating system, for a long time now. Real hardware is hard to find and prohibitively expensive, but some of these Sony NEWS workstations can be emulated through MAME. Sadly, as far as I can tell, you can only emulate NEWS-OS up to version 4.x, as I haven’t been able to find any information about emulating version 5.x and the final version, 6.x. If anyone knows anything about how to emulate these, if at all possible, please do share with the rest of us.

What’s interesting about Sony’s UNIX workstation efforts from the ’80s and ’90s is that they played an important role in the early development of the PlayStation. The early development kits for the PlayStation were modified NEWS workstations, with added PlayStation hardware. To further add to the importance of the NEWS line for gaming, Nintendo used them to develop several influential and popular first-party SNES titles, which isn’t surprising considering Nintendo and Sony originally worked together on bringing a CD-ROM drive to the SNES, which would later morph into the PlayStation as Nintendo cancelled the agreement at the last second.