“Firefox” ported to Haiku

Haiku is already awash with browsers to choose from, with Falkon (yes, the same one) being the primary choice for most Haiku users, since it offers the best overall experience. We’ve got a new addition to the team, however, as Firefox – in the form of Iceweasel, because trademark stuff and so on – has been ported to Haiku. Jules Enriquez provides some more background in a post on Mastodon:

An experimental port of Firefox Iceweasel is now available on HaikuDepot! So far, most sites are working fine. YouTube video playback is fine and Discord just works, however the web browser does occasionally take itself down. Still rather usable, though! If @ActionRetro thought that Haiku was ready for daily driving with Falkon (see first screenshot), then rebranded Firefox surely has to make it even more viable by those standards!

It should be noted though that just like with Falkon, some crash dialogs can be ignored (drag them to another workspace) and the web browser can still be used.

↫ Jules Enriquez

It’s not actually called Firefox at the moment because of the various trademark restrictions Mozilla places on the Firefox branding, which I think is fair just to make sure not every half-assed barely-working port can slap the Firefox logo and name on itself and call it a day. As noted, this port is experimental and needs more work to bring it up to snuff and eligible for using the name Firefox, but this is still an awesome achievement and a great addition to the pool of applications that are already making Haiku quite daily-drivable for some people.

Speaking of which, are there any people in our audience who use Haiku as their main operating system? There’s a lot of chatter out there about just how realistic of an option this has become, but I’m curious if any of you have made the jump and are leading the way for the rest of us. Action Retro‘s videos about Haiku have done a lot to spread the word, and I’m noticing more and more people from far outside the usual operating system circles talking about Haiku.

Which is great, and hopefully leads to more people also picking up Haiku development, because I’m sure the team can always use fresh blood.

Google unveils Android XR for headsets and glasses

It was only a matter of time before Google would jump into the virtual/augmented reality fray once again with Android, after their several previous attempts failed to catch on. This time, it’s called Android XR, and it’s aimed at both the big clunky headsets like Apple’s Vision Pro as well as basic glasses that overlay information onto the world. Google has been working on this with Samsung, apparently, and of course, this new Android variant is drenched in “AI” slop.

We’re working to create a vibrant ecosystem of developers and device makers for Android XR, building on the foundation that brought Android to billions. Today’s release is a preview for developers, and by supporting tools like ARCore, Android Studio, Jetpack Compose, Unity, and OpenXR from the beginning, developers can easily start building apps and games for upcoming Android XR devices. For Qualcomm partners like Lynx, Sony and XREAL, we are opening a path for the development of a wide array of Android XR devices to meet the diverse needs of people and businesses. And, we are continuing to collaborate with Magic Leap on XR technology and future products with AR and AI.

↫ Shahram Izadi at Google’s blog

What they’ve shown of Android XR so far looks a lot like the kind of things Facebook and Apple are doing with their headsets, as far as user interface and interactions go. As for the developer story, Google is making it possible for regular Android applications to run on XR headsets, and for proper XR applications you’ll need to user Jetpack Compose and various new additions to it, and the 3D engine Google opted for is Unity, with whom they’ve been collaborating on this.

For now, it’s just an announcement of the new platform and the availability of the development tools, but for actual devices that ship with Android XR you’ll have to wait until next year. Other than the potential for exercise, I’m personally not that interested in VR/AR, and I doubt Google’s Android-based me-too will change much in that regard.

Support my attempt to find out if you can do NFC tap-to-pay without big tech

I’ve been dropping a lot of hints about my journey to rid myself of Google’s Android on my Pixel 8 Pro lately, a quest which grew in scope until it covered everything from moving to GrapheneOS to dropping Gmail, from moving to open source “stock” Android application replacements to reconsidering my use of Google Photos, from dropping my dependency on Google Keep to setting up Home Assistant, and much, much more. You get the idea: this has turned into a very complex process where I evaluated my every remaining use of big tech, replacing them with alternatives where possible, leaving only a few cases where I’m sticking with what I was using.

And yes, this whole process will turn into an article detailing my quest, because I think recent events have made remocing big tech from your life a lot more important than it already was.

Anyway, one of the few things I couldn’t find an alternative for was Google Pay’s tap-to-pay functionality in stores. I don’t like using cash – I haven’t held paper money in my hands in like 15 years – and I’d rather keep my bank cards, credit card, and other important documents at home instead of carrying them around and losing them (or worse). As such, I had completely embraced the tap-to-pay lifestyle, with my phone and my Pixel Watch II. Sadly, Google Pay tap-to-pay NFC payments are simply not possible on GrapheneOS (or other de-Googled ROMS, for that matter), because of Google’s stringent certification requirements. Some banks do offer NFC payments through their own applications, but mine does not.

I thought this is where the story ended, but as it turns out, there is actually a way to get tap-to-pay NFC payments in stores back: Garmin Pay. Garmin offers this functionality on a number of its watches, and it pretty much works wherever Google Pay or Apple Pay is accepted, too. And best of all: it works just fine on de-Googled Android ROMs. Peope have been asking me to check this out and make it part of my quest, and ever the people-pleaser, I would love to oblige.

Sadly, it does require owning a supported Garmin watch, which I don’t have. To guage interest in me testing this, I’ve set up a Ko-Fi goal of €400 you can contribute to. Obviously, this is by no means a must, but if you’re interested in finding out if you can ditch big tech, but keep enjoying the convenience of tap-to-pay NFC payments – this is your chance.

QEMU with VirtIO GPU Vulkan support

With its latest reales qemu added the Venus patches so that virtio-gpu now support venus encapsulation for vulkan. This is one more piece to the puzzle towards full Vulkan support.

An outdated blog post on clollabora described in 2021 how to enable 3D acceleration of Vulkan applications in QEMU through the Venus experimental Vulkan driver for VirtIO-GPU with a local development environment. Following up on the outdated write up, this is how its done today.

↫ Pepper Gray

A major milestone, and for the adventurous, you can get it working today. Give it a few more months, and many of the versions required will be part of your ditribution’s package repositories, making the process a bit easier.

On a related note, Linux kernel developers are considering removing 32-bit x86 KVM host support for all architectures that support it – PowerPC, MIPS, RISC-V, and x86-64 – because nobody is using this functionality. This support was dropped from 32bit ARM a few years ago, and the remaining architectures mentioned above have orders of magnitude fewer users still. If nobody is using this functionality, it really makes no sense to keep it around, and as such, the calls to remove it.

In other words, if your custom workflow of opening your garage door through your fridge light’s flicker frequency and the alignment of the planets and custom scripts on a Raspberry Pi 2 requires this support, let the kernel developers know, or forever hold your peace.

Turning off Zen 4’s op cache for curiosity and giggles

CPUs start executing instructions by fetching those instruction bytes from memory and decoding them into internal operations (micro-ops). Getting data from memory and operating on it consumes power and incurs latency. Micro-op caching is a popular technique to improve on both fronts, and involves caching micro-ops that correspond to frequently executed instructions.

AMD’s recent CPUs have particularly large micro-op caches, or op caches for short. Zen 4’s op cache can hold 6.75K micro-ops, and has the highest capacity of any op cache across the past few generations of CPUs. This huge op cache enjoys high hitrates, and gives the feeling AMD is leaning harder on micro-op caching than Intel or Arm. That begs the question of how the core would handle if its big, beautiful op cache stepped out for lunch.

↫ Chester Lam at Chips and Cheese

The results of turning off the op cache were far less dramatic than one would expect, and this mostly comes down to the processor having to wait on other bottlenecks anyway, like the memory, and a lot of tasks consisting of multiple types of operations which not all make use of op cache. While it definitely contributes to making Zen 4 cores faster overall, even without it, it’s still an amazing core that outperforms its Intel competition.

As a sidenote, this is such a fun and weird thing to do and benchmark. It doesn’t serve much of a purpose, and the information gained isn’t very practical, but turning off specific parts of a processor and observing the consequences does create some insight into exactly how a modern processor works. There are so many different elements that make up a modern processor now, and just gigahertz or even the number of cores barely tells even half the story.

Anyway, we need more of these weird benchmarks.

A twenty-five year old curl bug

When we announced the security flaw CVE-2024-11053 on December 11, 2024 together with the release of curl 8.11.1 we fixed a security bug that was introduced in a curl release 9039 days ago. That is close to twenty-five years.

The previous record holder was CVE-2022-35252 at 8729 days.

↫ Daniel Stenberg

Ir’s really quite fascinating to see details like this about such a widepsread and widely used tool like curl. The bug in question was a logic error, which made Stenberg detail how any modern language like Rust, instead of C, would not have prevented this issue. Still, about 40% of all security issues in curl stem from not using a memory-safe language, or about 50% of all high/critical severity ones. I understand that jumping on every bandwagon and rewriting everything in a memory-safe language is a lot harder than it sounds, but I also feel like it’s getting harder and harder to keep justifying using old languages like C.

I really don’t know why people get so incredibly upset at the cold, hard data about this.

Anyway, the issue that sparked this post is fixed in curl 8.11.1.

HP-RT: HP’s real-time operating system from the ’90s

Every now and then I load OpenPA and browse around. Its creator and maintainer, Paul Weissmann, has been very active lately updating the site with new articles, even more information, and tons of other things, and it’s usually a joy to stumble upon something I haven’t read yet, or just didn’t know anything about. This time it’s something called HP-RT, a real-time operating system developed and sold by HP for a number of its PA-RISC workstations back in the ’90s.

HP-RT is derived from the real-time operating system LynxOS and was built as real-time operating system from scratch with native POSIX API and Unix features like protected address spaces, multiprocessing, and standard GUI. Real-time scheduling is part of the kernel with response times under 200 µs, later improved to sub-100 µs for uses such as hospital system tied to a heart monitor, or a missile tracking system.

For programming, HP-RT supported dynamic shared libraries, ANSI C, Softbench (5.2), FORTRAN, ADA, C++ and PA-RISC assembly. From HP-RT 3.0, GUI-based debugging environment (DDErt) and Event Logging library (ELOG) were included. POSIX 1003.1, 1003.1b and POSIX 1003.4a draft 4 were supported.

On the software side, HP-RT supported fast file system, X and Motif clients, X11 SERVERrt, STREAMSrt (SVR 3.2), NFS, and others.

↫ Paul Weissmann at OpenPA

I had no idea HP-RT existed, and looking at the feature list, it seems like it was actually a pretty impressive operating system and wider ecosystem back in the ’90s when it was current. HP released several versions of its real-time operating system, with 1997’s 3.0 and 3.01 being the final version. Support for it ended in the early 2000s alongside the end of the line for PA-RISC.

I’d absolutely love to try it out today, but sadly, my PA-RISC workstation – an HP Visualise c3750 – is way too “new” to be supported by HP-RT, and in the wrong product category at that. HP-RT required both a regular HP 9000 700 HP-UX workstation, as well as one of HP’s VME machines with a single-module module with the specific “rt” affix in the model number. On top of that you obviously needed the actual HP-RT operating system, which was part of the HP-RT Development Environment. The process entails using the HP-UX machine to compile HP-RT, which was then downloaded to the VMe machine.

The odds of not only finding all the right parts to complete the setup, but also to get it all working with what is undoubtedly going to be spotty documentation and next to nobody to talk to about how to do it, are very, very slim. I’m open to suggestions, of course, but considering the probable crazy rarity of the specific hardware, the price-gauging going on in the retrocomputing world, the difficulty of shipping to the Swedish Arctic, and the knwoledge required, I don’t think I’ll be the one to get this to work and show it off.

But man do I want to.

Maker of emotional supports robots for kids abruptly shuts down, kills all the robots in the process

Some news is both sad and dystopian at the same time, and this is one of those cases. Moxie, a start-up selling $800 emotional support robots intended to help children is shutting down operations since it can’t find enough money, and since their robots require constant connectivity to servers to operate, all of the children’s robots will cease functioning within days. They’re not offering refunds, but they will send out a letter to help parents tell their children “in an age-appropriate way” that their lovable robot is going to die.

If you have kids yourself, you know how easily they can sometimes get attached to the weirdest things, from fluffy stuffed animals designed to be cute, to random inanimate objects us adults would never consider to be even remotely interesting. I can definitely see how my own kids would be devastated if one of their favourite “emotional” toys were to suddenly stop working or disappear, and we don’t even have anything that pretends to have a personality or that actively interacts with our kids like this robot thing does.

We can talk about how it’s insane that no refunds will be given, or how a company can just remotely kill a product like this without any repercussions, but most of all I’m just sad for the kids who use one and are truly attached to it, who now have to deal with their little friend going away. That’s just heartbreaking, and surely a sign of things to come as more and more companies start stuffing “AI” into their toys. The only thing I can say is that we as parents should think long and hard about what kind of toys we give our children, and that we should maybe try to avoid anything tied to a cloud service that can go away at any time.

A brief history of Mac servers

Although there’s little evidence of them today, Apple made a long succession of Mac servers and servers for Macs from 1988 to 2014, and only discontinued support for the last release of macOS Server in April 2022. Its first entry into the market was a special version of the Macintosh II running Apple’s own port of Unix way back in 1988.

↫ Howard Oakley

These days, you can nab Xserves for pretty cheap on eBay, but since Apple doesn’t properly support them anymore, they’re mostly a curiosity for people who are into retro homelab stuff and the odd Apple enthusiast who doesn’t know what to do with it. It always felt like Apple’s head was never really in the game when it came to its servers, despite the fact that both its hardware and software were quite interesting and user friendly compared to the competition.

Regardless, if my wife and I ever manage to buy our own house, the basement’s definitely getting a nice homelab rack with old – mostly non-x86 Sun and HP – servers, and I think an Xserve would be a fun addition, too. Living in the Arctic means any heat they generate is useful for like 9 or so months of the year to help warm the house, and since our electricity is generated from hydropower they wouldn’t be generating a massive excess of pollution, either. I have to figure out what to do with the excess heat during the few months of the year where it’s warm outside, though.

Meet Willow, our state-of-the-art quantum chip

Today I’m delighted to announce Willow, our latest quantum chip. Willow has state-of-the-art performance across a number of metrics, enabling two major achievements.

  • The first is that Willow can reduce errors exponentially as we scale up using more qubits. This cracks a key challenge in quantum error correction that the field has pursued for almost 30 years.
  • Second, Willow performed a standard benchmark computation in under five minutes that would take one of today’s fastest supercomputers 10 septillion (that is, 10^25) years — a number that vastly exceeds the age of the Universe.
↫ Hartmut Neven, Founder and Lead, Google Quantum AI

The concensus seems to be that this is a major achievement and milestone in quantum computing, and that it’s come faster than everyone expected. This topic is obviously far more complicated than most people can handle, so we have to rely on the verdicts and opinions from independent experts to gain some sense of just how significant an announcement this really is. The paper’s published in Nature for those few of us possessing the right amount of skill and knowledge to disseminate this information.

Thank you to our weekly sponsor, OS-SCi

We’re grateful for our weekly sponsor, OpenSource Science B.V., an educational institution focused on Open Source software.

OS-SCi is training the next generation FOSS engineers, by using Open Source technologies and philosophy in a project learning environment.

OS-SCi is offering OSNews readers a free / gratis online masterclass by Prof. Ir. Erik Mols on how the proprietary ecosystem is killing itself. This is a live event, on January 9, 2025 at 17:00 PM CET. Sign up here.

The state of Falkon: KDE’s browser is much better than you know

It’s no secret that I am very worried about the future of Firefox, and the future of Firefox on Linux in particular. I’m not going to rehash these worries here, but suffice to say that with Mozilla increasingly focusing on advertising, Firefox’ negligible market share, and the increasing likeliness that the Google Search deal, which accounts for 85% of Mozilla’s revenue, will come to an end, I have little faith in Firefox for Linux remaining a priority for Mozilla. On top of that, as more and more advertising nonsense, in collaboration with Facebook, makes its way into Firefox, we may soon arrive at a point where Firefox can’t be shipped by Linux distributions at all anymore, due to licensing and/or idealogical reasons.

I’ve been warning the Linux community, and distributions in particular, for years now that they’re going to need an alternative default browser once the inevitable day Firefox truly shits the bed is upon us. Since I’m in the middle of removing the last few remaining bits of big tech from my life, I figured I might as well put my money where my mouth is and go on a small side quest to change my browser, too. Since I use Fedora KDE on all my machines and prefer to have as many native applications as possible, I made the switch to KDE’s own browser: Falkon.

What is Falkon?

Falkon started out as an independent project called QupZilla, but in 2017 it joined the KDE project and was renamed to Falkon. It uses QtWebEngine as its engine, which is Qt’s version of the Chromium engine, but without all the services that talk to Google, which are stripped out. This effectively makes it similar to using de-Googled Chromium. The downside is that QtWebEngine does lag behind the current Chromium version; QtWebEngine 6.8.0, the current version, is Chromium 122, while Chromium 133 is current at the time of writing.

The fact that Falkon uses a variant of the Chromium engine means websites just work, and there’s really nothing to worry about when it comes to compatibility. Another advantage of using QtWebEngine is that the engine is updated independently from the browser, so even if it seems Falkon isn’t getting much development, the engine it uses is updated regularly as part of your distribution’s and KDE’s Qt upgrades.

The downside, of course, is that you’re using a variant of Chromium, but at least it’s de-Googled and entirely invisible to the user. It’s definitely not great, and it contributes to the Chromium monoculture, but I can also understand that a project like Qt isn’t going to develop its own browser engine, and in turn, it makes perfect sense for KDE, as a flagship Qt product, to use it as well. It’s the practical choice, and I don’t blame either of them for opting for what works, and what works now – the reality is that no matter what browser you’re choose, you’re either using a browser made by Google, or one kept afloat by Google. Pick your poison.

It’s not realistic for Qt or KDE to develop their own browser engine from scratch, so opting for the most popular and very well funded browser engine and strip out all of its nasty Google bits makes the most sense. Yes, we’d all like to have more capable browser engines and thus more competition, but we have to be realistic and understand that’s not going to happen while developing a browser engine is as complex as developing an entire operating system.

Falkon’s issues and strengths

While rendering websites, compatibility, and even performance is excellent – as a normal user I don’t notice any difference between running Chrome, Firefox, or Falkon on my machines – the user interface and feature set is where Falkon stumbles a bit. There’s a few things users have come to expect from their browser that Falkon simply doesn’t offer yet, and those things needs to be addressed if the KDE project wants Falkon to be a viable alternative to Firefox and Chrome, instead of just a languishing side project nobody uses.

The biggest thing you’ll miss is without a doubt support for modern extensions. Falkon does have support for the deprecated PPAPI plugin interface and its own extensions system, but there’s no support for the modern extensions API Firefox, Chrome, and other browsers use. What this means for you as a user is that there are effectively no extensions available for Falkon, and that’s a huge thing to suddenly have to do without. Luckily, Falkon does have adblock built-in, including support for custom block lists, so the most important extension is there, but that’s it.

There’s a very old bug report/feature request about adding support for Firefox/Chrome extensions, which in turn points to a similar feature request for QtWebEngine to adopt support for such extensions. The gist is that for Falkon to get support for modern Firefox and Chrome extensions, it will have to go through QtWebEngine and thus the Qt project. While I personally can just about get by with using the BitWarden application (instead of the extension) and the built-in adblock, I think this is an absolute most for most people to adopt Falkon in any serious numbers. Most people who would consider switching to a different browser than Chrome or Firefox are going to need extensions support.

The second major thing you’ll miss is any lack of synchronisation support. You won’t be synchronising your bookmarks across different machines, let alone open tabs. Of course, this extends to mobile, where Falkon has no presence, so don’t expect to send your open tabs from your phone to your desktop as you get home. While I don’t think this is as big of an issue as the lack of modern extensions, it’s something I use a lot when working on OSNews – I find stories to link to while browsing on my phone, and then open them on my desktop to post them through the tab sharing feature of Firefox, and I really miss it. There’s a longstanding feature request for this one, too, and I suggested something like this could possibly be made to work using KDE Connect.

From here on out, the shortcomings and issues I’ve personally noted fall in the category of minor issues and bugs, mostly stemming from what seems to be a lack of attention in the development of Falkon’s UI. For instance, it’s one of the very few official KDE applications left that hasn’t received the Plasma 6 overhaul to reduce the number of frames, tidy up the spacing a bit, and generally give it a bit of a spruce. This makes Falkon look a bit outdated compared to the rest of your KDE desktop (but not massively so), while also containing some odd UI elements that are quite non-standard. I filed a bug report/feature request about this.

Even smaller bugs are random things like the cursor often not changing to a hand cursor when hovering over a link, favicons in the bookmarks toolbar not updating consistently, or (more annoyingly) screens and laptops going to sleep modes while video is playing. I’m no developer so don’t put too much faith in what I’m about to say, but it feels like things like these are not the most complicated bugs to handle, and looking at the lack of activity in the bug tracker for Falkon, it feels like even within KDE itself, Falkon isn’t exactly used a lot. This is a shame, because other than the issues I’ve mentioned, Falkon is remarkably full-featured and capable.

Think of any feature a modern browser has, and Falkon probably has it. There’s a password manager built-in that can use both encrypted and non-encrypted databases as well as Kwallet, a Greasemonkey-compatible extension, web inspector tools, extensive privacy controls, spell check, address bar search with support for every search engine under the sun, advanced tab management, and much, much more.

And of course, it has a Qt/KDE graphical user interface that integrates better with KDE, both visually and behaviourally, than any other browser – including support for things like the global menubar widget, something Firefox does not support (but Chrome weirdly does). This means Falkon will respect your font choices, colour settings, light and dark mode options, and everything else. Where Chrome and Firefox feel like they’re not at all at home in KDE (or GNOME, for that matter), Falkon is just another KDE application, and looks and feels almost entirely integrated.

Combine all of this with the excellent rendering and performance thanks to QtWebEngine, and Falkon is simply a far more capable and solid browser than most people seem to know. I’ve switched all my machines to it a little over a week ago or so now, and for me, the benefits of having a truly native, KDE-first browser far outweigh some of the shortcommings I’ve had to deal with. Relying on the BitWarden application instead of the extension is a bit more cumbersome, but not massively so. No longer having tab sharing sucks, but since switching to GrapheneOS and its Vanadium browser, I had to give that up anyway.

KDE is on track

My goal with writing this article, talking about Falkon on Mastodon, and filing bug reports – I’ve got a few more extremely minor niggles coming – is to let people know that Falkon is in a far better, more usable, and capable state than most people know. Hopefully, this article will get a few more people to try it out, file bug reports, or even become a contributor to this very capable but seemingly a bit of a neglected official KDE application.

At this rate, I give Firefox (the Linux version in particular) a few more years, at most, before its various advertising and other anti-user additions make it incompatible with the idealogical and license requirements of most Linux distributions, and KDE should be ready for when this day comes. I don’t have any illusions about my influence here – OSNews is relatively small and the inertia to switch browsers is very real and understandable – but I think that with how good Falkon already is, KDE is much closer to not having to rely on Firefox or Chrome than even KDE itself seems to know.

And with how things are going, that’s very good news.

Unofficial Windows 11 mobile is possible even on select budget phones with a free utility

Back in December 2019, Microsoft finally killed off Windows 10 Phone as it announced the end of support. The company’s grand plans with Lumia and Windows Phones sadly never became the success it needed to be in order to be able to compete with the likes of Android or iOS.

Thus Windows 11 Phone never became a real official thing outside of concepts. However, there is a free unofficial way that makes it possible, albeit the experience may not totally be free from flaws. Dubbed Project Renegade, the mod enables users to try Windows 11 on Qualcomm Snapdragon phones, among other devices.

↫ Sayan Sen at Neowin

Windows Phone 7 and 8 were amazing, and probably my favourite mobile platform of all time. I’m still sad that the duopoly made it impssible even for Microsoft to gain a foothold, because their efforts definitely deserved it. They didn’t just blindly copy Android or iOS, but came up with a truly original, unique, and in my view, superior mobile operating system, and in a fair market, they would’ve been rewarded for it, and Windows Phone would have a perhaps small, but profitable segment of the market.

In the vein of Bernie can still win, I still have this faint belief that Microsoft hasn’t completely given up on the smartphone market. Now that they’re serious about Windows on ARM, they might use it as sneaky way to get application developers on board, so that their applications are ready for the big Surface Phone a few years from now, complete with Windows Phone-inspired features and UI. I know this won’t happen, but let me enjoy my non-existent future, please.

I don’t want to rely on big tech anymore, but I might make an exception for an up-to-date Windows Phone. I’m only human.

EXiGY: let’s make shareware again

EXiGY rolls up the all of the above experiences into a single package: make games the way they were made in the mid-90s, by dragging and dropping objects into a window, programming some behaviour into those objects, and clicking the Run button. It’s like ZZT with tile graphics instead of ASCII.

Want to send your little game to some friends? Click the Gift button to package all of the files up, and send your friend the .XGY file.

EXiGY is about making it fun to create games again.

↫ Chris on the Exigy website

I fell in love with this the second I saw it come by on Mastodon. Chris – I don’t know the author’s full name so I’ll stick with Chris – has been working on this for the past year, and it’s not out quite yet. Still, the feature list is packed, and on the linked website, they intend to post development updates so we can keep up with the goings-on. This seems like an incredibly cool project and I’d love to play around with it when Chris deems it ready for release.

RISC-V Redox runs on x86-64 Redox

Every time a new Redox monthly report comes out, I’m baffled by the fact we’ve apparently rounded another month. They just keep on coming and going, don’t they? And I even turned 40 this 1 December, so it hits even harder this time. I’m now as old as I remember my parents were in some of my oldest memories, and now I’ve got two kids of my own. Wild. Time isn’t supposed to move this fast, and I strongly advise the Redox team to stop this madness.

Anyway, this month also saw the release of the 4th alpha of system76’s new COSMIC Linux desktop environment, and the parts of COSMIC available on Redox were updated to reflect that. This past months also saw a major milestone: the RISC-V version of Redox running in an emulator on the x86-64 version of Redox. That’s quite the feat, and highlights just how capable Redox has become in such a short time. There’s also the usual list of kernel, driver, and relibc improvements, as well as additional Rust programs ported to Redox.

Also highlighted in this report: a video detailing how to build Redox under Windows Subsystem for Linux. This could be a great avenue for operating system developers who use Windows to get their feet wet at building Redox on their own systems.

Vanir: open-source security patch validation

Today, we are announcing the availability of Vanir, a new open-source security patch validation tool. Introduced at Android Bootcamp in April, Vanir gives Android platform developers the power to quickly and efficiently scan their custom platform code for missing security patches and identify applicable available patches. Vanir significantly accelerates patch validation by automating this process, allowing OEMs to ensure devices are protected with critical security updates much faster than traditional methods. This strengthens the security of the Android ecosystem, helping to keep Android users around the world safe.

↫ Google Security Blog

Google makes it clear this tool can easily be adapted for other avenues too – it’s not locked into only working with Android and Java/C/C++. Since it’s now open source, anyone can contribute to it and make it compatible – for lack of a better term – with other platforms and programming languages as well.

Mozilla announces massive rebrand that mentions Firefox exactly once

Mozilla isn’t just another tech company — we’re a global crew of activists, technologists and builders, all working to keep the internet free, open and accessible. For over 25 years, we’ve championed the idea that the web should be for everyone, no matter who you are or where you’re from. Now, with a brand refresh, we’re looking ahead to the next 25 years (and beyond), building on our work and developing new tools to give more people the control to shape their online experiences.

↫ Lindsey Lionheart O’Brien at the Mozilla blog

I have no clue about marketing and branding and what investments in those things cost, but all I could think about while reading this massive pile of marketing wank is that the name “Firefox” only occurs once. How many Firefox bugs could’ve been squashed with the money spent on this rebrand literally nobody is going to care about because nobody uses Firefox as it is? Is a new logo and accompanying verbal diarrea really what’s going to turn this sinking ship around?

I’ve already made my choice, and I’ve left Firefox behind on all my machines, opting for an entirely different browser instead. I’m writing about that experience as we speak, so you’ll have to wait a bit longer to find out what choice I made, but rest assured I know I’m not the only one who is leaving Firefox behind after two decades of loyal service, and I doubt an expensive new logo is going to change anybody’s mind.

Banan-OS: a hobby operating system in C++

This is my hobby operating system written in C++. Currently supports x86_64 and i686 architectures.

↫ Banan-OS git page

A hobby operating system as a learning experience, but for once not written in Rust, which in and of itself makes it more unique than you’d think. Despite being mostly a one-person hobby project, it’s ticked quite a few boxes already: SMP, network stack, copy-on-write memory, ELF loading, NVME and ATA support, PS/2 and USB peripheral support, a basic GUI, and a lot more.

Contributions are welcomed, too.

VEKOS: the Verified Experimental Kernel Operating System

VEKOS is an experimental operating system written in Rust that focuses on verification and security at its core. This is the first alpha release (v0.0.1) that demonstrates the basic architecture and key features of the system.

↫ VEKOS GitHub page

Hobby and experimental operating systems written in Rust are not exactly a novel concept, but that doesn’t mean each new one that comes up isn’t cool. This one is still in its very early stages, but focuses on something quite interesting: every filesystem and memory operation is cryptographically verified using a proof system. It’s already got basic file system operations, signal handling and a scheduler, a shell, and more.

Contributions are welcomed.

HarmonyOS Next gets container tool to run Android applications

HarmonyOS Next, the new version of Huawei’s mobile operating system, runs on a brand new microkernel, uses a new, homegrown programming language, and most notably in this duopolistic world, does not run Android applications. This won’t be much of an issue inside China, where Huawei can more easily make sure the most important Chinese applications are supported and ported over, but outside of China that might pose some problems, especially for Chinese tourists visiting other countries.

It turns out there’s a solution for this, called 出境易 (as Android Authority notes, this seems to translate to something like “Easy Abroad”), which is basically a containerised Android runtime using microG. It comes with its own built-in application store filled with a number of popular Android applications, and runs them on HarmonyOS Next.

The tool is called 出境易, which roughly translates to “Easy Abroad.” It’s apparently designed to aid Chinese tourists who travel abroad. The tool seems to create a container for Android apps to run in, which is not a new concept but is surprising to see pop up so quickly for the new operating system. When installed, the tool lets you install a number of Android apps from its self-contained app store, including Facebook, Instagram, Discord, Reddit, YouTube, Google Search, Google Maps, Uber, Chrome, Gmail, Spotify, Disney Plus, Netflix, Steam, and more. These Android apps show up in a folder in the home screen but they cannot be dragged out of the folder.

[…]

An early hands-on of the tool from YouTuber LL Techview shows that it works surprisingly well. Android apps launch quickly, run pretty smoothly, and even appear in the recents menu. It’s even possible to sign into your Google Account to use apps like Google Search and Gmail.

↫ Mishaal Rahman at Android Authority

There are limitations, of course, and they’re roughly the same as the ones found on any device running microG instead of Google Play Services – something I just wrote about in my review of /e/OS on a FairPhone 5: certain banking applications won’t work, anything that hooks too deeply into Play Services won’t run, that sort of stuff. On top of that, this tool also brings in some limitations of its own, like only whitelisted application being supported, notifications not working properly, and a few other issues.

This all feels very similar to what Jolla and Sailfish tried to do way back in 2014. Running Android applications as a side hustle was jank back then and I feel like it’s probably going to be jank today. Even just running Play Services in a restrictive sandbox – like I do with GrapheneOS on my daily driver, a Pixel 8 Pro – presents some issues, and microG adds even more compatibility issues on top. Putting all of this in a container will surely add an additional layer of jank, like it did on Sailfish OS.

Regardless, I’m 100% down with trying to get my hands on a HarmonyOS Next device if they ever become available in some form here in Sweden, as I feel like a review of what is the most serious attempt at breaking the Android-iOS duopoly in over a decade is something that belongs here on OSNews. If that time ever comes, I might set up another fundraiser to get it done.