About a month ago, Flathub announced a ban on slopcoded applications. Evangelos “GeopJr” Paterakis, developer of a number of popular Linux applications and ton of other things, did some research into just how many applications tagged with “AI slop”, a tag Flathub reviewers used to keep track of slopcoded applications submitted to Flathub, actually survived the test of time. The results are exactly what you’d expect. Of the 120 unique repos, 32 were maintained and 88 were abandoned. No seriously, a big portion of them was completely deleted, nowhere to be found, others stopped 6 months ago, right after submitting to Flathub. ↫ Evangelos “GeopJr” Paterakis That’s absolutely soul-crushing. Why should Flathub’s reviewers spend their precious, limited time talking to lazy slopcoders’ “AI” agents to get their slopcoded applications into Flathub, when 70% of these applications are abandoned or outright deleted from existence within mere months of being submitted? Minimal effort for the slopcoders, maximum effort for the reviewers. Just dump a bunch of shitty code over the fence, let a chatbot handle the interactions with the reviewers, and pretend you made a valuable contribution. This is the contradiction slopcode enthusiasts really don’t want to talk about. If these “AI” tools are so great, where is all the amazing new software? Where’s the massive gains in software quality? Isn’t the story that “AI” tools do the menial work, giving programmers more time to focus on improving their software? Reality does not seem to match the story we’re being sold. Despite these slopcode tools being out and available for years now, there’s no influx of great applications and other software, there’s no rise in software quality, nothing. What we mostly seem to be getting are slopcoded projects nobody, not even their “creators” care about, so they just get abandoned and deleted as quickly as they were dredged up from the bottom of the programming barrel. These aren’t applications created because someone wanted them to exist; these are applications created because some mid programmer got high on their “AI” supply and fancied themselves better at programming than they really are – only to realise once the comedown hits they’ve got crappy, barely working, entirely unmaintainable gibberish vaguely looking like code nobody can make head nor tails of. And then they abandon the project, ready for the next high – leaving everyone else to clean up their mess. What a miserable workflow.
Only a few days ago we had Linux on the Mega Drive, and someone took that as a challenge, so now we have Linux on the Atari Jaguar. The Jaguar has a very different architecture than the Mega Drive, but does happen to use a processor from the same 68000-family. Interestingly enough, to this day, Linux has architecture code for the 68000-family of processors. 68040, 68030, 68010… and even the original base 68000 processor. All neatly structured under arch/m68k/. ↫ Joel Bueno And, well, that means Linux can indeed be made to work on the Jaguar, with some hacking and magic, of course.
Wherever in the world you go, the smartphone landscape is dominated by Android and iOS, and while this has always been problematic, recent events have made the dependency on two American tech giants for what is probably our most personal computing device even more problematic than it already was. We use our smartphones to keep our secrets, do our banking, interact with our governments, share our deepest thoughts with our friends and family, and a whole lot more. Having this invaluable tool the vast majority of us depend on tied entirely to Google and Apple is not just bad for the market, it’s also a downright threat to the national security of anyone not living in the US. Here in Europe, there’s been an awakening lately, with governments, companies, and people alike finally realising that having our entire digital infrastructure controlled by foreign, adversarial interests is a terrible idea. Sadly, breaking free from our Android and iOS chains is not so easy. The most ideal solution would be a truly open source alternative smartphone operating system, but that’s a hard sell for 99.9% of smartphone users who need the applications required to do their finances, talk to their friends, or interact with their governments. The cold and harsh truth is that with very few exceptions, these applications simply do not (yet) exist for smartphone operating systems that aren’t Android or iOS. The only viable alternative at this point in time is to take whatever’s left of the Android Open Source Project, remove anything that ties it to Google and its services, fill in the gaps with alternative services and applications, and sell it as a Google-free or de-Googled Android platform. There’s several projects in this space, and with Europe drunkenly stumbling out of the technological hole it dug itself into, it’s no surprise that two of the more popular alternatives to Apple or Google-controlled smartphones come from Europe (and from the same country, no less). Today, we’re taking a look at one of these: iodéOS. Iodé is a company based in Toulouse, France, which focuses on offering a Google-free Android called iodéOS, either preinstalled on phones you can buy, or as a ROM you can install yourself on supported devices. As a company, iodé makes its money through selling devices with iodéOS preinstalled, through an optional premium subscription (that I didn’t take a look at), and through donations, and all of their code is published as open source on their Gitlab instance hosted in France. Iodé loaned me a Fairphone 6 with iodéOS preinstalled, one of he many smartphones and tablets they sell through their online store for review. This isn’t going to be an Android review; you already know what Android is like, and there’s no need for me to rehash any of that. Instead, I want to focus on the things that make using de-Googled Android different from using Google Android. Don’t be afraid of microG There are various ways to go about making a de-Googled Android variant, and iodéOS chose the LineageOS route, with microG installed on top. For those unaware, microG is a project which aims to replace the various proprietary parts of Google Play Services, required by many Android applications, with open source reimplementations. While it doesn’t offer 100% compatibility, it works exceptionally well, and you’ll be hard-pressed to find applications just don’t work at all with microG. IodéOS updates its microG installation through a dedicated F-Droid repository that’s obviously enabled by default, so you don’t have to do anything yourself. Using microG instead of Google Play Services doesn’t mean you have to rely solely on whatever’s available in F-Droid, since there are a variety of alternative Play Store frontends available. IodéOS ships with the Aurora Store, which is an open-source frontend to the Play Store that can be used with or without a Google account. If you use it with your Google account, you’ll gain access to whatever applications you already own, including paid ones, but you won’t be able to buy applications inside Aurora. You can, however, buy an application on the Play Store website, after which it will show up in Aurora as well, assuming you’re logged in with the same account. Aurora also comes with something something called FakeStore, which is sadly an important part of the puzzle; it’s a stub application that has the same package name as the real Play Store. Some applications check whether the Play Store is available before working properly, so this is sadly needed to ensure maximum compatibility. The only issue I sometimes ran into with Aurora is that it would load up its listings, but then any application I tapped on said it was unavailable. When this happened, reloading the Aurora application always fixed the issue. Annoying, but not gamebreaking. A few things did not work for me when using microG on iodéOS, and they’re exactly the things you’d expect not to work. If you have a WearOS device, you’re out of luck; WearOS devices simply do not work when using microG, but there is a bounty to add support for it. If you want to use a smartwatch with iodéOS, there are various options available, such as Garmin devices, which is what I used during my testing and it worked flawlessly. Another feature from “regular” Android that simply won’t work is RCS. There’s only one RCS client available on Android, Google Messages, and as you can imagine, Google is in no rush to allow devices without Google Play Services to register for and use RCS messaging. Tying to register with Google Messages will fail, and there are no other RCS clients available (save for a few China and India-specific clients). There’s a microG bounty for this, too, but no luck so far. Of course, there are countless messaging platforms that work just fine on iodéOS – regular SMS, WhatsApp, Facebook Messenger, Signal, and so on – and especially if you’re European, it’s unlikely RCS support matters to you at all. I just don’t
Colour me positively surprised, as I had no idea Alpha emulation had progressed this much. As you might know, I’m involved a bit in the OpenVMS community and the Alpha emulation side via AXPBox. AXPBox (github) is a fork of the es40 alpha emulator by Camiel Vanderhoeven (who is now Chief Architect at VSI, the company that makes OpenVMS, for x86 nowdays). There have been many forks of es40 in the past and recently a new one has popped up with some great new features. Like speedups via a JIT compiler, S3 graphics port from MAME and ARC support, resulting in the ability to run Windows 2000 for the DEC Alpha. ↫ Remy van Elst Not only can you run the unreleased Alpha version of Windows 2000 on this forked emulator, it’s also capable of running OpenVMS and Tru64 UNIX. In fact, both OpenVMS and Tru64 can run their full X11 CDE desktops on the emulator as well, which is incredibly cool and a huge milestone. As the name of the original emulator implies, it’s emulating an AlphaServer Es40 from the turn of the century, which should be fast enough for enthusiast use. The last AlphaStation ever made, the ES47, is still very high on my list of computers I desperately want but will never have – they are incredibly rare, and whenever they do come up for sale, incredibly expensive. If you have one, consider yourself lucky, and please, write about it! Tell the world!
LineageOS, the de-Googled Android ROM that serves as the backbone for pretty much the entire custom Android ROM community, has published an article about what the Android developer verification changes mean for them. I really like the factual tone of their article, especially this part: Critics such as F-Droid, EFF, and “Keep Android Open” point out that this also happens to route every install path through Google-controlled infrastructure, hands Google a kill switch over any app or developer worldwide, and arrives shortly after Google’s antitrust lawsuits. Both things can be true at once: real fraud is a problem and the restriction of developers is a convenient side effect of solving it this way – and we’re not in a position to pretend we know Google’s internal reasoning. We’re just telling you what they’ve said and what it changes; you can weigh the “why” yourself. ↫ Nolen Johnson on the LineageOS website For LineageOS, these new verification measures don’t really mean much, as they don’t affect the project’s work or software. The developer verification infrastructure is a separate application that is part of Google Mobile Services, and LineageOS does not ship GMS nor does it ever intend to. As such, they don’t have to do anything, as this won’t be an issue unless LineageOS users choose to install a GApps package that happens to include the developer verification infrastructure. If Google were to move the developer verification infrastructure into Play Services in the future, LineageOS makes it clear they’ll disable it globally, as they have done with a number of other “annoying Play Services-provided over-the-air update implementations“. There really isn’t much more they can do; the rest is up to users and projects that use LineageOS as their base.
The Nintendo Entertainment System. Is it the platonic ideal of an 8-bit video game system? Well, only because it’s so prominent and successful– it’s actually kind of an oddball in its expandability and design. But there’s something else about it. The picture is a bit… wobbly. Well, over composite video anyway. Let’s dig in and learn a little big more about the nitty-gritty of composite video. ↫ Nicole Branagan As usual, the information density in this article by Branagan is kind of remarkable, especially when you consider it never overwhelms you. Such a great read.
Decentralized storage keeps getting pitched as the backbone of a sturdier, more resilient web. Fair enough, in theory. But run one of these systems on a lightweight or hobbyist operating system and the picture gets messier fast. Resource ceilings, retrieval times that swing from fine to frustrating, and the constant tug-of-war between isolation and performance turn something that sounds elegant on a whiteboard into a genuine headache in practice. The growing wave of hobbyist and edge deployments only sharpens the question. How do you get a peer-to-peer data layer to behave when the operating system underneath was built to be deliberately bare-bones? Anyone who’s spun up a node outside a standard Linux box has probably hit this wall already. Network Activity as a Stress Test for Constrained Setups Interest in established cryptocurrencies tends to work as a decent proxy for network health. When the litecoin price climbs on anticipation of its 2027 halving cycle, more people spin up nodes to support transactions and related infrastructure. That activity doesn’t stay confined to server farms with headroom to spare. Hobbyists and edge operators keep experimenting with lightweight or alternative operating systems, running straight into the same reliability questions researchers have flagged for years. A paper presented at the 21st USENIX Symposium on Networked Systems Design and Implementation, NSDI ’24, examined IPFS and didn’t paint a flattering picture. Retrieval latency ran roughly three times higher than plain HTTPS at the median and content publication could stretch past a minute at the 95th percentile thanks to DHT routing and replication overhead from node churn. The researchers also noted the IPFS stack remains too heavy for a lot of mobile or resource-limited devices, numbers that matter when a storage daemon is already running near its limits. Real-World Accessibility and Performance Gaps An ACM-affiliated study that combed through more than four million IPFS files found similar inconsistency. Roughly half the content wasn’t retrievable on the first try, sometimes taking multiple attempts spread across days, with lookup time dragging hardest for smaller files. There’s also a concentration problem worth noting. Ninety-five percent of files traced back to just fifty providers, many sitting on cloud infrastructure rather than a genuinely distributed network. These patterns hit harder on micro-OS platforms, where networking stacks are thinner and caching options limited. When a node chases content across shifting peers while managing local storage and consensus duties, small delays pile up. On hardware already stretched thin, those extra hops stop being minor annoyances and start becoming real stalls. Microkernel Trade-offs Come into Sharp Focus Microkernel designs promise strong isolation, which sounds great when you want a storage daemon to fail quietly instead of taking the whole system down. The catch is that nearly everything, file systems, network stacks, drivers, has to communicate through explicit message passing. That kind of communication brings copying, context switches and scheduling overhead that monolithic kernels mostly sidestep. Deep dives into microkernel architecture keep circling back to this same tension: the isolation that improves fault tolerance is the same isolation that quietly taxes performance under sustained load. Every retrieval request crossing multiple boundaries turns a clean diagram into cumulative drag once the workload involves constant peer-to-peer chatter. Targeted Recovery Offers a Partial Counterbalance Not all the news is grim. Research on microkernel filesystem recovery, presented at USENIX FAST 2025, introduced high-performance techniques for transparent recovery from unexpected storage failures — allowing only the affected component to be isolated and restarted without bringing down the entire system. In the traces examined, this cut damage from faulty agents dramatically while keeping the rest of the system stable, a genuinely useful tool even though the underlying IPC costs remain. Recent Optimizations That Shift the Equation Some sharp edges are getting sanded down. Early 2026 measurements from the ProbeLab research team showed a statistical adjustment to content publishing that took upload latency from over thirteen seconds, sometimes closer to twenty, down to under one second for most requests in key regions. That’s more than a tenfold speedup with forty percent less network overhead, and availability didn’t suffer. Ecosystem efforts around verifiable hot storage and faster finality, like Proof of Data Possession and warm storage tiers, point the same direction: keep the decentralized core, layer in pragmatic shortcuts where they matter most. Key Trade-offs Developers Still Navigate A few tensions keep resurfacing: These show up consistently, from hobbyist builds to edge devices built around minimalism. Where the Field Heads Next Between publishing and retrieval optimizations and architectural progress on recovery, decentralized storage is inching toward genuine usability on constrained environments. The choice between full decentralization and usable performance isn’t as binary as it used to be. OSNews, covering the Maestro kernel architecture, noted that memory-safe languages like Rust can offset a good chunk of stability headaches in experimental operating systems, though language choice alone doesn’t erase the base-level overhead when these systems run continuous background processes. Anyone who’s tried running IPFS nodes, Filecoin clients, or similar layers on Haiku, SerenityOS derivatives, or other lightweight setups has probably bumped into most of this already. Making these systems first-class citizens on alternative operating systems remains an open conversation. What’s your experience been running decentralized storage on non-mainstream platforms? Worth hearing in the comments.
A fairly big moment for the ReactOS project: it has just received its very first system call from NT6. The system call that has been added is NtGetCurrentProcessorNumberEx, which is used for returning the processor number of the logical processor that a caller is running on. It’s unclear how long it will take ReactOS to become compatible with Windows Vista software, but it took Microsoft around half a decade to develop Vista after the release of XP and marked a major upgrade, even if it didn’t land well with users at the time. ↫ Paul Hill at Neowin It’s a milestone for sure, but not one that’s going to make a huge difference for ReactOS at this moment in time. Still, it’s a sign of things to come, even if the very nature of the ReactOS project means that whatever things are coming tend to take a while to arrive.
At 4 a.m., long before the opening bell rings on Wall Street, a small number of traders are already watching numbers shift on a screen. They aren’t guessing. They’re reading a Dow futures chart, and in many cases, they already have a rough idea of how the trading day will unfold before most investors have finished their coffee. That head start is exactly why futures data draws so much attention from professional traders, portfolio managers, and increasingly, everyday investors who want to understand market direction before it becomes obvious. Why Futures Move Before the Market Opens The Dow Jones Industrial Average itself only trades during regular market hours. Futures contracts tied to the index, however, trade almost around the clock. This gap in trading windows is what gives futures their predictive reputation. Overnight news, economic data releases, corporate earnings, and geopolitical developments all get priced into futures contracts long before the cash market opens. A strong jobs report at 8:30 a.m. or an unexpected rate decision from a central bank overseas can send futures sharply higher or lower within minutes, setting the tone for the entire trading session. This is why financial professionals rarely check stock prices alone in the morning. They check futures first. Reading the Chart: More Than Just a Number A common mistake among newer investors is treating futures as a single data point, up or down, and stopping there. The real value lies in the pattern, not the snapshot. Volume tells a parallel story. A price move on thin overnight volume carries far less weight than the same move accompanied by heavy participation. Common Misreadings Worth Avoiding Several mistakes can affect futures analysis, especially for beginners. Common errors include ignoring market context, focusing only on price movements, and overlooking risk management while interpreting data. Treating premarket moves as guarantees: Futures indicate sentiment, not certainty. A market that looks strong at 6 a.m. can reverse entirely by 9:30 a.m. once actual trading volume returns and institutional desks begin executing orders based on the full picture, not just overnight headlines. Ignoring the broader context: A move in Dow futures rarely happens in isolation. Bond yields, currency markets, and commodity prices often shift in tandem, and a chart that’s read without that context can be misleading. A rising futures price alongside falling Treasury yields tells a different story than the same price move alongside rising yields. Overreacting to small percentage changes: Because futures trade continuously, minor fluctuations are constant. Distinguishing between routine overnight noise and a genuinely significant move is a skill that develops with experience, not something that shows up automatically on the screen. Here’s that section reworked with a shorter intro paragraph and pointers added: How Professional Traders Actually Use This Data For institutional desks, futures charts serve as a planning tool rather than a prediction machine, guiding decisions long before the market officially opens. Retail traders have gained similar access in recent years. What was once a tool reserved for trading floors is now available on ordinary laptops and phones, complete with historical comparisons, volume overlays, and customizable timeframes. This shift has narrowed the information gap between institutional and individual investors considerably, though interpretation still separates those who profit from those who merely watch. Putting the Pieces Together None of this data means much in isolation. A Dow futures chart becomes genuinely useful only when it’s read alongside broader market signals, historical context, and a clear understanding of what’s driving that particular session’s sentiment. The traders who use this information well aren’t necessarily the ones staring at screens the longest. They’re the ones asking the right questions about what the movement actually represents. That distinction, between watching numbers and understanding them, is what separates reactive trading from informed decision-making. Final Thoughts Futures data will always carry an element of uncertainty since it reflects sentiment ahead of full market participation, not a finished outcome. What matters most is developing the discipline to read it in context rather than in isolation, weighing volume, correlated markets, and recent history before drawing conclusions. Investors who build that habit tend to make steadier decisions once the opening bell rings, regardless of which direction the overnight numbers pointed. For those looking to track this data directly, platforms like TradingView provide a Dow futures chart with historical comparisons and customizable tools that make it easier to move from simply watching the market to actually understanding it.
For how often people invoke it, the concept of “hell” in Christianity is remarkably vague and nebulous, as both the Old and New Testament barely go into detail about the concept. As such, I’m glad Microsoft has now given us a clear vision of hell and what, exactly, it looks like, ending centuries of denominational disagreements. Microsoft is currently selling the idea of Windows and Copilot as two separate things: an OS and an assistant riding along on top of it. However, a leaked video shows Project Aion, an internal prototype where Copilot doesn’t just sit inside Windows, it becomes Windows, swallowing the Start menu, the taskbar, and three decades of desktop conventions in the process. The footage is reportedly two years old, so Aion is most likely dead by now. But it’s the clearest look yet at how far Microsoft was willing to take its agentic AI ambitions. ↫ Alfonso Maruccia at Techspot Everything about this is dreadful. Obviously replacing the entire shell with “AI” nonsense is the main crime against usability here, but on top of that, this new shell is all just websites, all the way down, so everything is slow and stuttery. Since this runs on something called “Win3”, which appears to be a very minimal, stripped-down version of Windows intended to only run the Edge browser engine, you can’t run Win32 applications. If you do try to run a Win32 application, it will load the application in a remote virtual machine running in the cloud, which I;m sure does wonder for performance, responsiveness, and latency. We can all thank the lord this project is two years old and most likely cancelled by now, but we have no way of knowing if Microsoft is still intending for this to be the future direction of Windows. Since people don’t want to use “AI” of their own volition, it only makes sense in the technology industry’s sick, twisted mind to force people into using “AI” with efforts like this. Consent has never been Silicon Valley’s strength, after all. At the time of writing, Microsoft is 225 billion dollars in the red on “AI”, so I wouldn’t be surprised if attempts to replace the regular Explorer shell with something “AI”-based is still very much on the table in Redmond.
NetBSD is the only BSD without a Vulkan stack (Mesa and Lavapipe), but that’s about to change. The effort to bring Vulkan to NetBSD is now in beta, with prebuilt binaries coming soon. Mesa configures, compiles, links, installs, and registers the Lavapipe software Vulkan driver on NetBSD 10.1 amd64, against LLVM 19.1.7. The driver (libvulkan_lvp.so, ~17 MB) installs into /usr/pkg/lib, and its ICD manifest (advertising Vulkan API 1.4) installs into /usr/pkg/share/vulkan/icd.d/, so a Vulkan loader on the system can discover it. ldd resolves every dependency cleanly. The entire process — environment setup, dependency builds, the Mesa build, and installation — is automated end to end and reproducible on a fresh install. ↫ vulkan-netbsd GitHub page It’s important to note that the next step in the process is to port the Vulkan loader, which is required to actually run Vulkan applications. This entire effort is still ongoing and seems to be handled mostly by Dean Howell alone, so expect breakage and incomplete documentation as development progresses. Still, this is a hugely important effort, and seeing it this far along is great news.
EveryMac turned 30. On July 2, 1996, EveryMac.com launched. Thirty years is a long time — and a great deal has changed since then — but what has not changed is that EveryMac.com has been there to provide you with detailed info on every Mac from the original 128k to the current line. Thank you very much for your support through the years. ↫ EveryMac news item I thought OSNews was pretty unique with its founding in 1997, so it’s great to see another enthusiast’s website as old as ours. Amazing company to be in, too – EveryMac is an indispensable, tirelessly maintained, and stupidly accurate resource that I use countless times each year. Here’s to another 30 years.
The clock is ticking for Android as a (somewhat) open platform. If you are running Android 8 or higher, a virus has been installed on your device and is silently awaiting remote activation. Over the past few months, devices around the world have been infected with this novel strain, with as many as 4 billion Android handsets and tablets estimated to have already been contaminated, meaning that around half of all humanity may be at risk from this threat. Disguising itself as the innocuously-titled “Android Developer Verifier” (ADV) process, this trojan horse runs surreptitiously in the background as a system service with full root privileges, quietly awaiting an activation signal. The service cannot be blocked, disabled, or removed. Unlike a commonplace bit of malware, this extraordinary strain won’t be detected and neutralized by Play Protect (the malware scanning and remediation service that is installed on all Android Certified devices). In fact, Play Protect is itself the vector through which this virus is transmitted and installed. That is because it is Google themselves who is propagating ADV. And once activated, this malevolent process has exactly one goal: to block you from running software by developers who haven’t been approved centrally by Google. ↫ The F-Droid news website If nobody steps up, if no regulator takes on Google in this matter, we could very well be looking at the end of F-Droid and similar open source application repositories on Android. I use F-Droid, and in fact, one of the most important and most-used application on my Pixel 10 Pro comes from F-Droid: Fennec. This Firefox fork is not available through any Google-sanctioned means, and I could just wake up one day and have the browser on what is supposed to be my phone stop working. Age verification, tying crucial services to iOS and Google Android, killing the ability to install your own software on your phone, purposefully making people hopelessly addicted to and dependent on “AI”, and so much more – we’re facing a multi-pronged attack designed to beat us into submission and give up on the idea of Free computing. I have to admit I’ve lost all hope we’ll be able to win this battle, as the combined interests of technology megacorporations and our own governments are just too powerful to fight. I feel like we’re living in the computing end times.
What if you need to do very low-level testing involving the very guts of Windows NT, but don’t need most of the userland that sits on top? In fact, what if that userland only slows you down and complicates the work you’re trying to do? The solution is Windows PE (Windows Preinstallation Environment). It is an official, stripped-down environment distributed with every Windows ISO image. It runs entirely in RAM, requires as little as 512 MB of memory, and lacks support for DirectX, the PowerShell subsystem, or the standard graphical shell (Explorer). Booting by default with NT AUTHORITY\\SYSTEM privileges makes it an ideal test harness for both of these tasks. The following analysis focuses on the low-level mechanisms of WinPE, as well as BCD and QEMU modifications that allow transforming this system into an ultra-fast, idempotent testing environment. ↫ Piotr Bednarski Now, the kind of work Bednarski does isn’t the most common of tasks, but I’ve often wondered just how far you can get by bolting on whatever WinPE will allow you to. There were various unofficial third-party tools that built Windows live CDs based on WinPE, but I think most of those have died out by now. If you look hard enough, you can also find some other utilities people made for WinPE, including even some rudimentary web browsers. Regarding web browsers, modern efforts seem to run into issues. WinPE is not really meant for any advanced functionality, but I really do wonder how capable you can make it without turning it into regular Windows.
M/PC is a concatenative operating system for Varvara, inspired by Openfirmware, designed to manage files on system without a file browser. It uses the postfix notation, meaning that the function success their operands. ↫ M/PC website I’m not going to pretend to really understand what any of this means.
Recently, there has been a surge in slopcoded new/hobby “operating systems”. Such slopcoded projects – which, due to the nature of “AI” tools, effectively consist of stolen code – will not be featured on OSNews and submitting them is fruitless. Other websites may choose to employ lower standards, as is their prerogative, but OSNews will not. I obviously cannot guarantee nothing will ever slip through the cracks, but I will take utmost care to ensure OSNews remains free of these so-called “sloperating systems”. Plagiarism, license-washing, and code theft have no place in the world of enthusiast and hobby operating systems.
European governments are rolling out digital identity wallets, which are to be used by citizens to access services, and to verify their age online. As reported by Follow the Money and Android Authority, there is a serious problem with this: these wallets rely on safety services of Google and Apple. These are known as Google Play Integrity API, and Apple’s Managed Device Attestation. Such safety services (known as “remote attestation”) are used to ensure that wallet apps run on hardware that is not tampered with. In this article we explain why the EU-wallet case is part of a bigger problem: by embedding these safety services in public infrastructure, Europe risks making society dependent on private companies while serving their corporate interests. ↫ Danny Lämmerhirt Setting aside the age verification nonsense, the fact that some European government are tying their identification services to iOS and Google Android is absolutely bonkers, especially in this day and age. There’s endless talk about reducing European dependence on the American tech giants who seem all too eager to do roll over when the Trump regime so much as glances in their general direction, and yet, they seem to want to effectively force us citizens to use American tech products. Essential online tools, like banking, government services, communication services, digital driver’s licenses, and more, should not require the use of iOS or Google Android.
There’s a lot you can say about macOS, but one thing Apple used to be incredibly good at were making beautifully crafted, detailed icons. As with almost every other aspect of macOS, this deteriorated sharply over the years, with the recent macOS releases with Liquid Glass being an absolute low point. Not only have they become bland and featureless, Apple also started forcing every icons to have the exact same rounded-rectangle shape, making them even harder to distinguish from one another. Rogue Amoeba, a company with a long history of developing applications with beautiful iconography, published a blog post pleading Apple to go back to proper icon design. With last year’s release of MacOS 26 (Tahoe), Apple made a mess of app icons. In the first betas of MacOS 27 (Golden Gate), however, there are signs of a turnaround. We’re urging Apple to continue making improvements, by restoring the ability for MacOS app icons to have distinct shapes. ↫ Paul Kafasis at the Rogue Amoeba blog I really hope Apple will turn its icon ship around.
If you have a Sega Mega Drive, you obviously want to run Linux on it. That’s something you can do now. You do need to have an EverDrive, but don’t worry, the port in question contains a custom fork of Qemu for those of us that don’t. I don’t know what else to say, other than I wonder why nobody did this sooner.
2FA still adds useful protection, but it cannot stop every account takeover. Passkeys, security keys, and phishing-resistant MFA are harder to bypass. Why 2FA Was Once Considered the Gold Standard Passwords had an obvious weakness: anyone who obtained one could try to log in. 2FA changed that by asking for another form of proof, such as a code sent to the user’s phone. This made 2FA a practical choice for both businesses and users. However, SMS codes and other traditional methods are easier to bypass than passkeys or hardware security keys. Why Traditional 2FA Is No Longer Enough 2FA has significantly improved account security over the years, but certain 2FA solutions can still be compromised through more advanced techniques. Threat actors have found creative ways to exploit human psychology, poorly designed account recovery processes, and weaker verification methods. Attack Method How It Works Why Traditional 2FA May Not Stop It Phishing Attackers create fake websites or messages to trick users into revealing login details and verification codes. Users may unknowingly provide both their password and 2FA code to attackers. SIM swapping A criminal takes control of the victim’s phone number by having it moved to another SIM card. SMS-based 2FA codes can be received by the attacker instead of the account owner. Session hijacking Attackers steal or misuse session cookies or tokens from an already authenticated browser or device, allowing them to access an account without repeating the original login and 2FA process. A second verification step may not protect an already authenticated session. The presence of such threats does not, however, make 2FA ineffective – it would still have prevented many cases of unauthorized access. The fact remains that older forms of 2FA should be supported by stronger security measures to provide more robust protection. How Online Casinos Protect Player Accounts Licensed online casinos rarely depend on 2FA alone. They may also verify a player’s identity and device, encrypt connections and payments, flag unusual activity, and send login alerts, although measures vary by operator and jurisdiction. Before registering or depositing, players should review an operator’s licence, privacy policy, payment security, login controls, and verification procedures. The Slotozilla mainpage provides online casino reviews, casino bonus information, free slot demos, and practical gambling guides. Slotozilla does not operate casino accounts or accept real-money wagers; it is an independent informational and entertainment website. These resources can support preliminary research, but players should still verify the operator’s licence, terms, security settings, and responsible gambling tools directly on its website. What Provides Better Protection Today? One login check is no longer enough for every situation. Many services now add passkeys, security keys, and checks for unusual activity to their existing 2FA systems. CISA recommends phishing-resistant MFA, particularly FIDO/WebAuthn authentication. The FIDO Alliance explains that passkeys use public-key cryptography and are tied to the correct website, making them resistant to conventional phishing. Practical Steps Users Can Take to Improve Account Security Improving account security requires several protective measures. Strong authentication should be combined with safe digital habits. These steps can significantly reduce account security risks. Regular reviews help keep protection effective as threats evolve. FAQ Is SMS 2FA still safe? SMS codes still add a useful barrier if someone gets hold of your password. The weak point is the phone number itself, which can be taken over through SIM swapping or recovery scams, so an authenticator app, passkey, or security key is a better choice when offered. What is 2FA versus MFA? 2FA is a form of MFA that uses exactly two authentication factors. MFA is the broader term for systems requiring two or more factors, such as something you know, something you have, or something you are. Are passkeys safer than passwords? A passkey cannot be reused or entered on a fake login page in the way a password can. It works only with the service that created it, so ordinary phishing and credential stuffing are far less effective. Should I still enable 2FA? Yes, turn on 2FA whenever an account offers it. If the account offers the option of passkeys or hardware security keys, it’s usually the most secure against phishers and account takeovers. Authenticator apps will still help, compared to text message (SMS) codes, and if none of those stronger methods is available, then SMS 2FA is still much better than using just your password. Which authentication method is best? Passkeys and FIDO security keys are difficult to steal through a fake login page. Even so, an account may still be exposed through weak recovery settings, an unprotected device, or a stolen active session.
