If you were to read the README of the Vib-OS project on GitHub, you’d see it advertised as a Unix-like OS that was written from scratch, runs on ARM64 and x86_64, and comes with a full GUI, networking and even full Doom game support. Unfortunately, what you are seeing there isn’t the beginnings of a new promising OS that might go toe to toe with the likes of Linux or Haiku, but rather a vibe-coded confabulation. Trying to actually use the OS as [tirimid] recently did sends you down a vibe-coded rabbit hole of broken code, more bugs than you can shake a bug zapper at, and most of the promised features being completely absent.

[tirimid] is one of those people who have a bit of a problem, in that they like to try out new OSes, just to see what they’re like. The fun starts with simply making the thing run at all in any virtual machine environment, as apparently the author uses MacOS and there it probably ‘runs fine’.

After this the graphical desktop does in fact load, some applications also open, but it’s not possible to create new folders in the ‘file explorer’, the function keys simply switch between wallpapers, there’s no networking or Doom support despite the promises made, there’s no Python or Nano support at all, and so on.

Clearly it’s still got the hallmarks of a functioning OS, and it’s sort of nice that you don’t need to know what you’re doing to create a sort-of-OS, but it will not appease those who feel that vibe-coding is killing Open Source software.

youtube.com/embed/JxknDQaDrao?…

hackaday.com/2026/03/04/trying…

[Diffraction Limited] has been working on a largely 3D-printed micropositioner for some time now, and previously reached a resolution of about 50 nanometers. There was still room for improvement, though, and his latest iteration improves the linkage arms by embossing tiny ball joints into them.

The micro-manipulator, which we’ve covered before, uses three sets of parallel rod linkages to move a platform. Each end of each rod rotates on a ball joint. In the previous iteration, the parallel rods were made out of hollow brass tubing with internal chamfers on the ends. The small area of contact between the ball and socket created unnecessary friction, and being hollow made the rods less stiff. [Diffraction Limited] wanted to create spherical ball joints, which could retain more lubricant and distribute force more evenly.

The first step was to cut six lengths of solid two-millimeter brass rod and sand them to equal lengths, then chamfer them with a 3D-printed jig and a utility knife blade. Next, they made two centering sleeves to hold small ball bearings at the ends of the rod being worked on, while an anti-buckling sleeve surrounded the rest of the rod. The whole assembly went between the jaws of a pair of digital calipers, which were zeroed. When one of the jaws was tapped with a hammer, the ball bearings pressed into the ends of the brass rod, creating divots. Since the calipers measured the amount of indentation created, they was able to emboss all six rods equally. The mechanism is designed not to transfer force into the calipers, but he still recommends using a dedicated pair.

In testing, the new ball joints had about a tenth the friction of the old joints. They also switched out the original 3D-printed ball mount for one made out of a circuit board, which was more rigid and precisely manufactured. In the final part of the video, he created an admittedly unnecessary, but useful and fun machine to automatically emboss ball joints with a linear rail, stepper motor, and position sensor.

On such a small scale, a physical ball joint is clearly simpler, but on larger scales it’s also possible to make flexures that mimic a ball joint’s behavior.

youtube.com/embed/NM2KXvRGmpg?…

hackaday.com/2026/03/04/emboss…

Disposable vapes aren’t quite the problem/resource stream they once were, with many jurisdictions moving to ban the absurdly wasteful little devices, but there are still a lot of slightly-smelly lithium batteries in the wild. You might be forgiven for thinking that most of them seem to be in [Chris Doel]’s UK workshop, given that he’s now cruising around what has to be the world’s only vape-powered car.

Technically, anyway; some motorheads might object to calling donor vehicle [Chris] starts with a car, but the venerable G-Wiz has four wheels, four seats, lights and a windscreen, so what more do you want? Horsepower in excess of 17 ponies (12.6 kW)? Top speeds in excess of 50 Mph (80 km/h)? Something other than the dead weight of 20-year-old lead-acid batteries? Well, [Chris] at least fixes that last part.

The conversion is amazingly simple: he just straps his 500 disposable vape battery pack into the back seat– the same one that was powering his shop–into the GWiz, and it’s off to the races. Not quickly, mind you, but with 500 lightly-used lithium cells in the back seat, how fast would you want to go? Hopefully the power bank goes back on the wall after the test drive, or he finds a better mounting solution. To [Chris]’s credit, he did renovate his pack with extra support and insulation, and put all the cells in an insulated aluminum box. Still, the low speed has to count as a safety feature at this point.

Charging isn’t fast either, as [Chris] has made the probably-controversial decision to use USB-C. We usually approve of USB-Cing all the things, but a car might be taking things too far, even one with such a comparatively tiny battery. Perhaps his earlier (equally nicotine-soaked) e-bike project would have been a better fit for USB charging.

Thanks to [Vaughna] for the tip!

youtube.com/embed/HwoZg3BCigU?…

hackaday.com/2026/03/04/vape-p…

This week Jonathan chats with Philippe Humeau about Crowdsec! That company created a Web Application Firewall as on Open Source project, and now runs it as a Multiplayer Firewall. What does that mean, and how has it worked out as a business concept? Watch to find out!

• github.com/crowdsecurity/crowd…
• crowdsec.net/feed/
• linkedin.com/company/53443483

youtube.com/embed/cFlhtWiCHNw?…

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

hackaday.com/2026/03/04/floss-…

The TX50U isn’t very Linux-friendly
If you’ve used Linux for a long time, you know that we are spoiled these days. Getting a new piece of hardware back in the day was often a horrible affair, requiring custom kernels and lots of work. Today, it should be easier. The default drivers on most distros cover a lot of ground, kernel modules make adding drivers easier, and dkms can automate the building of modules for specific kernels, even if it isn’t perfect.

So ordering a cheap WiFi dongle to improve your old laptop’s network connection should be easy, right? Obviously, the answer is no or this would be a very short post.

Plug and Pray

The USB dongle in question is a newish TP-Link Archer TX50U. It is probably perfectly serviceable for a Windows computer, and I got a “deal” on it. Plugging it in caused it to show up in the list of USB devices, but no driver attached to it, nor were any lights on the device blinking. Bad sign. Pro tip: lsusb -t will show you what drivers are attached to which devices. If you see a device with no driver, you know you have a problem. Use -tv if you want a little more detail.

The lsusb output shows the devices as a Realtek, so that tells you a little about the chipset inside. Unfortunately, it doesn’t tell you exactly which chip is in use.

Internet to the Rescue?

Note that most devices (including the network card) have drivers since this was taken after the driver install. The fingerprint scanner (port 5 device 3) does not have a driver, however.
My first attempt to install a Realtek driver from GitHub failed because it was for what turned out to be the wrong chipset. But I did find info that the adapter had an RTL8832CU chip inside. Armed with that nugget, I found [morrownr] had several versions, and I picked up the latest one.

Problem solved? Turns out, no. I should have read the documentation, but, of course, I didn’t. So after going through the build, I still had a dead dongle with no driver or blinking lights.

Then I decided to read the file in the repository that tells you what USB IDs the driver supports. According to that file, the code matches several Realtek IDs, an MSI device, one from Sihai Lianzong, and three from TP-Link. All of the TP-Link devices use the 35B2 vendor ID, and the last two of those use device IDs of 0101 and 0102.

Suspiciously, my dongle uses 0103 but with a vendor ID of 37AD. Still, it seemed like it would be worth a shot. I did a recursive grep for 0x0102 and found a table that sets the USB IDs in os_dep/linux/usb_intf.c.

Of course, since I had already installed the driver, I had to change the dkms source, not the download from GitHub. That was, on my system, in /usr/src/rtl8852cu-v1.19.22-103/os_dep_linux/usb_intf.c. I copied the 0x0102 line and changed both IDs so there was now a 0x0103 line, too:
{USB_DEVICE_AND_INTERFACE_INFO(0x37ad, 0x0103, 0xff, 0xff, 0xff), .driver_info = RTL8852C},
/* TP-Link Archer TX50U */
Now it was a simple matter of asking dkms to rebuild and reinstall the driver. Blinking lights were a good sign and, in fact, it worked and worked well.

DKMS

If you haven’t used DKMS much, it is a reasonable system that can rebuild drivers for specific Linux kernels. It basically copies each driver and version to a directory (usually /usr/src) and then has ways to build them against your kernel’s symbols and produce loadable modules.

The system also maintains a build/install state database in /var/lib. A module is “added” to DKMS, then “built” for one or more kernels, and finally “installed” into the corresponding location for use by that kernel. When a new kernel appears, DKMS detects the event — usually via package manager hooks or distribution-specific kernel install triggers — and automatically rebuilds registered modules against the new kernel headers. The system tracks which module versions are associated with which kernels, allowing parallel kernel installations without conflicts. This separation of source registration from per-kernel builds is what allows DKMS to scale cleanly across multiple kernel versions.

If you didn’t use DKMS, you’d have to manually rebuild kernel modules every time you did a kernel update. That would be very inconvenient for things that are important, like video drivers for example.

Of course, not everything is rosy. The NVidia drivers, for example, often depend on something that is prone to change in future Linux kernels. So one day, you get a kernel update, reboot, and you have no screen. DKMS is the first place to check. You’ll probably find it has some errors when building the graphics drivers.

Your choices are to look for a new driver, see if you can patch the old driver, or roll back to a previous working kernel. Sometimes the changes are almost trivial like when an API changes names. Sometimes they are massive changes and you really do want to wait for the next release. So while DKMS helps, it doesn’t solve all problems all the time.

Extras and Thoughts

I skipped over the part of turning off secure boot because I was too lazy to add a signing key to my BIOS. I’ll probably go back and do that later. Probably.

You have to wonder why this is so hard. There is already a way to pass the module options. It seems like you might as well let a user jam a USB ID in. Sure, that wouldn’t have helped for the enumeration case, but it would have been perfectly fine to me if I had just had to put a modprobe or insmod with a parameter to make the card work. Even though I’m set up for rebuilding kernel modules and kernels, many people aren’t, and it seems silly to force them to recompile for a minor change like this.

Of course, another fun answer would be to have vendors actually support their devices for Linux. Wouldn’t that be nice?

You could write your own drivers if you have sufficient documentation or the desire to reverse-engineer the Windows drivers. But it can take a long time. User-space drivers are a little less scary, and some people like using Rust.

What’s your Linux hardware driver nightmare story? We know you have one. Let us hear about it in the comments.

hackaday.com/2026/03/04/linux-…

Last summer we took a look at FreeDOS as part of the Daily Drivers series, and found a faster and more complete successor to the DOS of old. The sojourn into the 16-bit OS wasn’t perfect though, as we couldn’t find drivers for the 2010-era network card on our newly DOS-ified netbook. Here’s [Inkbox] following the same path, and bringing with it a fix for that networking issue.

The video below is an affectionate look at the OS alongside coding a TRON clone in assembler, and it shows a capable environment within the limitations of the 16-bit mode. The modern laptop here can’t emulate a BIOS as it’s UEFI only, and after trying a UEFI-to-BIOS emulator with limited success, he hits on a different approach. With just enough Linux to support QEMU, he has a lightweight and extremely fast x86 BIOS platform with the advantage of legacy emulation of network cards and the like.

The point of Daily Drivers is wherever possible to use real hardware and not an emulator, as it’s trying to be the machine you’d use day to day. But we can see in a world where a BIOS is no longer a thing it becomes ever more necessary to improvise, and this approach is better than just firing up an emulator from a full-fat Linux desktop. If you fancy giving it a try, it seems less pain than the route we took.

You can read our look at FreeDOS 1.4 here.

youtube.com/embed/mwLIgdRj5bI?…

FreeDOS logo: Bas Snabilie for the FreeDOS Project, CC BY 2.5.

hackaday.com/2026/03/04/succes…

WELCOME BACK TO THE FREE MONTHLY EDITION of Digital Politics.I'm Mark Scott, and the world appears to be veering out of control (again). You're here for digital policy. But for the latest on the evolving crisis in the Middle East, see here, here, here, here and here.

— The mood within European Union policymaking circleshas markedly changed when it comes to digital sovereignty, online competition and platform governance.

— The likelihood of a digital-focused transatlantic trade war has risen significantly in the wake of the US Supreme Court's overturning of Donald Trump's tariff regime.

— Who's actually funding Europe's AI industry? The answer isn't who you would think.

Let's get started:

THE NEW REALITY OF THE BRUSSELS BUBBLE

THE EU QUARTER CAN BE A STRANGE PLACE. Among the glass-fronted European Commission buildings, the hustle and bustle of multilingual lobbyists and the cavalcade of European Parliament lawmakers that most people have never heard of, it's difficult to decipher fact from fiction. I've spent most of the last two weeks entrenched in the so-called Brussels bubble. I come bearing news: the EU's collective digital policymaking priorities are in flux — and a new reality is starting to emerge.

First, a caveat. This analysis is based on conversations before the US and Israeli attacks on Iran over the weekend. Such an open-ended conflict will inevitably change political priorities, including those associated with tech. I don't know how that will shake out. Reader discretion is advised.

What is unmistakable, however, is that three fundamental shifts are underway in how the 27-country bloc approaches digital policymaking. This shift is couched in 1) the deregulatory environment created by Mario Draghi's 2024 competitiveness report; 2) the dominance of the center-right European People's Party across all EU institutions; and 3) a relegation of tech-related issues behind those linked to Ukraine and trade.

First, the EU is implementing a version of digital sovereignty that will try to onshore infrastructure and seek to reduce the Continent's independence on US tech giants. This move began before Donald Trump's second term in the White House. But over the last 12 months, even staunch US allies in Eastern Europe and the Baltics have come to recognize that Washington can no longer be seen as a short-term trusted partner. That has jumpstarted a policy agenda aimed at investing public European money into local alternatives to gradually wean the bloc off US tech.

This is still an early-stage movement. Many within more defense-focused policy circles fret that a so-called "rip-and-replace" strategy, which would see the likes of AWS infrastructure give way to a European alternative, would create systemic vulnerabilities which would not be in EU member countries' short-term national interests. More fiscally hawkish officials also worry that throwing EU public funds at often legacy industrial players — many of which are the only ones currently positioned to offer alternatives to Silicon Valley — would not represent good value for money.

Thanks for reading the free monthly version of Digital Politics. Paid subscribers receive at least one newsletter a week. If that sounds like your jam, please sign up here.

Here's what paid subscribers read in February:
— Digital policymaking needs a fundamental rethink; US attacks against Europe's online safety regime are not really about the bloc's online safety regime; Southeast Asia still dominates the world's semiconductor industry. More here.
— Public security and combating disinformation are increasingly intertwined, often in ways that should leave us feeling queasy; How Brussels' latest regulatory enforcement about TikTok plays into the EU's wider legislative agenda; Polarized social media has led to a public exodus from these platforms. More here.
— Be wary of anyone at India's AI Impact Summit peddling easy solutions for AI governance; The rise of kids' social media bans is example of the lack of quantifiable evidence in digital policymaking; The Global Majority is missing from the global data center boom. More here.
— What is, and what is not, working within the EU's Digital Services Act; Debrief from the AI Impact Summit: more trade show than policymaking; One-third of US teenagers use AI chatbots every day. More here.

And yet, my conversations with EU officials over the last two weeks made it clear that such a "Make Europe Great Again" digital sovereignty strategy — including now open discussions of funding European alternatives to American social media companies — has been baked into the bloc's policy priorities.

Second (and this is related to the first point) is a growing awareness and willingness to use the EU's digital competition rulebook to fast-track the newly-empowered digital sovereignty strategy.

While some officials and advocates would like to pour money into European alternatives (and that inevitably will happen), others are taking a more nuanced approach. That includes galvanizing the EU's Digital Markets Act to reduce market concentration which, in turn, would open up space for European alternatives to flourish.

This strategy is based on the somewhat naive belief that if only Big Tech didn't control the market, then a steady flow of European and non-European firms would be able to compete in everything from social media to online marketplaces to cloud computing infrastructure. Such a theory misunderstands the network effects from which consumers benefit when such services are bundled together — often at a cheaper price compared to buying such digital wares individually.

But as the DMA undergoes a current review, policymaking hope to extend the competition levers within this legislation to more aggressively hobble US tech firms, as well as expand areas of interoperability so that smaller firms can build on top of these platforms by offering people the ability to connect often rival services to each other. This is already available for messaging services within the bloc, and some EU startups now offer that ability.

Policymakers are also looking to extend that functionality — and, goes the theory, reduce Big Tech's market dominance and boost the bloc's digital sovereignty — to the likes of social media.

Third: the era of vigorous enforcement of the bloc's online safety and platform governance rules will be replaced by more nuanced policymaking aimed at balancing internal political priorities with those coming from outside the bloc.

That may sound odd, given my take on the EU's online safety landscape from last week. But the political winds have shifted away from comprehensive enforcement on topics like platform design and disinformation (editor's note: this does not constitute illegal content under the bloc's Digital Services Act). In its place, there will be more kneejerk policymaking attempts around populist topics like social media bans for teenagers, which meet short-term priorities for national leaders without addressing the long-term harm derived from how these platforms are designed.

It would be wrong to think that attacks from the US on the DSA had not played a role in this shift. The European Commission is a political beast. The repeated (and unfounded) claims that these rules equate to censorship of Americans' First Amendment rights have been heard at the very top of the Berlaymont building.

But, in truth, the shift away from aggressive, fast and comprehensive enforcement of the bloc's online safety rules has been driven by a change in the EU's internal dynamics.

Many center-right politicians — and such lawmakers now hold a majority in the European Commission, European Parliament and Council of the EU — are openly skeptical of the need for these rules. The complexities of implementing the DSA, in which Brussels enforcers are struggling to have a meaningful impact, have run up against shifting political priorities that promote deregulation and a more populist digital agenda.

That doesn't mean Brussels won't continue enforcing the DSA. But it is no longer first among legislative equals as EU officials turn their attention to digital sovereignty and the use of the bloc's competition rules to lift up European alternatives to their US and Chinese competitors.

Chart of the week

EUROPE WANTS TO GO IT ALONE ON AI. But which investors lie at the heart of the Continent's strategic ambitions for the emerging technology?

The University of Amsterdam's Leevi Saari crunched investment funds for all AI-linked European startups (including those from non-EU countries.) He then ranked which investors were central to these deals, ranking them on so-called "betweenness centrality," or a figure that measures the importance of certain actors in how the Continent's AI startups grow.

At the top of the list is French public investor BPI France, which plays a central role in the country's AI scene. Only one American Big Tech firm — Nvidia — makes the list (at number six.) Top-tier US venture capitalists and Europe's billionaire class, like Xavier Niel, also underpin how AI investment works across Europe, based on Saari's analysis.
Source: Leevi Saari

ARE WE HEADING TOWARD A TRANSATLANTIC (DIGITAL) TRADE WAR?

THE RECENT US SUPREME COURT 6-3 DECISIONto invalidate 60 percent of US tariffs against third-party countries feels like a lifetime ago. In truth, it only happened on Feb 20. The world is rightly preoccupied with other matters. But the ongoing global omnishambles should take away from the fact that the EU-US trade deal — known as the Turnberry Framework — is on life support after the European Parliament refused to ratify it; and US President Trump threatened a new round of potential tariffs, including those that targeted the 27-country bloc (more on that below).

Trade negotiators, on both sides, are seeking a compromise. Maroš Šefčovič, the EU's trade czar, held meetings with his US counterpart, and said that "full respect for the EU-US deal is paramount."

If only things were that simple.

I still believe that any future transatlantic trade beef would likely be limited to the offline, not online, world. The US runs a significant trade surplus with the EU on digital services, whereas it runs an almost identical trade deficit on non-digital goods. If Washington really wants to hurt Brussels (and other European capitals), then it makes a lot more sense to slap tariffs on French wine and German cars than it does to tax incoming digital services from the likes of <<checks notes>> almost no EU-based firm (I joke, but only just.)

This, however, is where things get sticky. As part of the White House's new arsenal of potential tariff measures are so-called Section 301 investigations. These probes allow the US Trade Representative to look into any country's trading practices to determine if they are discriminatory or unfair against US firms. When it comes to Europe, the Trump administration has already made clear its anger toward the bloc's digital rulebook.

"The European Union and certain EU Member States have persisted in a continuing course of discriminatory and harassing lawsuits, taxes, fines, and directives against U.S. service providers," the USTR said in late 2025. "If the EU and EU Member States insist on continuing to restrict, limit, and deter the competitiveness of U.S. service providers through discriminatory means, the United States will have no choice but to begin using every tool at its disposal to counter these unreasonable measures."

Shots fired, if you will.

Sign up for Digital Politics

Thanks for getting this far. Enjoyed what you've read? Why not receive weekly updates on how the worlds of technology and politics are colliding like never before. The first two weeks of any paid subscription are free.

Subscribe
Email sent! Check your inbox to complete your signup.

No spam. Unsubscribe anytime.

There is still a long way to go before Washington starts specific 301 investigations into Europe — let alone before it leads to a tit-for-tat trade war with Washington. US President Trump, however, is looking for any opportunity to impose new tariffs. And for the EU, that's most likely connected to the bloc's competition laws, known as the Digital Markets Act, and national digital services taxes, which almost exclusively are paid by American tech firms.

That contrasts with the public attention focused by some in the White House against the bloc's online safety rules. Such ire may represent red meat in the ongoing culture war issue of platform governance. But for almost all US tech giants, the bigger issue remains EU digital competition rules and these unilateral digital services taxes.

If I was to be a betting man, I would put all my money on upcoming 301 investigations to focus on these two digital issues in how Washington responds to last month's US Supreme Court decision. Former administrations, on both sides of the aisle, have raised objections to these laws. Competition rules and digital services taxes would neatly fix into the definition required to start such investigations. And the focus on tech — compared to more analogue products — provides the White House with a strong corporate lobbying constituency willing to back a more aggressive stance with Europe.

For now, such speculation remains what it is: speculation. Officials' attention is also drawn elsewhere.

But in the coming months, I would wager the US will attempt to use such digital-focused 301 investigations to force the issue. In response, Europe already has a suite of tech-focused tariff responses that would be aimed at Silicon Valley — including potential hefty EU tariffs and, if things really go badly, potential Continent-wide bans on certain digital services.

Hopefully, we do not get to such a stage, for the sake of officials on both sides of the Atlantic. In the wake of the Turnberry deal (almost of which did not affect the digital world), most people breathed a sigh of relief that we had avoided a transatlantic trade war. That threat is now back — and all bets may soon be off.

What I'm reading

— Chatham House published an analysis into how so-called Middle Powers countries could navigate the dual hegemony of the US and China on AI. More here.

— A report from Citrini, a research group, into the potential labor force and market impact of mass adoption of AI led to a significant fall in US financial markets. Read the analysis here.

— We are living in a 'sovereignty paradox' in which the more governments and companies try to build their own AI systems, the more they rely on a small number of foreign providers, argues Damien Kopp for the Digital New Deal

— More than 60 data protection authorities from around the world signed a joint voluntary statement on the privacy impact on AI-generated imagery. More here.

— The US federal government ordered all agencies to stop using Anthropic's AI systems after it refused to meet certain commitments, including the use of its technology to surveil American citizens within the country and to power unmanned military equipment. Here is Anthropic's statement. And here is the statement from OpenAI's Sam Altman after the company agreed to work with the US Department of War.

digitalpolitics.co/newsletter0…

In their recent announcement, NASA has made official what pretty much anyone following the Artemis lunar program could have told you years ago — humans won’t be landing on the Moon in 2028.

It was always an ambitious timeline, especially given the scope of the mission. It wouldn’t be enough to revisit the Moon in a spidery lander that could only hold two crew members and a few hundred kilograms of gear like in the 60s. This time, NASA wants to return to the lunar surface with hardware capable of setting up a sustained human presence. That means a new breed of lander that dwarfs anything the agency, or humanity for that matter, has ever tried to place on another celestial body.

Unsurprisingly, developing such vehicles and making sure they’re safe for crewed missions takes time and requires extensive testing. The simple fact is that the landers, being built by SpaceX and Blue Origin, won’t be ready in time to support the original Artemis III landing in 2028. Additionally, development of the new lunar extravehicular activity (EVA) suits by Axiom Space has fallen behind schedule. So even if one of the landers would have been ready to fly in 2028, the crew wouldn’t have the suits they need to actually leave the vehicle and work on the surface.

But while the Artemis spacecraft and EVA suits might be state of the art, NASA’s revised timeline for the program is taking a clear step back in time, hewing closer to the phased approach used during Apollo. This not only provides their various commercial partners with more time to work on their respective contributions, but critically, provides an opportunity to test them in space before committing to a crewed landing.

Artemis II Remains Unchanged

Given its imminent launch, there are no changes planned for the upcoming Artemis II mission. In fact, had there not been delays in getting the Space Launch System (SLS) rocket ready for launch, the mission would have already flown by now. Given how slow the gears of government tend to turn, one wonders if the original plan was to announce these program revisions after the conclusion of the mission. The launch is currently slated for April, but could always slip again if more issues arise.
Artemis II Crew
At any rate, the goals for Artemis II have always been fairly well-aligned with its Apollo counterpart, Apollo 8. Just like the 1968 mission, this flight is designed to test the crew capsule and collect real-world experience while in the vicinity of the Moon, but without the added complexity of attempting a landing. Although now, as it was then, the decision to test the crew capsule without its lander wasn’t made purely out of an abundance of caution.

As originally envisioned, Apollo 8 would have seen both the command and service module (CSM) and the lunar module (LM) tested in low Earth orbit. But due to delays in LM production, it was decided to fly the completed CSM without a lander on a modified mission that would put it into orbit around the Moon. This would give NASA an opportunity to demonstrate the critical translunar injection (TLI) maneuver and gain experience operating the CSM in lunar orbit — tasks which were originally scheduled to be part of the later Apollo 10 mission.

In comparison, Artemis II was always intended to be flown with only the Orion crew capsule. NASA’s goal has been to keep the program relatively agnostic when it came to landers, with the hope being that private industry would furnish an array of vehicles from which the agency could chose depending on the mission parameters. The Orion capsule would simply ferry crews to the vicinity of the Moon, where they would transfer over to the lander — either via directly docking, or by using the Lunar Gateway station as a rallying point.

There’s no lander waiting at the Moon for Artemis II, and the fate of Lunar Gateway is still uncertain. But for now, that’s not important. On this mission, NASA just wants to demonstrate that the Orion capsule can take a crew of four to the Moon and bring them back home safely.

Artemis III Kicks the Tires

For Artemis III, the previous plan was to have the Orion capsule mate up with a modified version of SpaceX’s Starship — known in NASA parlance as the Human Landing System (HLS) — which would then take the crew down to the lunar surface. While the HLS contract did stipulate that SpaceX was to perform an autonomous demonstration landing before Artemis III, the aggressive nature of the overall timeline made no provision for testing the lander with a crew onboard ahead of the actual landing attempt — a risky plan even in the best of circumstances.
Docked CSM and LM during Apollo 9
The newly announced timeline resolves this issue by not only delaying the actual Moon landing until 2028, to take place during Artemis IV, but to change Artemis III into a test flight of the lander from the relative safety of low Earth orbit in 2027. The crew will liftoff from Kennedy Space Center and rendezvous with the lander in orbit. Once docked, the crews will practice maneuvering the mated vehicles and potentially perform an EVA to test Axiom’s space suits.

This new plan closely follows the example of Apollo 9, which saw the CSM and LM tested together in Earth orbit. At this point in the program, the CSM had already been thuroughly tested, but the LM had never flown in space or had a crew onboard. After the two craft docked, the crew performed several demonstrations, such as verifying that the mated craft could be maneuvered with both the CSM and LM propulsion systems.

The two craft then separated, and the LM was flown independently for several hours before once again docking with the CSM. The crew also performed a brief EVA to test the Portable Life Support System (PLSS) which would eventually be used on the lunar surface.
Orion docked to landers from SpaceX and Blue Origin
While the Artemis III and Apollo 9 missions have a lot in common, there’s at least one big difference. At this point, NASA isn’t committing to one particular lander. If Blue Origin gets their hardware flying before SpaceX, that’s what they’ll go with. There’s even a possibility, albeit remote, that they could test both landers during the mission.

Artemis IV Takes a Different Path

After the success of Apollo 9, there was consideration given to making the first landing attempt on the following mission. But key members of NASA such as Director of Flight Operations Christopher C. Kraft felt there was still more to learn about operating the spacecraft in lunar orbit, and it was ultimately decided to make Apollo 10 a dress rehearsal for the actual landing.

The CSM and LM would head to the Moon, separate, and go through the motions of preparing to land. The LM would begin its descent to the lunar surface, but stop at an altitude of 14.4 kilometers (9 miles). After taking pictures of the intended landing site, it would return to the CSM and the crew would prepare for the return trip to Earth. With these maneuvers demonstrated, NASA felt confident enough to schedule the history-making landing for the next mission, Apollo 11.

But this time around, NASA will take that first option. Rather than do a test run out to the Moon with the Orion capsule and attached lander, the plan is to make the first landing attempt on Artemis IV. This is partially because we now have a more complete understanding of orbital rendezvous and related maneuvers in lunar orbit. But also because by this point, SpaceX and Blue Origin should have already completed their autonomous demonstration missions to prove the capabilities of their respective landers.

Entering Uncharted Territory

At this point, the plans for anything beyond Artemis IV are at best speculative. NASA says they will work to increase mission cadence, which includes streamlining SLS operations so the megarocket can be launched at least once per year, and work towards establishing a permanent presence on the Moon. But of course none of that can happen until these early Artemis missions have been successfully executed. Until then it’s all just hypothetical.

While Apollo was an incredible success, one can only follow its example so far. Despite some grand plans, the program petered out once it was clear the Soviet Union was no longer in the game. It cemented NASA’s position as the preeminent space agency, but the dream of exploring the lunar surface and establishing an outpost remained unfulfilled. With China providing a modern space rival, and commercial partners rapidly innovating, perhaps Artemis may be able to succeed where Apollo fell short.

hackaday.com/2026/03/04/new-ar…

Phase-coherent lasers are crucial for many precision tasks, including timekeeping. Here on Earth the most stable optical oscillators are used in e.g. atomic clocks and many ultra-precise scientific measurements, such as gravitational wave detection. Since these optical oscillators use cryogenic silicon cavities, it’s completely logical to take this principle and build a cryogenic silicon cavity laser on the Moon.

In the pre-print article by [Jun Ye] et al., the researchers go through the design parameters and construction details of such a device in one of the permanently shadowed regions (PSRs) of the Moon, as well as the applications for it. This would include the establishment of a very precise lunar clock, optical interferometry and various other scientific and telecommunication applications.

Although these PSRs are briefly called ‘cold’ in the paper’s abstract, this is fortunately quickly corrected, as the right term is ‘well-insulated’. These PSRs on the lunar surface never get to warm up due to the lack of an atmosphere to radiate thermal energy, and the Sun’s warm rays never pierce their darkness either. Thus, with some radiators to shed what little thermal energy the system generates and the typical three layers of thermal shielding it should stay very much cryogenic.

Add to this the natural vacuum on the lunar surface, with PSRs even escaping the solar wind’s particulates, and maintaining a cryogenic, ultra-high vacuum inside the silicon cavity should be a snap, with less noise than on Earth. Whether we’ll see this deployed to the Moon any time soon remains to be seen, but with various manned missions and even Moon colony plans in the charts, this could be just one of the many technologies to be deployed on the lunar surface over the next few decades.

hackaday.com/2026/03/04/creati…

Starting from the third quarter of 2025, we have updated our statistical methodology based on the Kaspersky Security Network. These changes affect all sections of the report except for the installation package statistics, which remain unchanged.

To illustrate trends between reporting periods, we have recalculated the previous year’s data; consequently, these figures may differ significantly from previously published numbers. All subsequent reports will be generated using this new methodology, ensuring accurate data comparisons with the findings presented in this article.

Kaspersky Security Network (KSN) is a global network for analyzing anonymized threat intelligence, voluntarily shared by Kaspersky users. The statistics in this report are based on KSN data unless explicitly stated otherwise.

The year in figures

According to Kaspersky Security Network, in 2025:

• Over 14 million attacks involving malware, adware or unwanted mobile software were blocked.
• Adware remained the most prevalent mobile threat, accounting for 62% of all detections.
• Over 815 thousand malicious installation packages were detected, including 255 thousand mobile banking Trojans.

The year’s highlights

In 2025, cybercriminals launched an average of approximately 1.17 million attacks per month against mobile devices using malicious, advertising, or unwanted software. In total, Kaspersky solutions blocked 14,059,465 attacks throughout the year.

Attacks on Kaspersky mobile users in 2025 (download)

Beyond the malware mentioned in previous quarterly reports, 2025 saw the discovery of several other notable Trojans. Among these, in Q4 we uncovered the Keenadu preinstalled backdoor. This malware is integrated into device firmware during the manufacturing stage. The malicious code is injected into libandroid_runtime.so – a core library for the Android Java runtime environment – allowing a copy of the backdoor to enter the address space of every app running on the device. Depending on the specific app, the malware can then perform actions such as inflating ad views, displaying banners on behalf of other apps, or hijacking search queries. The functionality of Keenadu is virtually unlimited, as its malicious modules are downloaded dynamically and can be updated remotely.

Cybersecurity researchers also identified the Kimwolf IoT botnet, which specifically targets Android TV boxes. Infected devices are capable of launching DDoS attacks, operating as reverse proxies, and executing malicious commands via a reverse shell. Subsequent analysis revealed that Kimwolf’s reverse proxy functionality was being leveraged by proxy providers to use compromised home devices as residential proxies.

Another notable discovery in 2025 was the LunaSpy Trojan.

LunaSpy Trojan, distributed under the guise of an antivirus app

Disguised as antivirus software, this spyware exfiltrates browser passwords, messaging app credentials, SMS messages, and call logs. Furthermore, it is capable of recording audio via the device’s microphone and capturing video through the camera. This threat primarily targeted users in Russia.

Mobile threat statistics

815,735 new unique installation packages were observed in 2025, showing a decrease compared to the previous year. While the decline in 2024 was less pronounced, this past year saw the figure drop by nearly one-third.

Detected Android-specific malware and unwanted software installation packages in 2022–2025 (download)

The overall decrease in detected packages is primarily due to a reduction in apps categorized as not-a-virus. Conversely, the number of Trojans has increased significantly, a trend clearly reflected in the distribution data below.

Detected packages by type

Distribution* of detected mobile software by type, 2024–2025 (download)

* The data for the previous year may differ from previously published data due to some verdicts being retrospectively revised.

A significant increase in Trojan-Banker and Trojan-Spy apps was accompanied by a decline in AdWare and RiskTool files. The most prevalent banking Trojans were Mamont (accounting for 49.8% of apps) and Creduz (22.5%). Leading the persistent adware category were MobiDash (39%), Adlo (27%), and HiddenAd (20%).

Share* of users attacked by each type of malware or unwanted software out of all users of Kaspersky mobile solutions attacked in 2024–2025 (download)

* The total may exceed 100% if the same users encountered multiple attack types.

Trojan-Banker malware saw a significant surge in 2025, not only in terms of unique file counts but also in the total number of attacks. Nevertheless, this category ranked fourth overall, trailing far behind the Trojan file category, which was dominated by various modifications of Triada and Fakemoney.

TOP 20 types of mobile malware

Note that the malware rankings below exclude riskware and potentially unwanted apps, such as RiskTool and adware.

* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.

The list is largely dominated by the Triada family, which is distributed via malicious modifications of popular messaging apps. Another infection vector involves tricking victims into installing an official messaging app within a “customized virtual environment” that supposedly offers enhanced configuration options. Fakemoney scam applications, which promise fraudulent investment opportunities or fake payouts, continue to target users frequently, ranking third in our statistics. Meanwhile, the Mamont banking Trojan variants occupy the 6th, 8th, and 18th positions by number of attacks. The Triada backdoor preinstalled in the firmware of certain devices reached the 9th spot.

Region-specific malware

This section describes malware families whose attack campaigns are concentrated within specific countries.

* Country where the malware was most active.
** Unique users who encountered the malware in the indicated country as a percentage of all users of Kaspersky mobile solutions who were attacked by the same malware.

Türkiye saw the highest concentration of attacks from Coper banking Trojans and their associated Hqwar droppers. In India, Rewardsteal Trojans continued to proliferate, exfiltrating victims’ payment data under the guise of monetary giveaways. Additionally, India saw a resurgence of the Thamera Trojan, which we previously observed frequently attacking users in 2023. This malware hijacks the victim’s device to illicitly register social media accounts.

The Trojan-Proxy.AndroidOS.Agent.q campaign, concentrated in Germany, utilized a compromised third-party application designed for tracking discounts at a major German retail chain. Attackers monetized these infections through unauthorized use of the victims’ devices as residential proxies.

In Brazil, 2025 saw a concentration of Pylcasa Trojan attacks. This malware is primarily used to redirect users to phishing pages or illicit online casino sites.

Mobile banking Trojans

The number of new banking Trojan installation packages surged to 255,090, representing a several-fold increase over previous years.

Mobile banking Trojan installation packages detected by Kaspersky in 2022–2025 (download)

Notably, the total number of attacks involving bankers grew by 1.5 times, maintaining the same growth rate seen in the previous year. Given the sharp spike in the number of unique malicious packages, we can conclude that these attacks yield significant profit for cybercriminals. This is further evidenced by the fact that threat actors continue to diversify their delivery channels and accelerate the production of new variants in an effort to evade detection by security solutions.

TOP 10 mobile bankers

* Unique users who encountered this malware as a percentage of all users of Kaspersky mobile solutions who encountered banking threats.

In 2025, we observed a massive surge in activity from Mamont banking Trojans. They accounted for approximately half of all new apps in their category and also were utilized in half of all banking Trojan attacks.

Conclusion

The year 2025 saw a continuing trend toward a decline in total unique unwanted software installation packages. However, we noted a significant year-over-year increase in specific threats – most notably mobile banking Trojans and spyware – even though adware remained the most frequently detected threat overall.

Among the mobile threats detected, we have seen an increased prevalence of preinstalled backdoors, such as Triada and Keenadu. Consistent with last year’s findings, certain mobile malware families continue to proliferate via official app stores. Finally, we have observed a growing interest among threat actors in leveraging compromised devices as proxies.

securelist.com/mobile-threat-r…

You may or may not be reading this on a smartphone, but odds are that even if you aren’t, you own one. Well, possess one, anyway — it’s debatable if the locked-down, one-way relationships we have with our addiction slabs counts as ownership. [LuckyBor], aka [Breezy], on the other hand — fully owns his 4G smartphone, because he made it himself.

OK, sure, it’s only rocking a 4G modem, not 5G. But with an ESP32-S3 for a brain, that’s probably going to provide plenty of bandwidth. It does what you expect from a phone: thanks to its A7682E simcom modem, it can call and text. The OV2640 Arducam module allows it to take pictures, and yes, it surfs the web. It even has features certain flagship phones lack, like a 3.5 mm audio jack, and with its 3.5″ touchscreen, the ability to fit in your pocket. Well, once it gets a case, anyway.

It talks, it texts, it… does not julienne fry, but that’s arguably a good thing.
This is just an alpha version, a brick of layered modules. [LuckyBor] plans on fitting everything into a slimmer form factor with a four-layer PCB that will also include an SD-card adapter, and will open-source the design at that time, both hardware and software. Since [LuckyBor] has also promised the world documentation, we don’t mind waiting a few months.

It’s always good to see another open-source option, and this one has us especially chuffed. Sure, we’ve written about Postmarket OS and other Linux options like Nix, and someone even put the rust-based Redox OS on a phone, but those are still on the same potentially-backdoored commercial hardware. That’s why this project is so great, even if its performance is decidedly weak compared to flagship phones that have as more horsepower as some of our laptops.

We very much hope [LuckyBor] carries through with the aforementioned promise to open source the design.

hackaday.com/2026/03/04/neithe…