Google is closing down Android more and more, and launching a new Linux-based OS

0:00Hey everyone and welcome back to your Linux and open source news show. I'm your host Nick and this is a podcast where we discuss everything related to Linux, privacy, the open web and all of that stuff. And this week we've got Google closing down Android a little bit more by spacing out the releases of various security updates. They're also launching a new Linux based operating system called previously aluminum OS and now it's a Google book OS, which is a terrible name. We also have a Katie getting some backlash on their AI policy and their handling of the whole conversation around it. We've got a gnome developer proposing a no AI at all policy in GNOME and a bunch of other interesting things. So as usual, if you want to dive deeper into any of these topics, all the sources I used are down in description. You are highly encouraged to go check them out to make up your own mind on everything. And also you'll find links to support the show, including a sum that will get you a daily

1:01version of this show with an RSS feed through Patreon, which you can just plug into any podcast client afterwards. You don't have to use Patreon to listen to the daily news and you also have this message from our sponsor, Taxido Computers. So Taxido makes hardware that chips with Linux out of the box. Their whole entire range is made of computers that support Linux really, really well. They even develop and upstream a lot of stuff to make sure that things keep running properly on any distro. They have a big range of devices. They will cover every need and every price point. And I can only recommend them. You've got options. You've got powerful devices. And I've been using them for so long now I have no issues with them. They run really well. I can swap distro's at will. They're fantastic. So as usual, the link is down in the description. So let's begin with Android and Graphino S. Specifically, it's not very happy with the direction Android is taking currently because Google has closed down the development process more and more over the past years and some things are getting even worse. Alternative ROMs now need to wait for Google to publish the code in various drops across

2:05the year. And apparently on that front, Google now started adding some security patches in their quarterly updates instead of the monthly security patches. Meaning alternative ROMs are falling behind when it comes to patching vulnerabilities because they will only get the fix when Google releases the source code for that quarterly update when previously they got those fixes monthly. This also comes as Android started deploying new APIs that apparently did not make it to the Android open source project yet. And while for example, Graphene managed to still update their bills to support those, they are not legally allowed to distribute these changes because that code has not been made public. Apparently this leads them to have to backport a ton of stuff to keep their ROM secure, which is the main selling point of Graphino S, more security than default Android or default AOSP. Google also apparently took their time to comply with a GPL source request when Graphene asked for the sources to a specific bill, which if it's under the GPL, they have to provide the sources with binaries.

3:05And Google took two weeks to comply, which is apparently unusual. Generally, they are much faster. All in all, it paints a pretty bleak picture of the open source state of Android. Because if you say that you're open source and you have an open source license, but you only distribute the source code in big releases twice, thrice, four times a year without really giving people any time to adapt without showing your development process in public, are you still really open source sort of, but it's not pretty the ethos all the way you probably should do things. And this leads to plenty of problems for people building an alternative to the official Android bills. And this is very clearly intentional, because Google in a lot of countries in the world now cannot forbid manufacturers to sell a device with a Google bill of Android and the same device with a non-Google bill of Android. So the way to make sure that those non-Google bills are worse is to delay the publication of source code to segment it more. So alternative runs cannot be as good or as updated as often.

4:07This is very clearly a voluntary move alongside every other really terrible thing that they're doing with Android and applications and the developer portal. It's not good. And still on Google, we know more about their new operating system for laptops, which is Linux based. This was called aluminum OS, but it is now called Google book OS, which is a horrible name. It will run on the new Google books, which is also a terrible name. I can't say it without thinking of gobble-de-gook, but yeah, that's what they went with. Now these devices will not replace Chrome OS or Chromebooks. Those will be higher end devices with a admittedly more capable OS. That thing is built on Linux. It also ships an Android subsystem to run Android applications. Apparently a bunch of those applications are being redesigned for the desktop use case, instead of just being phone or tablet apps running on the laptop, you could already run Android apps on Chrome OS, but generally they had a pretty terrible form factor. A lot of them crashed when you tried resizing them, but it's not a great experience.

5:08Apparently, phone and tablet apps will still run on Google books as well. They just won't be super adapted to a desktop. They use the full desktop Chrome browser instead of a subpar version from Chrome OS. The UI looks like Android stretched to a desktop with a taskbar. It uses the same material 3 design as Android, and it offers integration with Android phones in the same vein as what Apple offers between iPhones and Macs, although apparently they will not support phone calls for security reasons for now. It of course will add a bunch of AI-related features on top of it, powered by Gemini. It will come with 12 months of the paid Gemini Spark agent, but also apparently you have access to a terminal to Linux containers, so I would assume you could also run full-fat Linux apps in there too. Now we'll see what sort of Linux base it is, how capable it is, if it is sort of open, or if it is a giant proprietary blob dropped on top of just a Linux kernel. So is it more like Android, where it is Linux based in name only, or is it more like

6:09a regular Linux distro, probably somewhere in the middle, and probably more along the lines of what Chrome OS was, which was using a few subsystems that were used to in our Linux distro, but not most of them. On that note, they probably should just replace Chromebooks entirely. They just suck my father-in-law just bought one and returned it. Two days later, because it was such an awful experience, couldn't even open ODT files, even when installing library office from the Linux Dave container, that app did not have access to the USB device that the file was stored on. And if you wanted to grant access to that USB device, he had to remove access to it from the rest of the system, so he couldn't even open a file manager, double click on his ODT file and open it in the Linux app. Absolute garbage implementation of everything. Try to install Android apps, crash all the time, just he returned it, he bought a Windows laptop and we installed Linux on it, because yeah, that sucks. Now let's talk AI policies. I already covered very quickly the KD situation in a video a few days ago, but if you want

7:12the TLDR, Nate Graham from KD published a little recap of what happened. So basically a few weeks ago, a discussion started on KD's LLM policy. Everyone agreed that this was necessary because AI Slop submissions are making everyone's work harder. So they drafted a guideline to basically forbid any drive by AI Slop automatic bot generated kind of stuff. And this seems to have been positively received. Some developer suggested something that goes a bit more in depth on just handling every single form of AI contribution, but this went really unanswered for a while, because no one really had time to take care of it. After that, a talk at Academy proposed an AI native KD build called KDI. The following workshop on that specific idea was apparently not received very positively, but this led to Nate Graham reopening their draft policy for LLM. And that policy was being discussed by contributors and it was pretty harsh. It basically said, I don't want to hear anything about which tool you use. We will just judge on code quality.

8:14If you mention your AI, if we can detect it was done with AI, it's getting the boot. It needs to be on the exact same level of quality that what we get with humans. We don't want any assisted by tags or anything. You just submit your code. If it is good, it's going to make it in. If it's not good, it's getting dropped AI or no AI. Now that revised policy was being discussed, but then more people showed up that were apparently not known contributors to KDE. Although that apparently also included a bunch of people who had signed a petition that a KD was for the people, basically trying to say, hey, please, no AI in our project because we are a community of people and we don't want it. All of those people were lumped together, sort of, everyone started fighting about AI's ethical implications, which is fine, but not on a thread dedicated to a specific policy for a specific project. The general conversation around AI has no real place right there. You should be discussing the policy itself. This escalated quite a bit. The conversation was fully derailed and so basically they closed down and even deleted the entire conversation, which that second part is unfortunate.

9:16It would have been good to leave it open so people could have seen what was said if it was actually a big issue or if it was just a knee-jerk reaction in the form of, hey, you know what? Let's not talk about this anymore closing this down. Apparently the policy will be discussed more with KDE contributors directly and I would assume it will be then made public to have an actual conversation with the community instead of just enforcing it right then and there because yes, developers and contributors should have the most saying this, but users of KDE and the entire community that are not necessarily developers but can still contribute might still want their opinions heard. In short, as usual, when talking about AI, this discussion generally devalls into a shit show of people saying it's great, people saying it's the worst thing and no one really agreeing on anything so that always opens a can of worms. On that same note, a GNOME contributor reacted to that same issue laying out the GNOME LLM policy that they themselves would like to see and sort of proposing it unofficially. Now to be clear, this is not an official proposal for GNOME.

10:18I don't think it is being discussed using the proper channels currently. It is basically just a blog post but it is pretty significant because this policy is one single article LLMs cannot be used at all whatsoever period. If you do use it, your ban from the project. That's basically what this person would like to see implemented in GNOME. He also goes deeper into how they would evaluate the use of AI, basically just asking people about the changes being submitted, providing reasons for those changes, maybe asking people to demonstrate knowledge of the issue that they're trying to solve, actually solving the issue, not the symptoms of the problems, respecting the time of other contributors, actually detecting if someone is being impersonated by your bot. This GNOME developer says that GNOME is a collective, not just a software project. The main thing is the community and the people are the entire point of GNOME. As they say, please join GNOME so you can review LLM generated code submitted by bots, is not an appealing proposition to anyone as a hobby, as a project or even as a job.

11:20They still a bit, it's not fully enforceable. Of course, you can't detect everything. But as with all codes of conduct, some policies, 80% of the policies just preventing unwanted behaviors and then there's 20% of that policy, which is actually solving the problems created by people who ignored the policy. Now, of course, this is just a submission from one person. It hasn't been implemented. I don't think it is being discussed seriously right now if it is. I haven't seen it, but it is an interesting viewpoint, basically saying hell no. We are here for the people working on stuff. We don't want any robots or clenkers making code for us. We don't want that whether the code is good or not. We don't want it. We want humans and human interaction. Again, totally respect that. I don't know if it this will lead to projects maybe dying off in the future if they completely refuse AI. But right now, the way AI is built, I can fully understand why people would not want to get involved with it whatsoever. Now, back to KDE, they announced three goals that they will focus on for 2027 after

12:20the community submitted a bunch of goals and opened a voting process on these submissions. So the first goal that they picked is better enterprise and better enterprise deployment for KDE. So better LDAP integration, expiring passwords if you want that as an optional feature, SSO based accounts and logins as well, better network print or support, better headless remote access, all of that sort of stuff that of course makes KDE a better citizen in various companies that might want to run a dissrude at ships KDE. Second goal is better documentation, trying to eliminate all the duplicates or the misleading pages or the outdated stuff, then writing better tutorials and better documentation in general with a contributor guides to help people get started faster with KDE. And the third goal is what they call next gen styling, which is basically using the union theming system, which is a theming engine, basically, where other themes can plug into and that can theme all various KDE apps, whatever the framework they use to develop them.

13:21And also adding on that the new theme called ocean, we covered that a little bit in previous episodes. It is an effort to redesign KDE, improving upon the breeze team, making it a bit more current and of course working on all types of KDE apps. Now these are the three goals they will focus on. I think they are good ones. A visual redesign really cannot hurt. I kind of like breeze, I think it looks good, but some people think it looks a little bit dated when you compare it to stuff like macOS or Windows 11. So why not offering something else doesn't remove the previous options generally, so that's good. Better enterprise support is also probably a good idea to have more dissruses in KDE by default. And also better documentation cannot hurt. So good focusses, we'll see if those land on actual improvements or if those goals remain unfulfilled, there is no guarantee that everything in those goals will be actually made and delivered to users. Now this week we saw the release of a new build of SteamOS as a stable build. It is a minor version, but it does include a lot of stuff. It of course supports the Steam Deck, the Steam Machine, the officially supported device

14:23and also it will work on unsupported device provided they already worked with previous builds of SteamOS. This brings newer Mesa drivers with ray tracing performance improvements. I will be very happy to test that on my next gaming session, so I do use ray tracing on my SteamOS console for some games, but it doesn't perform that well with an AMD GPU, hopefully this improves. There's also better VRAM management in there too, with the latest changes we already talked about previously in previous episodes to better handle lower VRAM systems and still deliver acceptable performance when your system runs out of VRAM. You can also wake up the system using the Steam controller wireless adapter, they specify 2015 so I would assume this is for the old Steam controller, not the brand new one. The system will also tell you if you're currently drawing more power than what the power adapter can supply to your device, meaning you're not actually charging. Various delays when starting games have been reduced when no capture device was present. This is an issue that affected me, I don't know if it's the exact same issue, but sometimes launching games in SteamOS takes multiple minutes before I even see the first logos

15:27of the publishers. This might be addressed with that. You will also be able to reset all the audio settings, some HDMI audio drops, R-Fix, now there are tons of other bug fixes, more gamepad support and the kernel got a slight bump as well. As per the future, SteamOS 3.9 should arrive relatively soon as well with an updated Archbase, a newer kernel version 7.2, KD-plus-Mass 6.7.3 for the desktop mode, initial hibernation support as well, and the ability to run SteamOS in a VM with accelerated graphics which isn't bad either. Speaking of performance optimizations, it looks like a new patch series for the Linux kernel will improve file opening speeds by 39%. This is part of the virtual file system that the kernel offers, it should apply to all modern file systems that use that VFS, it apparently speeds up considerably the simple action of opening a file to read it in read-only mode, which is something your kernel does a lot on your system. Currently, there are currently duplicate entries in the code which create a bit of a performance

16:29penalty, that work is trying to remove those duplicates to unify the way you open files so everything can be faster and on a 20 core system that they tested things on, it reaches 39% more operations per second for opening the same file over and over in read-only mode, which is good, this should arrive in the kernel 7.4 so early 2027, I think. That's good stuff, this performance benefit will also trickle down to your entire system, whether you're running a game, you're running a heavy application that needs to interact with a lot of files, a lot of things will benefit, that's really nice. But we have even more because Ubuntu will change the out-of-memory behavior on their desktop. Currently on Linux when you're running out of RAM and also out of swap, chances are the system will kill something to avoid completely locking itself down. But what gets killed is generally pretty random, it could be an application which is sort of okay, but it can also be a system service that you actually need to run the entire desktop session, leading of course to losing the entire session which might also take down every

17:32app with it. Ubuntu wants to fix that in 26.10 using a new policy that gives a lower out-of-memory score to the desktop services and a higher score to apps and various optional background services. The higher the score, the likely or you are to be picked for termination if your system starts running out of memory. So basically Ubuntu wants the system to shut down apps before the entire desktop session which makes sense. They also disabled the system D out-of-memory service in the process because it used different scores than what the kernel itself used, meaning you could still end up with a broken session. This is apparently just the first step, they will try to make that more granular in the future. I would assume maybe with user controls at some point, who knows. And I think it makes sense, if your system is running out of RAM I would much rather lose a single app then lose my entire desktop session and potentially all of the apps that were running. What I would also like to see is applications being able to declare an intent with the systems that is being developed for Flatpack telling, hey, I can't do file restore if I

18:33crash. So maybe terminate me first because I don't care, I can just restart the app and I can restore the work. Stuff like LibreOffice or Odacity have those sorts of capabilities that seem to work pretty well. Maybe you could also use that sort of stuff to decide which applications get terminated. First, if they support that intent, their termination score is higher so they will be terminated. I don't know, maybe it's not doable but this seemed like a pretty solid idea here. Valve is introducing a new video codec called PyroWave. Now they didn't develop it themselves as far as I can tell, it is a separate project that has existed for a few years but they added it to Steam's beta client even on Linux and it's apparently very optimized to use more of your bandwidth about 5 to 10 times more which will reduce latency provided at least you're using an Ethernet cable. And of course that is very useful for game streaming from a Steam machine to a Steam frame, from a big PC to a Steam deck or whatever else. It is based on Vulcan, it is capable of HDR and it will be used for Steam Remote Play.

19:36It is not enabled by default, you'll need to turn it on in the advanced settings of the Steam client and there's also a quality slider you can tweak to get the best results. It is of course GPU accelerated, they will be adding it to the Steam link app as well in the future and as far as I can tell it is open source under the MIT license. And I think that codec could also have some cool potential implications for stuff like Remote Desktop. For example, if you're on the same local network chances are this codec will give you much better results to stream a desktop to another device. So there are potential use cases that might be demonstrated as being very useful by the use of that thing in Steam Remote Play might give more light to the project, I think it's good. Ubuntu is making more changes on top of that, they are apparently stepping up the update pace for their kernels obviously because they are way too many vulnerabilities being discovered through the use of AI or not, but way too many CVs anyway. So they will now provide updates every single week for their Linux kernels. Well previously it was a four week development cycle and basically you got kernel updates

20:39every two weeks if an urgent update was needed. Now it will just be a weekly affair with each kernel update cycle lasting two weeks but starting in parallel one week apart. So on one week they will release an update and start working on the next one the next week they will publish that update and start working on the next one and so on and so forth. Obviously this is due to the number of CVs being disclosed with the help of AI tools which means you cannot wait for almost a month to patch your systems, you almost need a rolling release kernel for security fixes and canonical also apparently aims to provide a workaround for people who want even faster updates, maybe working on a 24 or 48 hour disclosure to release cycle. I have no idea how they will manage that with all the backports they need to do to older unsupported kernel versions that exist in their LTSs, it's gonna be a lot of work and I think at some point for enterprise customers a live patching system to be able to swap a kernel with another without rebooting the server might become absolutely necessary

21:41with that sort of release cadence. Now this week we also got an update to Cosmic version 1.9 which is a big one, a has two new apps on the desk. The first one is Cosmic Viewer which is of course an image viewer. It apparently has a few image editing features which look more akin to a screenshot editing feature so text, freehand drawing, shapes, various colors you can select and do and redo support kind of looks like the interface that you get in spectacle of the screenshot manager for KD. I haven't seen specific tools to crop or automatically enhance pictures but I'm sure that if they're not there yet they will come soon. This is the recommended default for Cosmic as well but I don't think it will automatically change your own preferences if you update from the older version of Cosmic to a new one. I don't think it will erase your default image viewer. They also added an on-screen keyboard for Cosmic that lets you use touch screens properly and also game paths for text input. There's a panel applet to call it on-demand and it can also be used on the login screen. On top of that the store now makes application developer's names more visible in search results

22:45so you can be sure that the thing you're wanting to download is made by the developers of the app. Context menus now work properly in the app library and launcher. You can also press escape to close menus. The file manager handles drag selection better. It also has icons for .exe files and in file dialogs your sorting settings will be persistent now. The settings app also will display the current Cosmic version. It has configuration options for the new on-screen keyboard as well. Font settings will be synced with GNOME applications if you elect to theme them with the Cosmic colors. They will look more at home using the right fonts that you picked and you can also configure the thickness of the panel's border as well. Pretty solid update for a minor version. I'm still waiting on Epoch 2 to see if there are bigger, massive changes at that point. I will do a video on Cosmic. I don't think I can really do videos or reviews of those point updates. They're just not big enough. But when they release Epoch 2 I will probably cover every single change since Cosmic 1 was released just to have a complete video that showcases everything that this thing can

23:49do. And to conclude we can talk about a little fun project called React OS. You might have heard about it. It's been there for a long, long while it is an open source implementation of Windows basically. It uses a lot of wine code underneath as far as I can tell, but they have moved their entire DirectTec stack to wines stack instead of using their own DirectTecs implementation what they call their own hacks. So they should have a much, much better way of running DirectTecs which will be translated into OpenGL and or Vulcan. And this apparently took a very long time. The developer said 230 plus hours of work and it's still not fully completed because apparently that compatibility for now is for DirectTecs 9 and older and not for DirectTecs 10, 11 and 12 which will come later. It should still make React OS a lot more capable when it comes to DirectTecs related stuff and presumably updating to newer DirectTecs stacks from wine should be a bit easier now as well. Apparently it allows some games to run. They cite a Dragon Age origins for example.

24:51Now that's a fun project I've been looking at from a distance for a long, long while. I think I first heard about it like a few years after I started using Linux so it's been a long while and it's still there. So maybe at some point I will need to make a video about it on the channel. It could be fun just to see what they're doing, how it looks, how it works, which apps it can run, the compatibility with Windows stuff, maybe with drivers, whatever else. It's going to be fun to explore just to see what this thing can do. You'll let me know in the comments if you're interested in a video on React OS. Anyway this will conclude this week's episode as usual. All the sources are down in the description. This is also where you can find links to directly support the show through Patreon for example are getting a daily version of these news with its own RSS feed as well. And of course you also have a link to our sponsor, Tuxedo computers. Thank you all for listening and I guess you will hear me. In the next one next week. Bye.