Click To Pray, the official prayer app of the Pope’s Worldwide Prayer Network, was found to have zero security by a security researcher. According to BobDaHacker, they discovered in January 2026 that the Vatican-linked app had zero security, allowing anyone to access user data through the API endpoint by simply typing in user IDs. They emailed nine individuals about the vulnerabilities as soon as they discovered them but received no responses and saw no changes for six months.

The information that anyone could get from the Click To Pray app’s database included first and last names, email addresses, and birthdates, among other information. You may not think this is much, but getting names and email addresses is more than enough for bad actors to start sending phishing emails to vulnerable users. BobDaHacker also pointed out that most of the app's users are likely older people who aren’t tech-savvy, so any enterprising scammer could tap into the app for a literal treasure trove of email addresses.

It was also easy to get the complete list automatically. The user ID assigned to new accounts is sequential, and since there’s no rate limiting for the API, all it takes is one GET request per user to capture all that information. Aside from this, the validation_hash used to verify the validity of an account signup is also stored in the clear, meaning anyone with access to the API can verify an account by opening their inbox. The email also had security issues that make it look like a phishing email, even if it’s legitimate.

You may think that a prayer app shouldn’t be much of a target for cybercriminals, especially as this has a small install base compared to the 16 billion accounts exposed in one of the largest data breaches in history. But the fact that it had almost 720,000 accounts as of July 2026 meant that there’s a lot of possible targets within that database. Even if just 1% of these users respond to an enterprising cybercriminal who harvested their email addresses from the app, that’s more than 7,000 different individuals who could lose money because of this leak.

BobDaHacker waited for six months for a response, but, unfortunately, no one related to the app responded to their concerns. Because of this, they contacted Nate Neslon, a security journalist for Dark Reading (who similarly received crickets after contacting them), who published a story about it. It was only after the news went live that the app’s security lapses were fixed, even if BobDaHacker wasn’t, at the very least, acknowledged by the makers of the app. Hopefully, no other hackers were aware of the weaknesses of the Click To Pray app.

Bob is a hacker. Just over three months ago, they found serious vulnerabilities in Frontier Airlines' API and website that would let anyone with a boarding pass code for a flight retrieve every passenger's personal information, including but not limited to home address, nearly all credit card info, full passport details, and even TSA PreCheck codes. The boarding pass code (called PNR) is written on the pass itself, or scannable via its barcode; plus, since it's only six digits, it's easy to loop through, something they replicated to find several passengers' full info.

Bob notified Frontier about the problem, but the company did very little to fix it; getting a hold of the aforementioned info now required the passenger's last name, also printed on the pass. So they published a post on their blog detailing several vulnerabilities in Frontier's website.

The security vulnerability is dead simple: all you have to do is take a peek at someone's boarding pass, and either note the number and the person's last name, or scan the associated barcode. Any of these is trivial with a phone. Then you feed that info into one of Frontier's mobile API endpoints, and presto, you'll get a reply back that includes every passenger's home address, e-mail, phone number, full date of birth, full passport data, almost the entire credit card info save for the 5 middle digits and the CVV, payment history, TSA PreCheck code, and more.

All of that info is usable for identity theft, stalking, or any other number of nefarious criminal activities. The TSA PreCheck code (Known Traveler Number) is particularly concerning for airlines, as it opens the possibility of an identity thief getting past security checks. As for the credit card number, since the first six numbers and last four are exposed along with the cardholder's name and expiration date, it's easy enough to guess the middle five digits, and then the CVV code at the back becomes the sole load-bearing security feature.

This is hardly the end of it, though. As Bob came to find, the booking management pages on Frontier's website (also reachable with just the booking number and a last name) equally expose personal information in their source code and/or API requests. Standard security practices dictate that easily-accessible pages like this use the principle of data minimization, retrieving and displaying the bare minimum until absolutely necessary.

Bob found that the "Manage My Booking" page clearly shows the name, e-mail, and phone number in the source code, while that of the "Passengers / Edit" page reveals each person's full name, country, date of birth, full passport info, and TSA PreCheck number again. Ironically, Frontier attempted a fix for the former issue, only to have the fixed version reveal more info than it originally did. These pages do obscure the data for display purposes, but it's right there in the source code and API calls.

The security expert originally reached out to Frontier on March 3 and followed up on March 9, attempting to follow the standard 90-day disclosure procedure. The company fixed the one vulnerability and sent Bob a model plane for their trouble. Bob followed up with the additional data-exposing issues and started a "compensation discussion" with the company. Frontier apparently flip-flopped on a proper response. Now, Bob says Frontier's critical vulnerabilities are still live and that Frontier's passengers "deserve better."

Australia-based AI consultant and founder of Agentic Labs Jesse Davies woke up to an unpleasant surprise earlier this month: A Google Cloud bill of $25,672.86 AUD (approximately $18,391.78 USD) — even though there was a budget of $10 AUD (approximately $7 USD) on his account. And it happened overnight.

According to Davies' account on LinkedIn, he was well-versed with Google AI Studio and had followed practices such as per-project API keys, separate billing accounts, two-factor authentication, and Cloud audit logging. However, it only took a single weak link to nullify those precautions, as evidenced by the shockingly large overnight bill. On top of that, Davies found nine Google Cloud safety features that should have prevented this incident — but that were turned off by default.

"The attacker didn't steal my key. They found a Cloud Run service I'd published from AI Studio months earlier, hit the public URL, and Google's own proxy signed every request on their behalf using the API key stored as a plaintext environment variable in the container," Davies wrote in his LinkedIn post.

"Even though it was public, the link wasn't shared or indexed anywhere. By the time I got a budget alert the next morning, A$10,000 had already been charged to my credit card, now getting insufficient funds. I was still talking to Google support when A$15,000 more came through."

What’s worse was that Google automatically upgraded the tier of Davies' account without any notification. The account was initially at Tier 2, which had a $2,000 limit, but Google automatically upgraded it to the next level when the account crossed the $1,000 threshold during the incident. This increased the cap to between $20,000 and $100,000. While this is likely designed to make it easier for a service to scale, it also has the unwanted effect of costing the user more than intended, e.g. if they are the victim of an attack.

Went to bed with a $10 budget alert. Woke up to $25,672.86 in debt to Google Cloud. from r/googlecloud

Their headaches did not end here, though. It took several days before Davies was able to get through to a real human customer support. Thankfully, it seems that the charge has been waived, while the transactions that actually pushed through were credited back by their bank. Still, the issue isn’t settled, and Davies has a meeting scheduled with Google managers to talk about the case.

Davies also shared the experience on Reddit, on the r/googlecloud subreddit, and asked if other users had similar stories to share. It turns out they did — several other users reported getting hit with insane bills, including one commenter from Japan who said that they were hit with a $44,000 bill that ballooned to $128,000 even after they paused the API. And last month, we covered a case in which an API thief racked up $82,314.44 in charges on an account that typically saw around $180 per month.

Cybersecurity firm Truffle Security Co. has already highlighted the risks associated with Google Cloud using a single API key format. These API keys were previously used as project identifiers, but when the Gemini API is activated on any Google Cloud project, these existing API keys become Gemini credentials — allowing anyone who can copy them to rack up AI bills. So... it's likely we'll see more horror stories of shocking API bills if Google doesn't update its Gemini policies.

Microsoft’s DirectSR upscaling API supports AMD’s FidelityFX Super Resolution (FSR) 3.1. Microsoft’s DirectSR tool, an API for game developers to program support for all three significant graphics upscaling techs in games, will make it easier for games to support FSR 3.1 in addition to the other upscaling modes.

DirectSR is an API for DirectX12 games that allows game developers to enable support for multiple upscaling tools with a single code path. AMD’s FSR 3.1, Nvidia’s DLSS, and Intel’s XeSS often see mutual exclusivity in video game releases because coding support for all three upscaling solutions is an undue time expense. DirectSR effectively unifies the three solutions, allowing developers to support all three upscalers with a single API.

DirectSR had native support for FSR 2.2 in its earliest iterations, with Intel and Nvidia support requiring additional drivers. The new FSR 3.1 support is likewise baked into the DirectSR runtime, requiring only an update to the newest preview releases of the API. Thanks to better temporal awareness, FSR 3.1 offers improved ghosting reduction and reduced flickering or shimmering.

So far, only 43 games are listed with FSR 3 support on AMD’s FidelityFX landing page. This is largely due to the ubiquity of Nvidia GPUs and, therefore, an obvious preference for DLSS support in games. DirectSR’s FSR 3.1 support is likely to come with a much easier workflow for implementing the tool and a wider berth of high-end upscaling support for AMD users.

DirectSR seeks to succeed as a widely supported development tool, whereas Nvidia’s Streamline SDK did not. Back in 2022, Streamline sought to offer the same one-stop multi-vendor support as DirectSR, but AMD opted out of supporting the SDK. Intel was linked to the tool early on, but XeSS support in Streamline has never materialized. DirectSR’s links to Microsoft seem to have given it more life than Streamline’s “open-source” status.

Game developers interested in implementing the new FSR 3.1 support in DirectSR can find it through the Agility SDK 1.715.1-preview release. The tool is officially in prerelease, so full support and better bug squashing are yet to arrive.

Nvidia's RTX Remix toolkit, which is used to mod DirectX8 and DirectX9 games with ray-tracing and remastered materials, was announced on June 2 to be going open source, with the Beta already available for download and the complete Toolkit set to be updated later in June. Besides the open source announcement, Nvidia also demonstrated RTX Remix's new functionality with Portal (the original game, not the pre-Remix RTX remaster) and demonstrated both upscaling and remastering existing texture work with physically based rendering (PBR) and allowing AI prompts to customize the look of the game even further.

With the open-sourcing of RTX Remix and the implementation of the new Rest API, it seems that Pandora's Box has finally been opened for easy, fan-made remasters of classic PC games still stuck in the pre-RT, DirectX8/DirectX9 era. Even if you have no practical experience at all and don't wish to alter the game you're playing fundamentally, the most basic form of RTX Remix can now seamlessly upscale all the existing textures in the game and apply realistic PBR lighting to those materials as well.

Open-sourcing RTX Remix may also improve the long-run look for AMD GPU users who want to participate in this fun, but for now, AMD GPUs will only be running RTX Remix titles in their completed forms. Nvidia's full RTX Remix toolkit for developing these remasters, or mods rely on a lot of proprietary Nvidia kit and, thus, is most likely impossible to use on AMD cards at all, at least not without lots of development effort from AMD and perhaps even Nvidia in conjunction.

Now, we can't ignore the elephant in the room here. Generative AI's adoption in the broader gaming sphere has been controversial, and for good reason! The push for generative AI and AI PCs has been highly scrutinized, particularly as it relates to game development, art, acting, writing, and other laborers. Fortunately, some companies, like Nintendo, outright reject it— and others, like Take-Two, recognize that while it can enhance some processes, its employees are still the priority if they want to turn around quality products.

In the context of RTX Remix, it's difficult not to be impressed by how the new REST API leverages ComfyUI and Stable Diffusion to remaster or even retexture a classic game near-instantly, with only a text prompt. The long-term ethical ramifications await to be seen, but for now, this serves as a fascinating proof-of-concept for how AI can enhance game dev and game modding workflows. It still feels a little slimy, though, considering how artists are currently suing Stable Diffusion for using their work to train AI models without permission.

The language you're using for a Large Language Model (LLM) can have a huge effect on its cost and create an AI divide between English speakers and the rest of the world. A recent study shows that, due to the way services like OpenAI, measure and bill for server costs, English-language inputs and outputs are much cheaper than those in other languages with Simplified Chinese costing about twice as much, Spanishing costing 1.5x the price and Shan language going for 15 times more.

Analyst Dylan Patel (@dylan522p) shared a photograph that leads to research conducted by the University of Oxford which found that asking an LLM to process a Burmese-written sentence cost 198 tokens, while that same sentence in English cost just 17 tokens. Tokens representing the computing power cost of accessing an LLM through an API (such as OpenAI's ChatGPT or Anthropic's Claude 2), this means the Burmese sentence cost 11 times more through the service than the one written in English.

The tokenization model (which sees AI companies convert user input into computational cost) means that in a less-than-ideal world, models accessed outside the window of English language are much more expensive to access and train on. That's because languages such as Chinese have a different, more complex structure (either grammatically or by number of characters) than English, which results in their higher rate of tokenization. 

For example, according to OpenAI's GPT3 tokenizer, giving someone a token of "your affection" would be just two tokens in English but eight tokens in Simplified Chinese. This is true even though the Simplified Chinese text is just 4 characters (你的爱意) and the English one is 14 characters. Aleksandar Petrov et al's Tokenization Fairness page has a number of charts and tools you can use to see the disparity between languages.

OpenAI itself has a pretty helpful page explaining how it monetizes API access and usage of its ChatGPT model, which even includes access to a tokenizer tool that you can use to test the token cost per prompt. There, we see that 1 token is around 4 characters in English, and that 100 tokens would be around 75 English words. But that math just can't be applied to any other language, as OpenAI clearly puts it. 

There's really no competition against the cost-effectiveness of English in AI-related costs; Chinese, for example, costs twice as much as English in terms of required tokens per output. But it's simply a reflection of the available training data that AI companies have (until now) used to train their models on. If there's one thing the AI explosion has done for the world is show just how valuable high-quality emergent data (that which is created as a record of life) really is.

This issue directly links with AI companies' desire to achieve recursive training, or the ability to train AI models on their own outputs. If that's achieved, then future models will still show the same cost-effectiveness of English compared to other languages whose complexity and more limited availability of base training data. And when that happens, it's not just this vicious cycle of algorithmic bigotry we have to contend with: it's also that for now, research points to AI networks going MAD when trained over five times on their own outputs (synthetic data).

To further complicate the issue, it seems that other ways of quantifying costs (other than tokenization) would end up running into the same problems. Either via bit or character-counting, apparently no language can beat the pragmatic practicality of English - it would still present lower costs due to its inherently higher "compressibility" into a lower token count. 

That means the issue isn't in the way models have been monetized; it's an actual limitation of the technology and base models considered for training. And it should be no surprise to know the issue impacts multiple language models across their versions. They're all built mostly the same, after all.

This issue looks like a predictable one when we consider that the companies actually introducing Large Language Models (such as ChatGPT) or Generative Image networks (such as Midjourney) are mostly based in America. Lower usage costs and higher availability of quality data comes with the territory, in a way.

This cost difference has already led to a number of countries launching their own initiatives to train and deploy a native-language LLM. Both China and India have done so, and both claimed the same thing: that their plans were needed to accompany the pace of innovation allowed by English-based AI networks. And that rate is mostly limited by access and training costs.

It's only natural that everyone is looking to pay as little as possible for as much as possible; and these dynamics directly affect the cost of LLM training and deployment according to the base language. It's almost like this AI business is so complex, and its consequences so far-reaching, we have to be very careful with every little step we take.

AMD announced that it has released the HIP SDK for Windows intending to democratize GPU computing. You no longer must choose between Team CUDA or Team HIP, as the HIP SDK will help developers make CUDA applications run on AMD hardware. Notably, this new SDK will run on a select number of consumer Radeon GPUs.

There has always been a significant divide between developers that work with GPU-accelerated applications. Some prefer Nvidia's proprietary CUDA API, while others opt for the open-source HIP API. The HIP SDK, part of AMD's ROCm platform, wants to bridge that gap, allowing developers to convert CUDA applications into C++ code that will work on Nvidia and AMD graphics cards. ROCm targets HPC and AI applications, whereas HIP is for typical desktop applications.

AMD asserts that porting a CUDA application to HIP SDK isn't challenging since CUDA and HIP are based on C++. Furthermore, the HIP SDK provides tools to help developers speed up the process, such as the HIPIFY toolset that will convert CUDA code into portable HIP C++. The HIP SDK doesn't work miracles, such as optimizing code. That's still a manual task that you have to do by yourself.

The HIP SDK works on 32-bit and 64-bit Windows operating systems, including Windows 10 (22H2), Windows 11 (22H2), and Windows Server 2022. According to AMD, the list of compatible graphics cards extends from workstation-grade to mobile gaming. AMD even brags about APUs being on the list. Of course, support also depends on the developer. The chipmaker cites an example of Blender HIP embracing AMD Radeon graphics cards going back to the Vega days.

AMD is still updating the compatibility list, but only ten Radeon graphics cards, between RDNA 3 and RDNA 2, are officially supported thus far. The Radeon Pro W7900, W7800, and W6800 hail from the Radeon Pro lineup. On the consumer end, the Radeon RX 7900 XTX, RX 7900 XT, RX 7600, RX 6950 XT, RX 6900 XT, RX 6800 XT, and RX 6800 support the HIP SDK.

Offering HIP SDK on Windows is a milestone for AMD. Nonetheless, the chipmaker will continue to make HIP SDK better by adding new features in the future and making an effort to deliver updates on par with AMD Software: Pro Edition graphics driver.

In recent months there has been a groundswell of anecdotal evidence and general murmurings concerning a decline in the quality of ChatGPT responses. A team of researchers from Stanford and UC Berkeley decided to determine whether there was indeed degradation and come up with metrics to quantity the scale of detrimental change. To cut a long story short, the dive in ChatGPT quality certainly wasn't imagined.

Three distinguished academics, Matei Zaharia, Lingjiao Chen, and James Zou, were behind the recently published research paper How Is ChatGPT's Behavior Changing Over Time? (PDF) Earlier today, Computer Science Professor at UC Berkeley, Zaharia, took to Twitter to share the findings. He startlingly highlighted that "GPT -4's success rate on 'is this number prime? think step by step' fell from 97.6% to 2.4% from March to June."

GPT-4 became generally available about two weeks ago and was championed by OpenAI as its most advanced and capable model. It was quickly released to paying API developers, claiming it could power a range of new innovative AI products. Therefore, it is sad and surprising that the new study finds it so wanting of quality responses in the face of some pretty straightforward queries.

We have already given an example of GPT-4's superlative failure rate in the above prime number queries. The research team designed tasks to measure the following qualitative aspects of ChatGPT's underlying large language models (LLMs) GPT-4 and GPT-3.5. Tasks fall into four categories, measuring a diverse range of AI skills while being relatively simple to evaluate for performance.

• Solving math problems
• Answering sensitive questions
• Code generation
• Visual reasoning

An overview of the performance of the Open AI LLMs is provided in the chart below. The researchers quantified GPT-4 and GPT-3.5 releases across their March 2023 and June 2023 releases.

It is clearly illustrated that the "same" LLM service answers queries quite differently over time. Significant differences are seen over this relatively short period. It remains unclear how these LLMs are updated and if changes to improve some aspects of their performance can negatively impact others. See how much 'worse' the newest version of GPT-4 is compared to the March version in three testing categories. It only enjoys a win of a small margin in visual reasoning.

Some may be unbothered about the variable quality observed in the 'same versions' of these LLMs. However, the researchers note, "Due to the popularity of ChatGPT, both GPT-4 and GPT-3.5 have been widely adopted by individual users and a number of businesses." Therefore, it isn't beyond the bounds of possibility that some GPT-generated information can affect your life.

The researchers have voiced their intent to continue to assess GPT versions in a longer study. Perhaps Open AI should monitor and publish its own regular quality checks for its paying customers. If it can't be clearer about this, it may be necessary for business or governmental organizations to keep an check on some basic quality metrics for these LLMs, which can have significant commercial and research impacts.

AI and LLM tech isn't a stranger to surprising issues, and with the industry's data pilfering claims and other PR quagmires, it currently seems to be the latest 'wild west' frontier on connected life and commerce.

Earlier today, the Linux Foundation shared a new press release detailing plans for the Ultra Ethernet Consortium (UEC). This effort involves several prominent industry leaders, including AMD, Arista, Broadcom, Cisco, Eviden, HPE, Intel, Meta, and Microsoft. The consortium intends to optimize Ethernet standards for high-performance networking.

As more advancements are made in artificial intelligence, machine learning and other forms of high-performance computing, so are the demands of the networks that support these systems. The goal of UEC is for the involved companies to work together in improving the standards of modern networking protocols so they might be better equipped to handle the workloads of these newer advanced systems.

Dr. J Metz is Chair of the Ultra Ethernet Consortium and stated that there is no need to overhaul Ethernet, but instead, the team hopes to make adjustments over time that will improve efficiency.

So far, a few specific technical hurdles have been identified, which the consortium intends to focus upon. This involves the development of APIs and specifications for various Ethernet communication protocols, interfaces and data structures to suit the needs of high-performance technology better.

Additional areas of interest include both link-level and end-to-end network transport protocols. The press release also mentions congestion, signaling mechanisms, and telemetry as necessary targets. What this looks like in practice will only be apparent in time, but we can expect things like new software and Ethernet security protocols developed with AI, machine learning, and high-performance computing in mind.

You can read more about the UEC on their official website, including frequently asked questions and news and updates. The latest press release also provides plenty of information about forming the new consortium and its future goals.

A new plugin mod for CD Projekt Red's divisive (yet culty) Cyberpunk 2077 has been launched that's likely the one mod to mod them all. CyberAI, as it's been named by its creator, "tomatojuice", enables integration between the neo-chrome of Cyberpunk 2077 and the synthetic abilities of OpenAI's ChatGPT. 

Available on NexusMods, CyberAI promises to bring worlds of synthetic content to anyone curious enough to try: using the console, users will be able to query OpenAI API methods from Lua or Redscript, essentially allowing you to bring ChatGPT's scripting abilities to code extreme modifications. "tomatojuice" lists a few things the tool can be used for, like creating custom NPC (Non-PLayer Character) dialogue; Dynamic Plot Generation, which enables creating entire storylines and sidequests based on in-game events or player actions; Procedural Mission Planning, which generates new missions with in-game context, NPC data (which can be custom itself), and other player preferences; and the creation of interactive environments, which through AI generates more dynamic environment conditions while enhancing the interaction between elements.

Of course, it'd be a pity not to improve the game's own AI routines — the ones that control NPC behaviors and game simulation responses to events. These have been found to be somewhat of a miss with Cyberpunk 2077 (at least that perception will remain until the release of the game's next expansion, Liberty City, and the depth of its promised AI improvements). But with the ability to edit the enemy's AI behavior, users can script entire worlds within Cyberpunk 2077.

For example, you could create a script that verifies whether the player character kills a custom NPC; if so, that event then triggers a ChatGPT-generated storyline that can essentially interact with every mechanic employed by Cyberpunk 2077. A low-gravity mission against a group of chromed, monk cultists that are attempting to uncover whether their world is a video game simulation played in someone's bedroom PC in the year 2023? 

You can go and create that right now.

As "tomatojuice" stresses, imagination really is the limit. And there's even added flexibility to connect to other LLMs (Large Language Models) other than OpenAI's ChatGPT. That truly brings anyone's options through the proverbial roof: you can create custom missions that have NPC dialogue written by ChatGPT or Anthropic's generally more friendly Claude, of which version 2 was just launched. That way, you'd have different modalities between each model you add into the mix, making the world even more varied.

And it may sound impossible, but you can actually do even more than that: you can use one of our guides and create your personal ChatGPT, training it on data of the experiences you've loved the most. Feed it your favorite scripts, your favorite plotlines, books, and even personal journals, and see NPCs surround you that actually know you and respond with knowledge of your universe.

Your own Cyberpunk, whatever that means to you.

A developer has prepared a Windows 3.1 compatible application dubbed WinGPT. Described as an “AI Assistant for Windows 3.1,” the WinGPT app connects to the ChatGPT API natively. According to a blog post on the developer site dialup.net, the WinGPT app was developed so that Windows 3.1 users won’t feel closed off from the AI chatbot buzz that is prevalent in 2023.

WinGPT was written in C, compiled in Open Watcom v2, and uses a standard Windows API. This helps the resulting app look simple and very much like the Windows 3.1 era, as you can see. The same developer has prepared a TLS (Transport Layer Security) 1.3 protocol library so that Windows 3.1 can connect to the ChatGPT API natively. Compared with modern apps, this is a very light download, a zip file of only 218 KB includes a readme, the application, and the aforementioned TLS 1.3 DLL support file.

As the WinGPT app stands today, it is touted as being capable of helping Windows 3.1 users: do research, answer queries and questions, provide advice and tell jokes, and participate in other entertaining chats, working as a productivity helper by drafting documents and so on. However, the developer admits it isn’t the best way to access ChatGPT and can be limited and unreliable.

Some of WinGPT’s problems for users stem from the limited memory available on Win 3.1 machines. “JSON responses of modern APIs aren't especially optimized for size, and OpenAI's API is no exception,” notes the developer. Moreover, to conserve memory, the app doesn’t send chat history to the API calls, which means ChatGPT doesn’t use prior conversational context in this app.

Despite these drawbacks, getting up and running with WinGPT seems far simpler, easier, and fully featured than the DOS ChatGPT client we reported on in March.

If you want to try WinGPT, go and grab the lightweight download (scroll to the bottom of the article linked), which is licensed under GPL v2. The source code is also available. The program runs not just on Windows 3.1, but on “any 16-bit or 32-bit version of Windows post-Windows 3.1,” according to the developer. However, an implementation of Winsock is required, and it won’t run directly on Windows 64-bit editions (an emulator like Wine will be required). Lastly, an OpenAI API key is required, and you must enter it into the program’s options menu before you get started.

ChatGPT has managed to create some amusing and hilarious things in the right hands, like this Big Mouth Billy Bass project. However, there is a much darker side of AI that could be used to create some seriously complicated problems for the future of IT. A few IT experts have recently outlined the dangerous potential of ChatGPT and its ability to create polymorphic malware that’s almost impossible to catch using endpoint detection and response (EDR).

EDR is a type of cybersecurity technique that can be deployed to catch malicious software. However, experts suggest this traditional protocol is no match for the potential harm ChatGPT can create. Code that can mutate — this is where the term polymorphic comes into play — can be much harder to detect.

Most language learning models (LLMs) like ChatGPT are designed with filters in place to avoid generating inappropriate content as deemed by their creators. This can range from specific topics to, in this case, malicious code. However, it didn’t take long for users to find ways to circumvent these filters. It’s this tactic that makes ChatGPT particularly vulnerable to individuals looking to create harmful scripts.

Jeff Sims is a security engineer with HYAS InfoSec, a company that focuses on IT security. Back in March, Sims published a white paper detailing a proof-of-concept project he calls BlackMamba. This application is a type of polymorphic keylogger that sends requests to ChatGPT using an API each time it’s run.

“Using these new techniques, a threat actor can combine a series of typically highly detectable behaviors in an unusual combination and evade detection by exploiting the model’s inability to recognize it as a malicious pattern," Sims explains.

 Another cybersecurity company, CyberArk, recently demonstrated ChatGPT’s ability to create this type of polymorphic malware in a blog post by Eran Shimony and Omer Tsarfati. In the post, they explain how code injection from ChatGPT requests makes it possible to modify scripts once activated, avoiding the more modern techniques used to detect malicious behavior. 

At the moment, we only have these examples as a proof of concept — but hopefully this awareness will lead to more developments to prevent the harm this type of mutating code could cause in a real-world setting.

Before you start your day, it’s always helpful to peek at the current weather conditions. So what better way to plan your day than to program a Raspberry Pi for the task? While we’ve seen Raspberry Pi weather displays before, we wanted to share this beautiful Raspberry Pi dashboard created by Chris Twomey. It has a notably sleek interface, complete with a render of a local map based on your current location.

Weather data is taken from Accuweather/OpenWeatherMap API and formatted to display on an Inkplate 10. The Inkplate 10 is a 10-inch e-Ink panel, so it doesn’t use much power, and the data stays visible once the power has been cut off from the Pi. The generated map can be configured to any location you prefer and is shown underneath today’s date.

The map is generated using Google’s Static Maps API. Data is updated regularly on a schedule using MQTT and a server running on the Raspberry Pi. It also handles daylight savings time automatically, so you don’t have to make any adjustments throughout the year. Overall the project should operate on its own without interference.

Twomey tested the setup with a Raspberry Pi 3B+ and a Raspberry Pi Zero W. You should be able to duplicate this project with other models, including the latest Raspberry Pi 4. An ESP32 is also thrown into the mix as a client module to render the image onto the Inkplate 10. The dashboard is powered using a 2000 mAh battery, but Twomey suggests that 3000 mAh might yield longer-lasting results.

The Raspberry Pi needs to connect to the internet to pull data, so a model with wireless support is recommended. When the Pi wakes up, it connects to WiFi before updating the time and date. It’s running a Flask server, as well, to handle the update process for the weather data. You can read more about the software used in this project on the official GitHub page.

If you want to recreate this Raspberry Pi project or get a closer look at how it goes together, check out the Inkplate 10 Weather Calendar project page, and be sure to follow Chris Twomey for more projects and any future updates on this one.

Recently, we've seen AI models that produce detailed text-to-video or use run a chatbot on your phone. Now, OpenAI, the company behind ChatGPT, has introduced Shap-E, a model that generates 3D objects you can open in Microsoft Paint 3D or even convert into an STL file you can output on one of the best 3D printers.

The Shap-E model is available for free on GitHub and it runs locally on your PC. Once all of the files and models are downloaded, it doesn't need to ping the Internet. And best of all, it doesn't require an OpenAI API key so you won't be charged for using it.

It is a huge challenge actually getting Shap-E to run. OpenAI provides almost no instructions, just telling you to use the Python pip command to install it. However, the company fails to mention the dependencies you need to make it work and that many of the latest versions of them just won't work. I spent more than 8 hours getting this running and I'll share what worked for me below.

Once I finally got Shap-E installed, I found that the default way to access it is via Jupyter Notebook, which lets you view and execute the sample code in small chunks to see what it does. There are three sample notebooks which demonstrate "text-to-3d" (using a text prompt), "image-to-3d" (turning a 2D image into a 3D object) and "encode_model" which takes an existing 3D model and uses Blender (which you need installed) to transform it into something else and re-render it. I tested the first two of these as the third (using Blender with existing 3D objects) was beyond my skillset.

How Shap-E Text-to-3D Looks

Like so many AI models we test these days, Shap-E is full of potential but the current output is so-so at best. I tried the text-to-video with a few different prompts. In most cases, I got the objects that I asked for but they were low res and missing key details.

When I used the sample_text_to_3d notebook, I got two kinds of output: color animated GIFs which displayed in my browser and monochrome PLY files I could open later in a program like Paint 3D. The animated GIFs always looked a lot better than the PLY files.

The default prompt of "a shark," looked decent as an animated GIF, but when I opened the PLY in Paint 3D, it seemed lacking. By default, the notebook gives you four animated GIFs that are 64 x 64, but I changed the code to up the resolution to 256 x 256 outputted as a single GIF (since all four GIFs looks the same). 

When I asked for something that OpenAI had as one of its examples, "an airplane that looks like a banana," I got a pretty good GIF, particularly when I upped the resolution to 256. The PLY, file, though, exposed a lot of holes in the wings. 

When I asked for a Minecraft creeper, I got something that a GIF that was correctly colored green and black and a PLY that was in the basic shape of a creeper. However, real Minecraft fans would not be satisfied with this and it was too messy of a shape to 3D print (if I had converted it to an STL).

Shap-E Image to 3D Object

I also tried the image-to-3d script which can take an existing 2D image file and turn it into a 3D PLY file object. A sample illustration of a corgi dog became a decent, low-res object that it outputted as a rotating, animated GIF which had less detail. Below, the original image is on the left and the GIF is on the right. You can see that the eyes seem to be missing. 

By modifying the code, I was also able to get it output a PLY 3D file that I could open in Paint 3D. This is what it looked like.

I also tried feeding the image-to-3d script some of my own images, including a photo of an SSD, which came out looking broken and a transparent PNG of the Tom's Hardware logo, which didn't look much better.

However, it's likely that if I had a 2D PNG that looked a bit more 3D-ish (the way the corgi does), I'd get better results. 

Performance of Shap-E

Whether I was doing text or image to 3D processing, Shap-E required a ton of system resources. On my home desktop, with an RTX 3080 GPU and a Ryzen 9 5900X CPU, it took about five minutes to complete a render. On an Asus ROG Strix Scar 18 with an RTX 4090 laptop GPU and an Intel Core i9-13980HX, it took two to three minutes. 

However, when I tried doing text-to-3D on my old laptop, with has an Intel 8th Gen U series CPU and integrated graphics, it had only finished 3 percent of a render after an hour. In short, if you are going to use Shap-E, make sure you have an Nvidia GPU (Shap-E doesn't support other brands of GPUs. The options are CUDA and CPU.). Otherwise, it will just take too long.

I should note that the first time you run any of the scripts, it will need to download the models, which are 2 to 3 GB and could take several minutes to transfer.

How to Install and Run Shap-E on a PC

OpenAI has posted a Shap-E repository to GitHub, along with some instructions on how to run it. I attempted to install and run the software in Windows, using Miniconda to create a dedicated Python environment. However, I kept running into problems, especially because I could not get Pytorch3D, a required library, to install.

However, when I decided to use WSL2 (Windows Subsytem for Linux), I was able to get it up and running with few hassles. So the instructions below will work either in native Linux or in WSL2 under Windows. I tested them in WSL2.

1. Install Miniconda or Anaconda in Linux if you don't already have it. You can find a download and instructions on the Conda site.

2. Create a Conda environment called shap-e with Python 3.9 installed (other versions of Python may work).

conda create -n shap-e python=3.9

3. Activate the shap-e environment.

conda activate shap-e

4. Install Pytorch. If you have an Nvidia graphics card, Use this command.

conda install pytorch=1.13.0 torchvision pytorch-cuda=11.6 -c pytorch -c nvidia

If you don't have an Nvidia card, you'll need to do a CPU-based install. The install is speedy but processing the actual 3D generation with the CPU was extremely slow in my experience. 

conda install pytorch torchvision torchaudio cpuonly -c pytorch

5. Build Pytorch. This is the area where it took me hours and hours to find a combination that worked. 

pip install "git+https://github.com/facebookresearch/pytorch3d.git"

If you get a cuda error, try running sudo apt install nvidia-cuda-dev and then repeating the process.

6. Install Jupyter Notebook using Conda.

conda install -c anaconda jupyter

7. Clone the shap-e repo.

git clone https://github.com/openai/shap-e

Git will create a shap-e folder underneath the one you cloned it from.

8. Enter the shap-e folder and run the install using pip.

cd shap-epip install -e .

9. Launch a Jupyter Notebook. 

jupyter notebook

10. Navigate to the localhost URL the software shows you. It will be http://localhost:8888?token= and a token. You'll see a directory of folders and files.

11. Browse to shap-e/examples and double-click on sample_text_to_3d.ipynb.

A notebook will open up with different sections of code.

12. Highlight each section and click the Run button, waiting for it to complete before moving onto the next section.

This process will take a while the first time you go through it, because it will download several large models to your local drive. When everything is done, you should see four 3D models of a shark in your browser. There will also be four .ply files in the examples folder and you will be able to open those in 3D imaging programs such as Paint 3D. You can also convert them to STL files using an online converter.

If you want to change the prompt and try again. Refresh your browser and change "a shark" to something else in the prompt section. Also, if you change size from 64 to a higher number, you get a higher resolution image. 

13. Double-click on sample_image_to_3d.ipynb in the examples folder again so you can try the image-to-3d script.

14. Highlight each section and click Run.

You'll end up, by default, with four small images of corgis. 

However, I recommend adding the following code to the last notebook section so that it will output PLY files as well as animated GIFs.

from shap_e.util.notebooks import decode_latent_meshfor i, latent in enumerate(latents):    with open(f'example_mesh_{i}.ply', 'wb') as f:        decode_latent_mesh(xm, latent).tri_mesh().write_ply(f)

15. Modify the image location in section 3 to change the image. Also, I recommend changing the batch_size to 1 so it only makes one image. Changing the size to 128 or 256 will give you a higher resolution image.

16. Create the following python script and save it as text-to-3d.py or another name. It will allow you to generate PLY files based on text prompts at the command line.

import torchfrom shap_e.diffusion.sample import sample_latentsfrom shap_e.diffusion.gaussian_diffusion import diffusion_from_configfrom shap_e.models.download import load_model, load_configfrom shap_e.util.notebooks import create_pan_cameras, decode_latent_images, gif_widgetdevice = torch.device('cuda' if torch.cuda.is_available() else 'cpu')xm = load_model('transmitter', device=device)model = load_model('text300M', device=device)diffusion = diffusion_from_config(load_config('diffusion'))batch_size = 1guidance_scale = 15.0prompt = input("Enter prompt: ")filename = prompt.replace(" ","_")latents = sample_latents(    batch_size=batch_size,    model=model,    diffusion=diffusion,    guidance_scale=guidance_scale,    model_kwargs=dict(texts=[prompt] * batch_size),    progress=True,    clip_denoised=True,    use_fp16=True,    use_karras=True,    karras_steps=64,    sigma_min=1e-3,    sigma_max=160,    s_churn=0,)render_mode = 'nerf' # you can change this to 'stf'size = 64 # this is the size of the renders; higher values take longer to render.from shap_e.util.notebooks import decode_latent_meshfor i, latent in enumerate(latents):    with open(f'{filename}_{i}.ply', 'wb') as f:        decode_latent_mesh(xm, latent).tri_mesh().write_ply(f)

17. Run python text-to-3d.py and enter your prompt when the program asks for it.

That will give you a PLY output, but not a GIF. If you know Python, you can modify the script to do more with it.

Anyone can use ChatGPT for free, but if you want to use GPT4, the latest language model, you have to either pay for ChatGPT Plus, pay for access to OpenAI's API, or find another site that has incorporated GPT4 into its own free chatbot. There are sites that use OpenAI such as Forefront and You.com, but what if you want to make your own bot and don't want to pay for the API?

A GitHub project called GPT4free allows you to get free access to the GPT4 and GPT3.5 models by funneling those queries through sites like You.com, Quora and CoCalc and giving you back the answers. The project is GitHub's most popular new repo, getting 14,000 stars this week. 

Now, according to Xtekky, the European computer science student who runs the repo, OpenAI has sent a letter demanding that he take the whole thing down within five days or face a lawsuit.

I interviewed Xtekky via Telegram, and he said he doesn't think OpenAI should be targeting him since he isn't connecting directly to the company's API, but is instead getting data from other sites that are paying for their own API licenses. If the owners of those sites have a problem with his scripts querying them, they should approach him directly, he posited.

I installed GPT4Free in WSL2 (Windows Subsystem for Linux) on my PC. It took just a few moments, which involved cloning the Github repository, installing some required libraries with pip, and running a Python script. With the script launched, I used my web browser to visit http://localhost:8501, the address it gave me, and was presented with a working chatbot that was running off of my PC.

On the backend, GPT4Free is visiting various API urls that sites like You.com, an AI-powered search engine that employs OpenAI's GPT3.5 model for its answers, use for their own queries. For example, the main GPT4Free script hits the URL https://you.com/api/streamingSearch, feeds it various parameters, and then takes the JSON it returns and formats it. The GPT4Free repo also has scripts that grab data from other sites such as Quora, Forefront, and TheB. Any enterprising developer could use these simple scripts to make their own bot. 

"One could achieve the same [thing by] just opening tabs of the sites. I can open tabs of Phind, You, etc. on my browser and spam requests," Xtekky said. "My repo just does it in a simpler way."

All of the sites GPT4Free draws from are paying OpenAI fees in order to use its large language models. So when you use the scripts, those sites end up footing the bill for your queries, without you ever visiting them. If those sites are relying on ad revenue from their sites to offset these API costs, they are losing money because of these queries.

Xtekky said that he is more than happy to take down scripts that use individual sites' APIs upon request from the owners of those sites. He said that he has already taken down scripts that use phind.com, ora.sh and writesonic.com. 

Perhaps more importantly, Xtekky noted, any of these sites could block external uses of their internal APIs with common security measures. One of many methods that sites like You.com could use is to block API traffic from any IPs that are not their own.

Xtekky said that he has advised all the sites that wrote to him that they should secure their APIs, but none of them has done so. So, even if he takes the scripts down from his repo, any other developer could do the same thing.

The developer said that he doesn't believe he's liable for what others do with his script and that OpenAI should not be targeting him for using other sites' APIs, which are available unsecured on the open web. 

"OpenAI could also reach out to the sites and warn/notify them and in collaboration come to me and do a takedown, but it seems that this [legal threat] solely comes from OpenAI and they basically claim that I am directly attacking them," he said. "I do not really know, but it looks like if a site use OpenAI's API, it has OpenAI's legal protection and OpenAI is liable for the damages the site gets."

Xtekky initially told me that he hadn't decided whether to take the repo down or not. However, several hours after this story first published, we chatted again and he told me that he plans to keep the repo up and to tell OpenAI that, if they want it taken down, they should file a formal request with GitHub instead of with him. 

"I believe they contacted me before to pressurize me into deleting the repo myself," he said. "But the right way should be an actual official DMCA, through GitHub."

Even if the original repo is taken down, there's a great chance that the code -- and this method of accessing GPT4 and GPT3.5 -- will be published elsewhere by members of the community. Even if GPT4Free had never existed anyone can find ways to use these sites' APIs if they continue to be unsecured.

"Users are sharing and hosting this project everywhere," he said. "Deletion of my repo will be insignificant."

On Sunday, Xtekky made an announcement on the project's Discord channel, saying that he's making some changes to his chatbot, which lives apart from the GitHub repo but serves as a working example of what you can do with it. We haven't linked to the chatbot because it's at an adult domain name (but has no adult content), but you can find a link to it on the GPT4Free GitHub page.

"We're stepping away from our previous method and implementing a new system that will ensure a seamless and legal processing of requests. We're also proud to announce that a rebranding is in the works along with some other general fixes that will improve your experience," he posted.

Xtekky told me that he plans to move the chatbot to a different domain and to rebrand it as g4f (short for GPT4Free) and to change the logo it uses, which looks a lot like the OpenAI logo. It's unclear whether the repo name will change.

We reached out to OpenAI's press email for comment and will update this story if and when we receive a response.

If you want to try it while it's still there, check out GPT4Free on GitHub. If you want to set up your own ChatGPT-like chatbot without potentially running afoul of OpenAI's lawyers, see our tutorial on how to run ChatGPT on a Raspberry Pi or PC

A hobbyist software developer and retro computing enthusiast has succeeded in bridging the ChatGPT and IBM PC-XT computing divide. On the lookout for a challenge, Yo Kheng Meng wondered if he could write a ChatGPT client for MS-DOS. Specifically, he targeted a 1984 vintage IBM 5155 Portable PC, which is powered by a 4.77 MHz Intel 8088 CPU and has 640KB of RAM (enough for anyone, right?). Several technological obstacles needed to be surmounted to make the project a success.

Typically, most people access ChatGPT via a web browser, but it seems to be a growing trend to access this AI resource via a client. We have reported on some notable and fun clients like a ChatGPT Smartwatch powered by a Raspberry Pi and Microsoft’s much maligned Clippy with an AI brain transplant. However, getting ChatGPT to work on one of the most ancient of PCs might be even more ambitious.

Meng started his quest by finding a compiler which could span the 40 years or so gap between the target computer and ChatGPT. The Open Watcom C/C++ compiler fit the bill. To test the DOS application during development he decided to run it in a virtual machine (Virtualbox virtual machine running DOS 6.22) on a modern PC.

One of the biggest hurdles with DOS was with the networking required to connect to the ChatGPT service. Meng found that MTCP, written by Michael B. Brutman, would facilitate the connection to ChatGPT’s Chat Completion API. However, to communicate with this API required the developer to “construct the entire POST request by hand in C.”

A few further hurdles the developer had to pass included JSON parsing, changing the ChatGPT output from HTTPS to HTTP, and working with the lack of multi-threading in DOS. You can read more about how this was achieved in his full blog post.

OpenAI’s conversational AI ChatGPT (Chat Generative Pre-Trained Transformer) has gained lots of attention in and outside of the tech world since its debut late last year. It has spurred intense new competition between web titans like Google and Microsoft, it has helped clarify the potential of AI (and some downsides), and it has caused a mini-boom for many related businesses.

Microsoft is stepping up its investment in the artificial intelligence realm, and today announced it is expanding its partnership with OpenAI. According to Microsoft, this will be the third phase in its tie-up with OpenAI, representing a "multi-billion dollar investment" in its effort to be at the forefront of all things AI.

"We formed our partnership with OpenAI around a shared ambition to responsibly advance cutting-edge AI research and democratize AI as a new technology platform," said Microsoft CEO Satya Nadella. "In this next phase of our partnership, developers and organizations across industries will have access to the best AI infrastructure, models, and toolchain with Azure to build and run their applications."

From now on, Microsoft's Azure cloud infrastructure will be used exclusively to power OpenAI workloads, API services, research, and backend systems. Microsoft will also use OpenAI to enhance its products to create "new categories of digital experiences." Those experiences will leverage OpenAI's ChatGPT, a conversational AI routine that can be used to write articles, poetry, and even debug code. 

The Information reported earlier this month that Microsoft planned to fuse ChatGPT with its Bing search engine to become more competitive with Google (or, more specifically, the Google Knowledge Graph). Perhaps even more interesting is the rumor that claims Microsoft intends to bring the GPT text-generation model to Microsoft Word and Outlook. This would potentially let AI write emails for you based on input commands, or flesh out an article you're writing using information siphoned from the web. 

On that note, we used ChatGPT (using the GPT-3 language model) last week to inquire about how to build a PC. Unfortunately, despite ChatGPT's impressive capabilities, its advice on building a PC turned out to be pretty bad. Its instructions were grammatically correct, but would have likely resulted in the destruction of the CPU if followed by a tech neophyte. 

Microsoft's investment in AI should not come as a surprise to anyone. When Nadella announced that the company would lay off 10,000 employees this year, he noted that "the next major wave of computing is being born with advances in AI, as we're turning the world's most advanced models into a new computing platform." 

OpenAI was co-founded in 2015 by a group of tech luminaries, including Sam Altman, Peter Thiel, and Elon Musk. Its mission is to "ensure that artificial general intelligence benefits all of humanity," and the company's continued partnership with Microsoft will hopefully advance those efforts. 

"The past three years of our partnership have been great," said Altman, who serves as OpenAI's CEO. "Microsoft shares our values and we are excited to continue our independent research and work toward creating advanced AI that benefits everyone."

Microsoft's DirectStorage 1.1 application programming interface is available for Windows-based computers, the latest graphics cards, and advanced NVMe solid-state drives. So, it is time to find out what hardware best handles GPU decompression, which is one of the most exciting features of DirectStorage 1.1. Fortunately, Compusemble has developed an appropriate benchmark, whereas PC Games Hardware used it to uncover some interesting findings.

Microsoft's DirectStorage 1.1 has several critical performance-boosting features, but the main objectives of this API are to reduce CPU load when dealing with NVMe requests. It also saves valuable CPU cycles for other workloads and handles game asset decompression via highly-parallel GPUs with little OS intervention and low CPU utilization. In addition, the usage of DirectStorage asset compression and decompression algorithms allows for transferring more data than the storage medium (i.e., SSD) is capable of, which greatly reduces loading times.  

Meanwhile, GPU hardware handles DirectStorage decompression algorithms differently, so PCGH decided to find out which of the latest GPUs — AMD's Radeon RX 7900 XT, Intel's Arc A770, or Nvidia's GeForce RTX 4080 — is better for asset decompression. They took Compusemble's benchmark and ran it on the graphics cards and on Intel's Core i9-12900K CPU.

The first thing that strikes the eye is that all GPUs handle decompression at least 2.4 times better than the Core i9-12900K processor. Meanwhile, Intel's Arc A770 is noticeably better than AMD's Radeon RX 7900 XT and Nvidia's GeForce RTX 4080 regarding GPU asset decompression. In the best-case scenario, the A770 can transfer/decompress assets at a rate of 16.8 GB/s, whereas the RX 7900 XT comes third with a 14.6 GB/s rate (13% behind the leader). 

Whether an AMD, Intel, or Nvidia GPU is used, actual loading times are reduced by an order of magnitude — from 5 seconds to 0.5 seconds, according to PCGH. Therefore, given how close the decompression rate results of graphics processors are, it does not really matter which GPU is used — they are all up to the task and are generally good enough to significantly improve the gaming experience.

Just yesterday, Intel released a massive driver update to its Arc Alchemist GPUs, resulting in a near 2x FPS (frames per second) increase in DX9-based titles. Now, according to a report by GamingOnLinux, we know how Intel was able to accomplish this task in some games. Intel has added another translation layer to its latest graphics driver, featuring Steam’s DXVK translation layer. This is the same translation layer Steam uses in its Proton API to translate Windows games to Linux (like we saw on the Steam Deck), allowing Intel to translate DX9 code to the open-source Vulkan API.

According to Intel’s blog post from yesterday, Intel is apparently only using the DXVK translation layer in some cases; its driver will take a hybrid approach of opportunistically utilizing a combination of API techniques that take advantage of translation layers using one or more modern API implementations. As a result, Intel won’t be using DXVK for the entirety of its DX9 processing, and will only use DXVK when it can provide better performance over Intel’s DX12 emulation technique.

Intel never actually stated it was using DXVK in its official blog post, but thanks to Gaming On Linux, we now know DXVK translation is what Intel is referring to, based on a readme document Intel published on the same topic. Unfortunately, we do not know how effective DXVK actually is with Intel’s implementation, but it must be a very effective solution for Intel to implement the translation layer into its latest driver at all.

Intel’s Arc GPUs - and its associated Xe integrated graphics, no longer feature native DX9 support. Instead Intel has opted to rely solely on translation layers to replicate native rendering. One such example is Intel’s utilization of the Microsoft D3D9On12 mapping layer, which translates DX9 commands to DX12.

Intel’s reliance on translation layers may not be ideal, but it actually gives the company a shortcut in garnering good DX9 GPU performance quickly. Translation layers allow Intel to use DX12 optimizations for both modern DX12 titles and for older DX9 games, which severely cuts down the development time needed to optimize both new and old APIs. This was a necessary move for Intel, because it needed a way to compete with Nvidia and AMD, which have nearly twenty years of experience developing DX9 drivers for discrete GPU hardware.

The awesome part about DXVK is that Intel no longer needs to rely on Microsoft’s DX12 emulation layer to play DX9 games on Arc. With DXVK, Intel can now run DX9 games on other operating systems such as Linux, and gain additional performance benefits that might not be available in Microsoft’s emulator. 

China-based Moore Treads on Friday began sales of its latest MTT S80 graphics card based on the Chunxiao architecture for client PCs. The add-in-board promises compute performance comparable to Nvidia's GeForce RTX 3060 Ti, but its performance in real games remains unknown. Meanwhile, it is available at JD.com, a store that delivers worldwide. However, there is a catch.

A GeForce RTX 3060 Ti-Like GPU from China

Moore Threads' MTT S80 graphics board is based on the company's Chunxiao graphics processor featuring 4,096 stream processors, 128 tensor cores, 256 texture units and 256 render outputs clocked at 1.80 GHz. In addition, the card carries 16GB of GDDR6 memory with a 14 GT/s data transfer rate connected to the GPU using a 256-bit interface (up to 448 GB/s peak bandwidth). 

From a compute performance point of view, the MTT S80 delivers up to 14.4 FP32 TFLOPS, slightly below the peak compute performance of Nvidia's GeForce RTX 3060 Ti (16.2 FP32 TFLOPS), which is one of the best graphics cards. Meanwhile, the actual performance of the MTT S80 AIB in real games needs to be tested. 

The GPU comes with drivers that support Microsoft's DirectX application programming interface, Khronos Group's OpenGL/OpenGL ES, proprietary MUSA, and multiple specialized APIs. However, Moore Threads openly says that its DirectX support is in its infancy, and only 20 popular titles are initially supported (e.g., Call of Duty, Crossfire, Counter-Strike, Diablo 3, League of Legends, etc.), so do not expect much from the card for now. Meanwhile, the company says that it is working closely with developers of Unity and Unreal Engine as well as designers of actual games to ensure compatibility and performance with the two popular engines. 

The Chunxiao graphics chip also has a capable video engine that can handle AV1, H.264, and H.265 codecs for up to 8K videos. Unfortunately, Moore Threads does not disclose which players support its hardware-assisted video decoding. Meanwhile, the MTT S80 AIB has three DisplayPort 1.4 and one HDMI 2.1 interface. 

Interestingly, the MTT S80 is the world's first client graphics card with a PCIe 5.0 x16 interface, as Nvidia's Ada Lovelace GPUs support a PCIe Gen4 bus. AMD has yet to disclose the host interface of its latest RDNA 3 GPUs in general and Radeon RX 7900 XT and Radeon 7900 XTX in particular.

Only Available in Bundles

The Moore Threads MTT S80 graphics card is now available at JD.com (via VideoCardz) for ￥2999 ($373 without VAT). However, the AIB does not come alone, as it is bundled with the Asus TUF Gaming B660M-PLUS D4 motherboard priced at ￥1029. If you subtract the value of the motherboard, then the graphics board will cost $245 without VAT, which is relatively cheap given its compute capabilities. Still, since the performance of the product is unclear, we can only wonder whether it is actually worth $245. 

Another thing to point out is that according to VideoCardz, the initial release of the MTT S80 will be very limited, and it is unclear how many units were actually made. It is also unclear when the second batch is set to come and how big it is.

A New Kid on the Block?

There are about a dozen known developers of graphics processors in China. Some target only datacenters (including AI and HPC), while others design client GPUs yet only aim local market. Founded in October 2020, Moore Threads designs GPUs for many applications (except HPC) and seems intent on selling its products outside of China. This is why the company makes its MTT S80 available at JD.com, which ships worldwide and works with developers of popular engines and games to ensure compatibility with western titles. 

Will it succeed? That depends on multiple factors, including engineering talent availability, willingness to invest, and ability to execute. Moore Threads is a very young company, and while so far it has released four AIBs (MTT S10, MTT S50, MTT S60, and MTT S2000) with two incoming (MTT S80 and MTT S3000), we can only wonder whether it has enough people to address all of its declared market opportunities. After all, AMD, Intel, and Nvidia employ thousands of people to work on gaming and datacenter GPUs. 

Furthermore, it remains to be seen whether western companies will work closely with a Chinese entity even on such things as video games. Given the strict curbs the U.S. government imposes against Chinese semiconductor and supercomputing sectors, some companies may consider it risky to work with China-based high-tech companies. In fact, there are things that they might deem potentially toxic.

The Chunxiao GPU in its MTT S80 form is aimed at consumer applications and therefore is not designed for any artificial intelligence or high-performance computing applications. Also, Moore Threads has the MTT S3000 32GB server grade board that offers a 15.2 FP32 TFLOPS throughput and supports datacenter-oriented features, such as up to 32-way GPU partitioning as well as SR-IOV PCIe virtualization. Meanwhile, the Chunxiao graphics processor supports FP32, FP16, and INT8 precision. Therefore, assuming that it also supports an appropriate instruction set, it can theoretically be used for AI or even some light HPC workloads that do not need FP64.  

Based on what we know about the Chunxiao graphics processor, we believe it is aimed primarily at gaming and entertainment applications. The datacenter MTT S3000 will likely mainly be used for remote Android games rendering, virtual desktop infrastructure (VDI), and video streaming services.  

Whether the MTT S3000 can actually be used for non-consumer AI and technical computing applications in datacenters efficiently is something we do not know. We have reasonable doubts given the form factor, power consumption, and performance. Yet, if the U.S. further tightens its sanctions against the Chinese high-tech industry, there might be ramifications even for a consumer-oriented company like Moore Threads. 

Perhaps one day, anime will be real life thanks largely in part to projects like this one from maker and developer Jess Peter. Peter is using a Raspberry Pi to power a custom holographic anime virtual assistant named Maria that’s completely interactive and 100% adorable.

This holographic virtual assistant features an original 3D design with animations that help bring her to life. Peter implements AI for voice recognition and programmed text-to-speech so Maria can talk back and forth with the user to help complete verbal requests and initiate tasks. Maria is still a work in development so functions are limited but plans are in the works to add more in the future.

Peter has provided plenty of juicy details about she works and how to set her up on your own at home. According to the project website, Maria can provide weather predictions based on WeatherAPI, set custom timers (yelling “Beep! Beep! Beep! when they go off) and even play music using the Spotify API.

This project is running on a Raspberry Pi 4B connected to a USB microphone for audio input and a USB speaker for audio output. The Pi is housed inside of a 3D-printed case fitted with a conical acetate sheet to give the holographic effect. A small, 3.2-inch screen is used to project the image with a resolution of 800 x 400px.

Diving into the software side, Maria makes use a Python server that constantly listens for audio input. Keywords are detected using Webrtvt and Deepspeech and used to determine incoming commands. The text-to-speech functions are handled using C along with Google’s text-to-speech library. A shader is necessary to warp the character on the screen so she appears correctly on the acetate cone. You can read more about the project details on the official GitHub page.

We find this Raspberry Pi project to be thoroughly impressive and implore anyone looking to recreate it to check out the official website where Peter was kind enough to share all the details you need to bring Maria to your home.

Moore Threads Intelligent Technology, a major graphics processors developer from China, on Thursday announced its next generation GPU that can be used for gaming, artificial intelligence, and datacenter workloads. The MTT S80 gaming graphics cards as well as MTT S3000 server board promise to deliver compute performance akin to that of Nvidia's GeForce RTX 3060 Ti, though their actual performance in games and professional applications is something that remains to be tested. 

The Chunxiao GPU

Moore Threads's new graphics processor is based around the company's Chunxiao architecture that supports FP32, FP16, and INT8 precision and is compatible with the company's MUSA computing platform and application programming interface (it can work with standard APIs too though). The MTT Chunxiao GPU is clocked at 1.80 GHz – 1.90 GHz and packs 4,096 stream processors, 128 tensor cores, 256 texture units, and 256 render output. The GPU features a 256-bit memory interface and can work with GDDR6 memory with a 14 GT/s data transfer rate. As for host bus, it features 16 PCIe Gen5 lanes and fully supports the SR-IOV specification for PCIe virtualization in server environments. The GPU up to 32-way partitioning, which will be handy for Android games rendering.  

The chip also comes with a rather powerful video engine that supports AV1, H.264, and H.265 codecs for up to 8K videos as well as can decode up to 32 streams at a 1080p30 resolution. As for output, the GPU has four display engines supporting an up to 8Kp30 resolution and has three DisplayPort 1.4 as well as one HDMI 2.1 interface. 

Moore Threads says that depending on clocks, its Chunxiao GPU can deliver 14.4 FP32 TFLOPS or 15.2 FP32 TFLOPS, which is comparable to single precision compute performance of Nvidia's GeForce RTX 3060 Ti GPU. On paper, this is enough to make it to our list of the best gaming graphics cards available today, but how the ChunxiaoGPU works in real life is something that we will have to test. 

Meanwhile, since the Moore Threads Chunxiao graphics processor is aimed at AI, gaming and datacenter workloads, it comprises of 22 billion of transistors, which is fairly complex. To put the number into context, Nvidia's GA104 features 17.4 billion transistors, whereas AMD's Navi 21 packs 26.8 billion of transistors. Moore Threads does not disclose which process technology it uses to make its Chunxiao graphics processor.

Two Products Coming 

For now, Moore Threads plans to offer two products based on the Chunxiao GPU — the MTT S80 graphics card with a 14.4 FP32 TFLOPS throughput and 16GB of memory as well as the MTT S3000 server card with a 15.2 FP32 TFLOPS compute performance and 32GB of memory. 

Moore Threads has not disclosed power consumption of its MTT S80 and MTT S3000 products, though the former comes with a rather sophisticated cooling system with three fans. 

One of the main advantages that the Moore Threads Chunxiao offers is its broad compatibility; It can work with a variety of client and datacenter hardware platforms (Arm, Ampere, Intel, etc.) and operating systems. It is compatible with Microsoft's DirectX (and therefore will ship with appropriate drivers for Windows), Khronos Group's OpenGL/OpenGL ES, proprietary MUSA as well as multiple specialized APIs. Furthermore, the Chunxiao can work with PyTorch, TensorFlow, PaddlePaddle, Jittor and other mainstream deep learning frameworks and popular AI models. 

To ensure compatibility with modern games, Moore Threads says it had worked closely with developers of Unreal Engine and Unity as well as creators of popular titles (e.g., Call of Duty, Crossfire, Counter Strike, Diablo 3, League of Legends, etc.). Meanwhile, Moore Threads admits that for now its Chunxiao only properly supports about 20 DirectX titles and does not make any promises about performance. 

The GPU developer plans to start selling its MTT S80 graphics cards at JD.com on November 11, 2022.  No pricing has been announced.

AMD's next generation graphics cards based on the RDNA 3 architecture have passed conformity tests with Khronos Group's Vulkan 1.3 application programming interface. The compliancy indicates that the new graphics processors from AMD are functional and their drivers can pass conformity tests. 

AMD plans to formally unveil its forthcoming graphics cards based on the RDNA 3 architecture on November 3, 2022, next week. Since the new GPUs are a little more than a week away, it's not particularly surprising that their drivers for Windows 10 and Ubuntu 5.15 Linux kernel are good enough to pass Vulkan 1.3.3.1 conformity tests, based on the list of conformant products published at Khronos.org (via VideoCardz). 

The list currently includes not only an Undisclosed Product that belongs to the AMD RDNA 3 family of GPUs, but also an Undisclosed Product that belongs to AMD's Undisclosed Family of GPUs. While we do not know for sure how many of AMD's new products are compliant with the Vulkan 1.3 API, it's safe to say that at least two of them can pass the Vulkan 1.3.3.1 conformity tests. 

AMD's codenamed Navi 3x graphics processors based on the company's RDNA 3 architecture are projected to substantially increase performance compared to existing Radeon RX 6000-series offerings. Also, the top-of-the-range Navi 31 is expected to use a multi-chiplet design. 

Unofficial sources indicate that AMD plans to reveal two high-end RDNA 3-based graphics cards — a flagship offering and the one that is positioned slightly below — this year and start their sales in the second half of December. While prices of the new boards are unknown, there are rumors that AMD might position them higher than it positioned its Radeon RX 6900 XT at launch.

These days it doesn’t take expensive hardware to create potentially life-saving technology. Using a Raspberry Pi Pico W, Dmytro Panin has developed a web enabled Geiger counter to help track ionizing radiation levels every few hours.

The Raspberry Pi Pico W is connected to an M4011 Geiger tube which serves as the sensor responsible for detecting radiation. The tube relays data to the Pico W which interprets the findings for the interface once every few hours. Panin also took the time to create a basic JSON API that can be accessed by anyone. This API provides the current values that can be relayed to an LCD screen or just checked periodically in the browser window.

Panin lives in Kyiv which isn’t very far from the Chernobyl Nuclear Power Plant outside of Pripyat, Ukraine. He decided to place the system next to his apartment window to detect any radiation level variances. This data is pushed to a server every couple of hours which outputs to the webpage so Panin can easily check the current readings while away from the setup.

The hardware for this custom Geiger counter is fairly basic. As we mentioned before, it’s using a Raspberry Pi Pico W module which is necessary for its wireless support. The radiation is detected using an M4011 tube which is the most expensive part of the operation. In addition, Panin included a breakout board with a 128 x 64 pixel OLED screen connected via I2C. This OLED module displays the current readings taken from the M4011 tube.

The Pico can be programmed using a few languages with the most popular choices being MicroPython and CircuitPython but in this case, Panin opted to use C++. According to Panin, the ionizing radiation data is measured in Nanosieverts per hour and relayed to the API.

To see this Raspberry Pi project in action or recreate one for yourself, check out the original thread shared to Twitter and be sure to follow Dmytro Panin for future Pi-powered developments.

Microsoft says the DirectStorage 1.1 API is coming soon to Windows PCs. With this release, Microsoft will enable GPU Decompression on PCs per its previously shared roadmap. The primary benefit of GPU Decompression is that PC gamers could see load times reduced by as much as 40% depending on the game and the PC hardware configuration.

DirectStorage 1.0 was introduced for Windows (10 and 11) in March 2022. It was designed to bring speed, bandwidth and latency optimizations to the Windows storage subsystem, which would scale with storage performance. Thus faster storage, like the latest NVMe SSDs, deliver greater overall benefits. Version 1.1 of the API builds on this promise with GPU Decompression, reducing the processing of graphical assets using the CPU and moving this workload to the GPU, which is adept at massively parallel processing and decompression tasks.

Microsoft explains in its DirectX Developer Blog that modern games typically require massive amounts of data to build and render the immersive worlds we navigate. This could mean hundreds of gigabytes of compressed data loaded to run the latest AAA titles. “When a game is run, the assets are transferred to system memory, where the CPU decompresses the data before it is finally copied into GPU memory to be used as needed,” says Senior Microsoft Program Manager, Cassie Hoef. “The transfer and decompression of these assets on gaming devices contributes heavily to load times and limits how much detail can be included in open world scenes.”

DirectStorage 1.1 has an optimized GPU-powered decompression algorithm to deliver loading performance benefits of up to 40% to the PC gaming experience. To back up its claims, Microsoft built an optimized demo where scene loading was up to 3x faster, and CPU loads were drastically reduced. Above, you can see a GPU with GDeflate (left) loading a scene in 0.8 seconds versus the CPU with Zlib (right) taking 2.36 seconds.

DirectStorage was initially described as a Windows 11-exclusive technology before Microsoft caved and facilitated its use in Windows 10 gaming experiences. Like the previous 1.0 version of the API, there are still said to be “additional optimizations in the IO stack available to Windows 11 users.” A DirectX 12-capable GPU supporting Shader Model 6.0 is necessary, and users should have game data on a high-speed NVMe SSD for optimal gains.

It will be interesting to see this technology applied in modern games, as in many titles on my mainstream 2022-built PC, it is the GPU that is usually maxed out, not the CPU.

Developers will be able to play with DirectStorage 1.1 later this year, and when it goes mainstream, we expect GPU driver updates from all major players. Please don’t hold your breath, though, as we are yet to see even one AAA game with DirectStorage 1.0 support released on Windows. Forspoken, by Square Enix, was going to spearhead DirectStorage on Windows this month but has been rescheduled for late January 2023.

Getting your Raspberry Pi project online is now cheaper and easier thanks to the $6 Raspberry Pi Pico W. It only takes five lines of code to connect your Raspberry Pi Pico W to the world, but sharing your code can leave you open to a few security concerns.

Your MicroPython code now contains your Wi-Fi password, API keys and bespoke URLs. So how do we mitigate the risk while keeping our data portable?

Creating a MicroPython module is the best way to keep your secrets out of your project code. We can import the module just like any other module, and reference its contents in the same manner. 

In this how-to, we will create a secrets module and use it, along with Open Weather to get the current weather details for our home location. The project code can be easily shared with others, without fear of including any personal information.

For this project you will need

• Raspberry Pi Pico W
• A computer

Creating a Secrets File for Credentials

The secrets module is really a standard MicroPython file that contains objects that reference our Wi-Fi access point, Wi-Fi password and our Open Weather API key.

1. Follow this guide to setup your Raspberry Pi Pico W. Follow the steps until “How to blink an LED”.

2. Create a new blank file.

3. Create an object SSID and assign it the name of your Wi-Fi access point. The equals sign will assign the value to the right, into the object.

SSID = “YOUR WI-FI AP NAME”

4. Create an object PASSWORD and assign it the password for your Wi-Fi access point.

PASSWORD = “YOUR WI-FI PASSWORD”

5. Create an object, owm_api and assign it your Open Weather API key. You can get a free API key by signing up to Open Weather.

6. Save the file to your Raspberry Pi Pico W as secrets.py.

7. In the Python shell (bottom of Thonny’s window) import the secrets file and then print the SSID of your Wi-Fi access point. Essentially we have just made a Python module that contains all of the details that we wish to keep safe.

import secretsprint(secrets.SSID)

Using Secrets in a Project

The purpose of the secrets file is to keep our main project code free of any files that may contain personal / secure information. By keeping the project code free of sensitive information, we can easily share it with others.In this part of the how to we shall import the secrets module and use it with the Open Weather API to get the weather for our location.

1. In Thonny create a new blank file.

2. Import three modules of code. Network enables our Pico W to connect to Wi-Fi, Secrets is our file full of secret information, urequests is a module that enables us to make requests to remote devices, in this case Open Weather’s API. We used the same module to get data on the astronauts onboard the International Space Station.

import networkimport secretsimport urequests

3. Create an object, wlan, and use it to create a connection from our code to the Wi-Fi chip on the Pico W, then turn the Wi-Fi chip on.

wlan = network.WLAN(network.STA_IF)wlan.active(True)

4. Using the secrets module, use the SSID and PASSWORD objects to connect to your Wi-Fi access point.

wlan.connect(secrets.SSID,secrets.PASSWORD)

5. Create an object, weather, to store the returned data from the Open Weather API. Use secrets.owm_api to insert your API key into the URL. This specially created URL sends a request to Open Weather for our location q=Blackpool,UK, which can be changed to your own location. We can also specify the units used &units=metric (which can be changed to imperial).

weather = urequests.get("http://api.openweathermap.org/data/2.5/weather?q=Blackpool,UK&units=metric&appid="+(secrets.owm_api)).json()

6. Store the current temperature in an object, temperature. The returned data is in a JSON format, which is almost identical to Python’s dictionary datatype. Dictionaries use a key, value format to store data. The keys ["main"]['temp'] will take us to the main section of data, and then the temperature value is saved to our newly created temperature object.

temperature = weather["main"]['temp']

7. Store the current humidity in a corresponding object.

humidity = weather["main"]['humidity']

8. Store the current overall weather condition in the weather object. This data is buried a little deeper in the JSON object. It is a dictionary, then list, then dictionary object. The list [0], identifies that we are using the first item in the list, as Python starts counting from zero.

weather = weather["weather"][0]["main"]

9. Print the returned data using string formatting that will drop the corresponding data into the sentence.

print("The weather today is {} with a temperature of {} degrees Celsius and a humidity of {}%".format(weather, temperature, humidity))

10. Save the code to the Raspberry Pi Pico W as weather.py. Click run to start the code. The code will use the Open Weather API, download the latest weather for your location, and then print a sentence containing the information to the Python Shell.

Complete Code Listing

import networkimport secretsimport urequestswlan = network.WLAN(network.STA_IF)wlan.active(True)wlan.connect(secrets.SSID,secrets.PASSWORD)weather = urequests.get("http://api.openweathermap.org/data/2.5/weather?q=Blackpool,UK&units=metric&appid="+(secrets.owm_api)).json()temperature = weather["main"]['temp']humidity = weather["main"]['humidity']weather = weather["weather"][0]["main"]print("The weather today is {} with a temperature of {} degrees Celsius and a humidity of {}%".format(weather, temperature, humidity))

Graphics processing, and possibly machine learning applications, just took a step forward on the Raspberry Pi 4. In a blog post by Raspberry Pi CEO Eben Upton - that the popular single-board computer is now conformant with version 1.2 of the Vulkan graphics API.

Having hit version 1.0 in November 2020, and 1.1 in October 2021, version 1.2 integrates 23 frequently used Vulkan extensions into the standard, and is tantalizingly close to the latest version, 1.3, which was released in January.

The project to make the newest Pi boards (the Pi 4, 400, and Compute Module 4, as older models’ GPUs are not up to the job) conformant with Vulkan is actually carried out by open-source consultancy Igalia. The driver is written, and presented to Vulkan maintainer Khronos for approval. This time, Khronos said yes, a stamp of approval that should see a driver update in an upcoming OS release.

“All the changes required for this have already been merged in the upstream v3dv Mesa driver and will eventually be available in future Raspberry Pi OS updates,” says Iago Toral from Igalia. “Aside from Vulkan 1.2 core functionality, we have also been adding support for various other extensions, some of which are core in Vulkan 1.3, as well as many bugfixes and performance improvements.”

While this development doesn’t necessarily mean we’ll see games such as Hades or Path of Exile on the Pi 4, but it could lead to improvements in performance for applications such as Kodi, VLC or hardware accelerated web applications. Vulkan libraries also exist for machine learning, opening up new paths to training neural networks on Pi clusters.

Upton’s post also flags up a contribution from Roman Stratiienko adding support for Android to the driver. This opens the door for Android games to run on the Pi 4 via a port of Google’s operating system such as Lineage OS. 

If there’s one thing a Raspberry Pi is good for, it’s working with data from the web. This project, created by maker and developer Rui Alves, is taking this idea to new heights, via the world of aviation. This homemade arrivals and departures board keep tracks up incoming and outbound flights in real-time for any airport of your choosing.

It works by pulling relevant flight data from an open source API, processing the flight details, and displaying that information on a custom display. It features an animation effect that closely resembles airport flip boards. These animations trigger each time the flight data is updated. Overall, the end result is a tiny desktop arrivals and departures board that looks just like the ones you’ll find in actual airports.

Alves is no stranger to microelectronics—especially the Raspberry Pi. His personal blog, Super Techman documents his past creations, highlighting plenty of works that demonstrate his technical prowess. One example is this Raspberry Pi sound box that works as a basic music player.

This project was built around a Raspberry Pi 3 B+ but there’s no reason you couldn’t use a newer Pi like the Raspberry Pi 4 or the Raspberry Pi Zero 2 W to pull it off. Alves designed an enclosure from scratch and 3D printed it to house all of the components which also includes an LCD display harvested from an old project. Any display should work as long as you can connect it to the Raspberry Pi's HDMI port or DSI connector.

Alves shared plenty of details about the inner workings of the software side including his design process along the way. He ultimately landed on running an Apache webserver to display the flight data, using PHP to pull information from an open source API known as AirLabs. The text animations are built using an open source tool called HTML & SCSS Departure Board, created by Tom Giddings. The Pi's web browser is configured to run in Kiosk mode so the web server launches in full screen when booted. You can find the full source code for the board over at GitHub.

If you want to recreate this Raspberry Pi project or just get a closer look at how it works, check out the original project thread shared to the Super Techman blog and be sure to follow Alves for more projects as well as any future updates on this one.

We’ve seen makers integrate hundreds of applications with various Raspberry Pi projects but not too many use the instant messaging platform Discord. So today, we’re sharing a project from Reddit user Android2771, who has created an easy way to look at the latest post of a given Discord server using a simple Pi-powered e-ink display setup.

E-ink displays are limited as far as refresh rates go but excel at providing low-power display options for projects using text and images. In addition, some of them provide multiple color options, but in this case, Android 2771 uses a small, 2.7-inch e-ink display with just black and white support. These screens are standard in e-readers but work well for homemade Pi projects like this digital calendar and can quickly adapt to a wider variety of applications using tools like PaperPi.

This project relies on a Raspberry Pi as the central controller. First, it’s responsible for checking Discord for the most recent text posts and images. Then, it processes the data into a format that fits the tiny e-ink display parameters. The result is an e-ink display that regularly updates with posts from any Discord server you like.

It doesn’t take too much hardware to recreate this project as it’s mainly just a Raspberry Pi with an e-ink screen using a network connection to retrieve the chat log data. In this project, Android2771 is using a Raspberry Pi 4, but there’s no reason an older model like a Raspberry Pi 3B+ wouldn’t work in its place. The e-ink screen used in this project is a 2.7-inch model from Waveshare, but you could use any e-ink screen, including larger ones with more color options.

In the original post, Android2771 explains that he used a custom Discord bot to interface with a local API in charge of the e-ink display output. Python Pillow was responsible for handling the image processing, turning them into black and white images with a small enough resolution to appear fully on the small e-ink screen.

Unfortunately, the code used in this project is not open source, but Android2771 left a trail for makers to follow who are interested in creating a similar system of their own. If you want to make this Raspberry Pi project yourself, check out the original thread shared to Reddit for sources, links, and plenty of details to get you started in the right direction.

AMD's Radeon Technology Group (RTG) is hiring a RISC-V CPU/GPU designer for its existing team of architects developing embedded RISC-V CPUs. A new job posting indicates that the development of RISC-V-based solutions is well underway at AMD, whereas the fact that Radeon Technologies Group is hiring specialists could give a hint about the applications RTG is working on. 

The job description provides some general details about AMD's expectations from its RISC-V micro-architect/RTL designer. The company is looking for a specialist with experience in high-performance GPUs; RISC-V RV64 CPUs; and CPUs with out-of-order execution, speculative execution, and branch predictors.  

According to the job posting, AMD has a team working on embedded RISC-V CPUs at AMD's Radeon Technologies Group in Orlando, Florida. The new candidate is expected to know and improve "existing and emerging graphics/compute paradigms and new APIs employing RISC-V processors." Also, they will have to analyze CPU workloads and make recommendations for improvements as well as understand bottlenecks and other challenges where an embedded CPU will improve performance. 

Evidently, AMD's Radeon Technologies Group does not develop its own CPUs, so we are probably not going to see AMD-branded RISC-V CPUs (or licensable RISC-V embedded CPU cores/designs) from RTG. Modern GPUs could use embedded CPUs for a variety of tasks, including managing certain onboard functions for a GPU, or could even be expanded for more exotic purposes, like running an operating system or processing general-purpose tasks such as fetching data from storage devices. RISC-V designs could also be used for other purposes, like security by providing a hardware-based root of trust. 

At this point, we don't know exactly what kind of RISC-V CPU cores AMD's Radeon Technologies Group is developing, but we do know that Nvidia uses RISC-V microcontrollers on its own GPUs to manage certain on-board functions.

The RISC-V open-source architecture is exceptionally well suited for emerging applications, so it's possible that AMD is working on something new. Meanwhile, since we are dealing with a 64-bit RISC-V architecture, we can be fairly sure that this is not a simplistic microcontroller.

Microsoft's DirectStorage application programming interface (API) promises to improve the efficiency of GPU-to-SSD data transfers for games in a Windows environment, but Nvidia and its partners have found a way to make GPUs seamlessly work with SSDs without a proprietary API. The method, called Big Accelerator Memory (BaM), promises to be useful for various compute tasks, but it will be particularly useful for emerging workloads that use large datasets. Essentially, as GPUs get closer to CPUs in terms of programmability, they also need direct access to large storage devices.

Modern graphics processing units aren't just for graphics; they're also used for various heavy-duty workloads like analytics, artificial intelligence, machine learning, and high-performance computing (HPC). To process large datasets efficiently, GPUs either need vast amounts of expensive special-purpose memory (e.g., HBM2, GDDR6, etc.) locally, or efficient access to solid-state storage. Modern compute GPUs already carry 80GB–128GB of HBM2E memory, and next-generation compute GPUs will expand local memory capacity. But dataset sizes are also increasing rapidly, so optimizing interoperability between GPUs and storage is important.

There are several key reasons why interoperability between GPUs and SSDs has to be improved. First, NVMe calls and data transfers put a lot of load on the CPU, which is inefficient from an overall performance and efficiency point of view. Second, CPU-GPU synchronization overhead and/or I/O traffic amplification significantly limits the effective storage bandwidth required by applications with huge datasets.

"The goal of Big Accelerator Memory is to extend GPU memory capacity and enhance the effective storage access bandwidth while providing high-level abstractions for the GPU threads to easily make on-demand, fine-grain access to massive data structures in the extended memory hierarchy," a description of the concept by Nvidia, IBM, and Cornell University cited by The Register reads.

BaM essentially enables Nvidia GPU to fetch data directly from system memory and storage without using the CPU, which makes GPUs more self-sufficient than they are today. Compute GPUs continue to use local memory as software-managed cache, but will move data using a PCIe interface, RDMA, and a custom Linux kernel driver that enables SSDs to read and write GPU memory directly when needed. Commands for the SSDs are queued up by the GPU threads if the required data is not available locally. Meanwhile, BaM does not use virtual memory address translation and therefore does not experience serialization events like TLB misses. Nvidia and its partners plan to open-source the driver to allow others to use their BaM concept.

"BaM mitigates the I/O traffic amplification by enabling the GPU threads to read or write small amounts of data on-demand, as determined by the compute," Nvidia's document reads. "We show that the BaM infrastructure software running on GPUs can identify and communicate the fine-grain accesses at a sufficiently high rate to fully utilize the underlying storage devices, even with consumer-grade SSDs, a BaM system can support application performance that is competitive against a much more expensive DRAM-only solution, and the reduction in I/O amplification can yield significant performance benefit."

To a large degree, Nvidia's BaM is a way for GPUs to obtain a large pool of storage and use it independently from the CPU, which makes compute accelerators much more independent than they are today.

Astute readers will remember that AMD attempted to wed GPUs with solid-state storage with its Radeon Pro SSG graphics card several years ago. While bringing additional storage to a graphics card allows the hardware to optimize access to large datasets, the Radeon Pro SSG board was designed purely as a graphics solution and was not designed for complex compute workloads. Nvidia, IBM, and others are taking things a step further with BaM.

Microsoft, via its Developer Blog has announced the availability of the DirectStorage API (Application programming Interface) for Windows PCs. Available for both Window 10 and Windows 11, the new API brings speed, bandwidth and latency optimizations for the Windows storage subsystem that should scale with storage performance - especially for some of the best, high-speed NVMe options. The announcement comes days after we've got confirmation of the first game with baked-in DirectStorage support, Luminous Productions' Forspoken.

The new API provides game and application developers with a new model for IO management, which should lift bandwidth bottlenecks currently affecting the latest storage technologies such as NVMe and even older SATA III SSD drives - which were introduced more than a decade ago, in 2009. In theory, this should unlock available performance that's currently not being tapped. According to Microsoft, DirectStorage means users "can look forward to vastly reduced load times and virtual worlds that are more expansive and detailed than ever."

Microsoft initially announced DirectStorage as a Windows 11-exclusive technology, bridging the gap between the Xbox's Velocity architecture (and its closer-to-the-metal approach) and Windows' relatively dated IO management. However, the company has since reversed its stance, and is making DirectStorage available for the older version of Windows as well - despite Microsoft saying that Windows 11 features "further storage optimizations" that should result in stronger overall IO performance compared to the previous version of the OS.

Unfortunately, a crucial element of the tech - at least when it comes to gaming - isn't being included in this API release version as yet. In the announcement blog, Microsoft explained that GPU decompression still is't baked in, despite being next on the company's roadmap. That is likely the single most important element for gaming scenarios, which will allow game developers to take advantage of GPU's shading performance and advanced parallelism to directly decompress game assets. This provides the added benefits of freeing up CPU cycles that would otherwise be responsible for the decompression routines (freeing it up for other performance-sensitive duties), whilst also reducing data shuffling between storage, operating memory, the CPU and the GPU. That feature not being available as yet means that IO performance can still be improved due to the revised storage subsystem, but leaves a lot of performance on the table - and still requires the CPU to do the heavy-lifting in decompressing game world data.

The Covid-19 pandemic affected people in all sorts of different ways, and for British novice coder Andy Adkin it spawned a project that’s taken him all over the country, filming short vignettes with a Raspberry Pi camera and posting them on Twitter.

What’s especially clever about Adkin’s '5into15' project is that it compresses five minutes of images into a 15-second video clip, automatically, using a Python script that takes 300 JPEG stills at a rate of one per second and turns them into a 20 FPS movie file at 720p resolution. Twython then takes over, interfacing with the Twitter API to post the finished vignette to the site. Adkin's targets have included the Manchester Cycling Centre, the Lamplighter festival in the Yorkshire town of Todmorden, and sunrise over the sea from Pant Yr Hwch, Wales.

Adkin, who admits his projects are "tiny but interesting, if perhaps pointless", has used a couple of different Raspberry Pi boards, along with two Zerocam Fisheye cameras, having damaged one. He began with a Pi Zero, but the processing time for the video was too long, so he moved up to a full-size Pi 3B+, followed by a Zero 2 W to make the system more portable. The electronic bundle is powered by a rechargeable power pack, and controlled from Adkin’s phone over SSH, which also provides internet access via its personal hotspot. He hopes to upgrade to a Pi 4 and HQ Camera module (the Zerocam being tricky to focus) in future, and to keep the electronics in a waterproof case.

“I know very little about computers and programming,” writes Adkin. “This was mostly researched via Google with some additional input from users on a Pi discussion thread on London's friendliest cycling forum. My motivation was to take time to stop and enjoy my surroundings, as well as to capture moments of movement that may otherwise go unnoticed.” 

If you feel like having a go yourself, Adkin has put more information, and a dummy script, on his GitHub page. 

A developer has implemented 3dfx's Glide application programming interface into Mesa's Gallium3D driver stack for modern GPUs. The implementation allows users to play games that rely on Glide under Linux to run on modern hardware. 

Link Mauve, an independent hobbyist developer, created Grover, a Glide API implementation front-end for Mesa'sGallium3D using the Rust programming language, reports Phoronix. Mesa's Gallium 3D driver stack includes open-source drivers for modern AMD's Radeon and Intel's Gen or Xe hardware, which essentially means it will be possible to play old Glide-based games on up-to-date GPUs. However, there are some caveats.

Since Glide was generally used for Windows games and the developer did not have access to any Glide-based game for Linux, he used code samples and the 1997 game Pandemonium to test his implementation. For this very same reason, he could not implement the windowing system, which is an important feature as hardly anyone wants to run a late 1990s game on a large modern display in full-screen mode. Given limited testing, Mauve considers Grover a work in progress.

Because most Glide games were developed for Windows, playing them under Linux requires the use of Grover within the Wine/Proton compatibility layer, which has its perks. 

When it comes to playing old Windows video games that do not run on contemporary PCs, it is possible to build a system using outdated components that have drivers for Windows 2000 or Windows XP. Sourcing properly working GeForce or Radeon graphics cards from the early 2000s is tricky, but obtaining a 3dfx Voodoo board to play games that exclusively use the proprietary Glide API (e.g., Unreal, Unreal Tournament) from the late 1990s is much harder. 

Given all the complexities and costs associated with procuring old hardware, as well as getting it up and running, various Linux emulations look like a viable option. However, if you want to get the same experience from late 1990s games (and therefore ultimate reminiscence), nothing beats buying an outdated graphics card and supporting hardware to go along with a 4:3 aspect ratio monitor.

A Java vulnerability (Log4Shell) was recently discovered that is so severe it allows for and attacker to remotely execute commands on the exploited machine. Tracked under CVE-2021-44228 by the National Institute of Standards and Technology (NIST), the vulnerability affects the logging library in Apache, a widely used, open-source server package. The vulnerability compromises any system that is accessible directly from a browser, mobile device, or application programming interface (or API) call.

While AMD has announced that its software products are safe from the exploit, Intel listed as many as nine applications that make use of Java that are currently vulnerable.

• Intel Audio Development Kit
• Intel Datacenter Manager
• Intel oneAPI sample browser plugin for Eclipse
• Intel System Debugger
• Intel Secure Device Onboard (mitigation available on GitHub)
• Intel Genomics Kernel Library
• Intel System Studio
• Computer Vision Annotation Tool maintained by Intel
• Intel Sensor Solution Firmware Development Kit

The exploit in Apache's Log4J service allows for a hacker to trick the target server to download and run arbitrary (malicious) code that can be hosted on a server the attacker controls, circumventing multiple layers of software security solutions. Crucially, the exploit doesn't require physical access to the system. It can be triggered through any server that has some sort of browser access. This expls why the vulnerability has been classified under the highest possible value of the "CVSS 3.0" guidelines: 10. Intel is currently at work providing updated versions of these applications that mitigate the vulnerability.

AMD has announced that after preliminary investigation, none of their products appear to be affected by the vulnerability. Considering the potential impact of it, however, AMD said it is "continuing its analysis." 

Nvidia's situation is slightly more complex: If using the latest releases for the services and subservices of each application, then there is currently no known exploitable vulnerability. However, server managers don't always feature the latest updates on their machines, and for those, the company lists four distinct products vulnerable to "Log4Shell" if outdated:

• CUDA Toolkit Visual Profiler and Nsight Eclipse Edition
• DGX Systems
• NetQ
• vGPU Software License Server

Further, Nvidia distributes its DGX enterprise computing systems with Ubuntu-Linux packages, and users can install Apache's Log4J functionality block by themselves. The systems are thus immune in their out-of-box configuration. But in cases where the Log4J service was installed, however, Nvidia is prompting users to update the service to the latest version, which locks down the vulnerability.

As for Microsoft, the company has issued updates to two of its products targeting this vulnerability: Its Azure Spring Cloud employs certain Log4J elements in the boot process, rendering it vulnerable to the exploits unless updated. Microsoft's Azure DevOps application too has received mitigations aiming to nullify the exploit. 

Microsoft this week announced its new Video Encode application programming interface (API) for DirectX 12. The API is designed to enable third-party applications to accelerate video encoding using GPUs and will provide them abilities to tweak various aspects of the encoding process. The technology offers a consistent approach for video apps by providing a standard standard process for GPU-accelerated video encoding.

Microsoft's DirectX 12 already features APIs to support GPU acceleration for video decoding, video processing, and motion estimation, which covers the requirements of the vast majority of end-users outside of the professional video industries. Those who need video encoding use professional applications that support GPU-accelerated encoding, but that encoding is implemented using proprietary means and requires developers to work closely with GPU vendors as there is no standard approach for video encoding. 

With the release of the Video Encode API for DirectX 12, Microsoft is changing that and provides a standard for video decoding on Windows 11. All proprietary technologies will continue to be supported, but from now on companies will be able to take advantage of the standard API.

At this point Microsoft's Video Encode API for DirectX 12 supports H.264 and H.265 (HEVC) codecs, which are popular among both professional and non-professional audiences. Meanwhile, those professionals who need other codecs, including AV-1, H.266 (VVC) will continue to rely on other encoding technologies (most of which are CPU-accelerated).

As far as technological implementation is concerned, the API takes each video frame represented by ID3D12Resource textures and compresses them into an ID3D12Resource buffer that contains the slice headers and payload of each encoded frame. Right now, only DXGI_FORMAT_NV12 and DXGI_FORMAT_P010 are available depending on driver support, so input content may need to be color converted and down sampled previously by the application. The rest of the bitstream codec headers (i.e. SEI/VUI/VPS/SPS/PPS) is assigned to the application, which will create and pack them into the final bitstream along with the compressed bitstream taken from the GPU operation for each frame.

Microsoft's Video Encode API for DirectX 12 offers exposes multiple configurable parameters for applications (and the end user) to allow tweaking many aspects of the encoding process, which will be particularly useful for professionals.

The Video Encode API is included as part of Windows 11 and is also available in the DirectX 12 Agility SDK (version 1.700.10-preview or newer). Drivers from Intel and Nvidia already support the new API, driver support from AMD is coming in Q2 2022.

Due to a potential security vulnerability, Intel has disabled support of the DirectX 12 application programming interface in its recent graphics drivers for its 4thGeneration Core 'Haswell' processors.

Starting from Intel's graphics driver version 15.40.44.5107, applications that run exclusively on DirectX 12 API no longer work with GPUs integrated into Intel's 4th Generation Core processors as well as Celeron and Pentium chips powered by the Haswell architecture. The GPUs in question are based on Intel's Gen7 architecture. 

Intel says that some of its integrated GPUs contain a security vulnerability that may allow escalation of privilege. In a bid to mitigate the weakness, Intel decided to disable DirectX 12 API support on Haswell platforms, which naturally means that DirectX 12 games will no longer work on Haswell-based systems that use integrated GPUs. Those who need to run DirectX 12 applications based on the said GPU are advised to downgrade the driver to version 15.40.42.5063 or older.

It is noteworthy that Gen7 architecture is also used in Intel's 3rd Generation Core 'Ivy Bridge' CPUs. However, Intel has not deprecated DirectX 12 support for systems running these chips or at least has not issued a document on the matter.

Black Lotus Labs revealed on Thursday that it's discovered new malware that uses the Windows Subsystem for Linux (WSL) to avoid being detected by security tools.

WSL debuted in 2016 alongside the Windows 10 Anniversary Update as a way to access GNU and Linux tools without having to boot into a different operating system. It didn't originally provide true access to the Linux kernel—it used a compatible kernel developed by Microsoft—but that changed when WSL 2 arrived in June 2019.

That release officially brought the Linux kernel to Windows, and while that's usually a good thing for people who don't want to fuss with dual booting or using a different virtual machine environment, it turns out that it poses a security risk as well. Black Lotus Labs said the malware it found was used to covertly attack target PCs.

The researchers said the malware was distributed via Executable and Linkable Format (ELF) files intended to run on Debian, a popular Linux distribution, and its derivatives. In some cases those files contained a payload intended for a target PC; in others they received a payload from remote command and control infrastructure.

Black Lotus Labs found several versions of the malicious ELF files. One was said to have been written exclusively in Python using standard libraries that would allow it to target both Linux and Windows systems. Another used PowerShell, Microsoft's command shell and scripting language, to interact with specific Windows APIs.

The researchers said "this tradecraft could allow an actor to gain an undetected foothold on an infected machine." VirusTotal, a utility that checks submitted files for malware against 70-odd antivirus scanners, confirmed this by giving "the technique a detection rate of one or zero" when the Black Lotus Labs report was written.

"To our knowledge, this small set of samples denotes the first instance of an actor abusing WSL to install subsequent payloads," the Black Lotus Labs security researchers said. "We hope that by illuminating this distinct tradecraft, we can help drive better detection and alerting before its use becomes more rampant."

In the meantime, Black Lotus Labs is asking WSL users to ensure that they use proper logging to help prevent this type of malware from seeing widespread use.

AMD has traditionally separated its Linux drivers into open-source and closed-source solutions, and the latter has outperformed the former for quite some time now. However, a new report from Phoronix reveals that the latest round of improvements to the RadeonSI workstation open-source graphics driver has resulted in a 10% performance uplift.

The Linux Application Programming Interface (API) world is widely dominated by the newest members, Vulkan and OpenCL. However, when it comes to some serious workstation-grade software, the good 'ol OpenGL API comes into play. AMD has a closed-source Radeon driver for OpenGL applications, and it provides the best possible performance for Radeon cards. However, developers have been working on improving its open-source equivalent.

Called the RadeonSI driver, it's part of the Mesa driver collection of open-source GPU drivers. Its performance has lagged the AMD's Radeon Pro driver for workstation-grade software and hardware, but that has now been fixed with the latest updates.

The latest round of driver patches is due for Mesa version 21.3, scheduled for release next quarter. The new code has already been tested with a popular benchmark, SPECViewPerf Siemens NX, and the new driver delivers as much as 10% more performance than the older revision. This is a great sign of progression, achieved by adding 379 lines of new code and removing 461 lines of the older codebase.

This shows us that the open-source driver work is now on pace to catch up with the closed-source AMDGPU-PRO OpenGL workstation driver. However, it doesn't mean that AMD will abandon the development of the proprietary solution. It just means that the open driver is now more up to par with what AMD offers in closed form, and it could reach a point of overtaking the proprietary solution. AMD, of course, works with a multitude of clients, so support for the closed solution will likely last for a very long time.

RISC-V has been one of the hottest topics in the world of computing, as the Instruction Set Architecture (ISA) allows for extensive customization and is easy to understand, besides the whole open-source, license-free benefit. There's even a project that designed a general-purpose GPU based on RISC-V ISA, and now we are witnessing a port of Nvidia's CUDA software library to the Vortex RISC-V GPGPU platform.

Nvidia's CUDA (Compute Unified Device Architecture) represents a unique computing platform and application programming interface (API) that runs on Nvidia's lineup of graphics cards. When applications are coded for CUDA support, whenever a system spots a CUDA-based GPU, it gets massive GPU acceleration of the code.

Today, researchers have examined a way to enable CUDA software toolkit support on a RISC-V GPGPU project called Vortex. The Vortex RISC-V GPGPU aims to provide a full-system RISC-V GPU based on RV32IMF ISA. That means 32-bit cores that can be scaled from 1-core to 32-core GPU designs. It supports OpenCL 1.2 graphics API, and today it got support for some CUDA action as well.

The researchers explain: "...in this project we propose and build a pipeline to support an end-to-end CUDA migration: the pipeline accepts CUDA source codes as input and executes them on an extended RISC-V GPU architecture. Our pipeline consists of several steps: translates CUDA source code into NVVM IR, convert NVVM IR into SPIR-V IR, forwards SPIR-V IR into POCL to get RISC-V binary file, and finally executes the binary file on an extended RISC-V GPU architecture."

This process is visualized in the graph above, showing all the steps to get it working. In simple terms, CUDA source code is represented in the intermediate representation (IR) format called NVVM IR, based on the open-source LLVM IR. It is later converted to Standard Portable Intermediate Representation (SPIR-V) IR, then forwards that into the portable open-source implementation of the OpenCL standard called POCL. As Vortex supports OpenCL, it is fed with supported code and executes it without a problem.

For more details on this complicated process, check out this paper. And as an important note, you have to appreciate the effort of these researchers to enable CUDA to run on a RISC-V GPGPU. While this is only a small step for now, it is a possible beginning of an era where RISC-V is used for accelerated computing applications, very similar to what Nvidia is doing today with its GPU lineup.

Keeping an eye on stocks is no big task thanks to our favorite single-board computer the Raspberry Pi. Developer Redmera has created a custom Pi-powered stock ticker that updates periodically with crucial stock data making it possible to track certain financial assets at a glance.

According to Redmera, the stock data is pulled from an API and refreshes on an e-ink display at predetermined intervals. The screen’s refresh rate takes between 2 to 3 seconds on average and can be programmed to pull stock data as frequently as you need.

The best Raspberry Pi projects are easy to recreate—thankfully, the hardware for this project is easy to acquire and ready to assemble out of the box. Redmera is using a Raspberry Pi Zero with an Adafruit 2.13-Inch Monochrome E-Ink Bonnet for a display. There are buttons on the bonnet that Redmera programmed to switch between stocks.

The data is pulled from the Yahoo Finance RapidAPI, which has a monthly request limit of 500. To chart the stock information, Redmera opted to design their own interface using Pillow, an open-source library for drawing graphics in Python.

To get a close-up look at this stock ticker, check out the original thread shared to Reddit by Redmera and follow them for future updates. 

Porkchop and Hamhock are a couple of guinea pigs with one of the best Raspberry Pi-based monitoring systems an owner can make. Developed by Christian Hollinger, this project is designed to provide remote observation features without the need for an inaccessible third-party server that may or may not be storing private data.

While platforms exist that enable users to access camera feeds via various apps, Hollinger wanted to create something with a little more security and control. The idea here was to create a monitoring system that isn’t constantly running a live feed but also automates to an extent with periodic snapshots or on-demand requests.

The solution? A custom Telegram bot of course! Telegram is an instant messaging platform with a robust API that can interface easily with the Raspberry Pi. With Hollingers custom bot, users can access the camera feed and request pictures in real-time with a simple phrase like “take a picture”.

Another key component used in the project is MotionEyeOS. This software runs on the Raspberry Pi and offers a useful array of tools—including motion detection triggers. It’s worth noting that Telegram bots are not totally secure and can be accessed by the public. To add an extra layer of security, Hollinger added some code designed to ignore messages from unauthorized chatIDs.

The best Raspberry Pi projects are ones you can make at home. If you want to recreate this project, check out the full post on Hollinger’s website for a complete breakdown of how it works and what you’ll need to get started.

The Splunk Threat Research Team revealed yesterday a cryptocurrency-mining malware campaign targeting Windows servers on Amazon Web Services (AWS). Once those instances are compromised they're enlisted into a crypto botnet that, according to the report, has ties to a similar campaign that was active in 2018.

Splunk explained that the attack relies on the Telegram API that "malicious actors can [use to] turn desktop clients of compromised hosts into bots as they can issue commands remotely, download additional tools and payloads." The campaign effectively uses the messaging service as its command and control infrastructure.

"In a typical attack with Crypto Botnet on Telegram, threat actors first break into Windows servers and proceed to install several tools found in hacking forums such as NL Brute, KPort Scan and NLA Checker," Splunk said. "All these tools target Windows servers with weak passwords using RDP protocol brute force tools."

Once those tools are installed, the malware's operators install Telegram's desktop client so they can use its API to distribute mining tools related to Monero, a cryptocurrency that claims to be "private and untraceable." That makes it an excellent option for crypto botnet operators hoping to cover their tracks. Monero also happens to be one of the few cryptocurrencies where CPU mining can still turn a modest profit (especially if you're stealing CPU time).

Splunk said that it found a Monero wallet that "has been observed in previous campaigns dating back to 2018." The company also said the campaign itself "involved the use of cryptomining payloads and very similar exploitation techniques," which could indicate that it's being conducted by the same people.

AWS customers running Windows servers were advised to make sure they regularly patch their operating system, install the latest security updates, stop using weak passwords, and consider enabling Network Level Authentication to mitigate the potential impact of these brute force attacks.

Valve has today published its monthly update for Steam Hardware Survey, with an update for July. Besides the regular fluctuations in the market share of CPU and GPU vendors, there is another interesting change slowly happening. According to the newest data from the survey, gaming on Linux has climbed to 1.0% for the first time in years.

Back in 2018, Valve introduced Proton, a technology that translates Windows-specific API calls to Linux equivalents, enabling thousands of Linux gamers to play the games that they wanted to, but were unable because they weren't using Windows OS.

At the same time, many Linux gamers were trying out the Proton software and the market share of Linux gamers managed to climb to around 2% of a much smaller Steam customer base. However, after this testing period ended, only 0.8-0.9% of gamers were still using Linux distros, and the percentages stayed within that range for some time.

In the latest Steam Hardware Survey published for July, Valve has noted that Linux gaming market share managed to climb to 1.0% of all gaming systems questioned in the survey. And this is quite a bit of achievement, given that Valve has access to millions of PCs and gamers across the world.

What are the possible reasons for such growth you might wonder? For starters, Valve has recently announced its Steam Deck portable gaming console, which runs a  Linux-based Arch OS. As many people heard that the new console runs Linux OS, it is possible that many decided to try the experience and prepare for what is to come, once the new console launches.

It is important to note that once Valve begins shipping Steam Deck consoles to the many eager early adopters, the Linux gaming market share will continue to grow. All of the people using the console will contribute to the growth of Linux gaming, helping it to a much higher level adoption. The growth of the Linux gaming ecosystem and community is still going to take baby steps to increase, however, given that a major software and hardware developer like Valve is supporting it, there are chances that it could reach a double-digit percentage sometime in the future.

Microsoft has begun to hire software engineers to develop machine learning-based upscaling algorithms implemented using its DirectX/DirectML application programming interface (API), which is designed for Xbox and Windows systems. The technology will compete both against AMD's FidelityFX Super Resolution and Nvidia's DLSS. 

The software giant recently posted two job openings one for a Senior Software Engineer and another for a Principal Software Engineer for Graphics seeking graphics specialists who will work on the new technology in Redmond, Washington (via TechPowerUp). The openings were posted on June 18 and June 30, just days after AMD officially started to support its FidelityFX Super Resolution upscaling technology on Microsoft's Windows platform. Since the openings were published last month, it looks like the technology is in its early stages of development. 

There are two competing upscaling technologies for games these days: AMD's FidelityFX Super Resolution (FSR) and Nvidia's deep learning super sampling (DLSS). Both technologies have to be implemented by game developers, but AMD's FSR works on virtually any GPU (including those from Intel and Nvidia) and does not use any proprietary machine learning techniques, whereas Nvidia's DLSS requires the company's GPUs to work. For the sake of truth, it should be noted that Nvidia is not the only company offering a proprietary AI-based upscaling technology. Samsung has been offering one with its high-end televisions for a while. 

As it turns out, Microsoft wants to have the best of both worlds. It wants to use machine learning-based upscaling, implemented using its industry-standard DirectX API that is widely supported by hardware from different vendors.  

Creating universal ML-based upscaling method makes great sense for Microsoft, which has for years focused on providing a consistent gaming experience on Windows no matter which hardware a user has. For hardware developers, a Microsoft-developed technology means that they will know which features to support and how to support them in a bid to provide competitive performance on all of the best graphics cards and even those that don't quite make the cut.  

One of Microsoft's job descriptions reads: 

"Xbox is leveraging machine learning to make traditional rendering algorithms more efficient and to provide better alternatives. The Xbox graphics team is seeking an engineer who will implement machine learning algorithms in graphics software to delight millions of gamers. Work closely with partners to develop software for future machine learning hardware. Make a big impact in computer graphics and gaming."

Microsoft is finally kicking the curb to its once-famous and popular Internet Explorer web browser. In a recent blog post, Microsoft said that it plans to fully retire Internet Explorer 11 (the latest version of the browser) by June of 2022.  For companies still using apps tailor-made for Internet Explorer, Microsoft has added an Internet Explorer compatibility mode to Edge, to ensure critical enterprise apps remain operational.

Since the introduction of the Edge web browser in 2015, we knew Microsoft had fully planned to retire its now seriously-outdated Internet Explorer browser. Since its glory days in 2003, Internet Explorer saw a rapid loss in traction, even before Microsoft released its Edge browser.

Back in the early 2000s, Internet Explorer was actually one of the best browsers on the web and supported cutting-edge technologies that no other browser supported. But, due to Microsoft's persistent use of proprietary APIs and lack of consistent updates, Internet Explorer quickly lost ground to other web browsers like Chrome and Firefox in the early 2010s.

Now, all Internet Explorer is used for is to run proprietary applications which only work with Internet Explorer's code. This is where Microsoft's Internet Explorer compatibility mode will fully replace Internet Explorer, allowing Internet Explorer-specific applications to remain functional.

For more details, check out Microsoft's FAQ. As of this moment, Microsoft is asking all companies that still operate with Internet Explorer 11 to migrate to Edge's Internet Explorer compatibility mode as soon as possible.

I have some old telephones lying around - few of them fully functional anymore. I was going to throw out one of them when I realized I could replace the inner wiring with a Raspberry Pi, and have the Google Assistant running on it. 

While it’s certainly easier to call “hey google” across the room, there’s something fun about picking up the phone, asking it a question, and having it immediately respond. This is how to install the Google Assistant on an old rotary telephone with a Raspberry Pi Zero. 

What You’ll Need to make an old phone into a Google Assistant 

• A Raspberry Pi Zero with soldered GPIO pins, a memory card (with Raspberry Pi OS on it), and power adapter
• An old telephone with a functional receiver (speaker and microphone), and a functioning hook switch that you don’t mind destroying
• A few female jumper cables, wire strippers, and electrical tape or solder
• A few types of screwdrivers depending on your phone
• 1 USB audio adapter compatible with linux
• 1 male-male 3.5mm audio cable
• 1 Raspberry Pi Zero micro USB to USB A female adapter

How to Install the Google Assistant on an Old Phone 

This Raspberry Pi project is quite extensive and can take a bit of time, so I’ve split it up into four distinct parts: 

• Registering with Google
• Authenticating with Google
• Wiring your telephone
• Setting up the assistant

Registering With Google 

Before we use a Raspberry Pi as a Google Assistant, we must register the device with Google. This process can be a bit confusing if you’ve never used Google Cloud Platform before, but the steps should be easy enough to follow. 

1. Clone this repository to your raspberry pi. 

cd ~/git clone https://github.com/rydercalmdown/google_assistant_telephone

2. Navigate to https://console.actions.google.com in your browser. This site allows us to manage Google Assistant Actions, as well as register custom Google Assistant devices.

3. Click “New Project” and fill in the required information. The name doesn’t matter - just pick something you can remember. 

4. In a new tab, visit this link to Google Cloud Platform, and confirm that the name of the project you just created appears in the top bar - if not, select it. Then, click the “Enable” button to turn on the API. 

5. In your original tab, scroll to the bottom of the page and click “Are you looking for device registration? Click here” 

6. On the next page, click “Register Model”.

7. Fill in the required information and copy down the Model ID to file - you will need it later.

8. Click Download OAuth 2.0 credentials to download the credentials file your Raspberry Pi will use to make requests.  

9. Rename the downloaded file to oauth_config_credentials.json and transfer it to your pi. Place it into the repository folder you cloned in step 1. 

# Rename your downloaded filecd ~/Downloadsmv your_unique_secret_file_name.json oauth_config_credentials.json# Move the file into your repositoryscp oauth_config_credentials.json pi@your_pis_ip_address:/home/pi/google_assistant_telephone

10. Back in the browser, after downloading and renaming the credentials, click the “Next” button.

11. On the “Specify traits” tab, click “Save Traits” without adjusting any settings to complete the setup.  

Authenticating With Google 

We’ve now registered a device with Google. Next, it’s time to authenticate this device so it has access to our Google account and personalized assistant.

1. Navigate to https://console.cloud.google.com/apis/credentials/consent ensuring that the project matches the name you decided in Step 3 of “Registering With Google”. 

2. Select “External” and click the “Create” button. 

3. Fill in an App name. Once again, this doesn’t really matter - but to keep it simple I went with the same name as before.

4. Select your email from the dropdown in User support email. This is in case any users of your app need to contact you, but since we won’t be making the app public, there’s no need to worry.

5. Add that same email under “Developer contact information” and click “Save and Continue”. 

6. On the next page, click Add or Remove Scopes to bring up the scopes sidebar.

7. Search for “Google Assistant API” in the search bar, and check the /auth/assistant-sdk-prototype scope. Then click update, followed by “Save and Continue” at the bottom of the page. 

8. On the next page, click “Save and Continue” to skip Optional Info.

9. With the setup complete, click “OAuth Consent Screen” in the sidebar to refresh the page - then “Add User” under Test Users.

10. Add your Google account’s email, and click save. 

11. Next, on your pi navigate to the downloaded repository and run the following command: 

cd ~/google_assistant_telephonemake authenticate

12. Follow the link it gives you and complete the Authentication process in your browser. Once the process is complete, copy the code and paste it back in your terminal.

13. If successful, you’ll see a message indicating “credentials saved:” followed by a path to the credentials. Use this path to move the credentials into the current directory. Transfer these credentials to your repository’s root directory 

# credentials saved: /Users/test/Library/Application Support/google-oauthlib-tool/credentials.jsonmv /Users/test/Library/Application\ Support/google-oauthlib-tool/credentials.json /home/pi/google/assistant/telephone/credentials.json

Wiring Your Rotary Telephone With Raspberry Pi 

Depending on your rotary phone, this process will vary widely. These are the steps that I used, but likely this will require a fair bit of trial and error on your part. Make sure you use a phone you don’t care about, as it won’t be able to work normally after this.

1. Take the cover off the telephone. You may need to loosen a screw on the bottom. 

2. Find and strip the wires connected to the hook switch. We’ll connect these wires to the pi’s GPIO pins to determine if the receiver has been picked up or set down.

3. Connect the hook switch wires to GPIO Board pin 18 and ground. You may need to solder the wires from the hook switch to jumper wires to connect them easier, or just attach them together with a bit of electrical tape. 

4. Connect your USB audio adapter to the raspberry pi zero. You will need a USB-micro to female USB-A adapter to do this.

5. Solder the microphone and speaker in the handset to two separate 3.5mm cables. These will carry the signal from the pi to the speaker, and from the microphone to the pi. You should be able to connect these within the phone case and use the original handset cord. This will take a bit of trial and error to determine which wires belong to the speaker, and which to the microphone. 

6. Connect the 3.5mm cables to the USB audio adapter being mindful to connect them in the proper order. 

7. Tuck the pi into the phone, and close up the cover - or keep it open while you debug setting up the assistant. Run the power adapter connected to the pi out the back of the case where the original telephone wire would go. 

Setting Up The Assistant 

1.  Run the installation script. It’ll take care of base and python requirements. If you have a Raspberry Pi Zero, the compilation process can take hours and will appear stuck on a step installing grpc (it just moves very slowly). I’d recommend leaving it running over night. 

cd google_assistant_telephonemake install

2. Configure your USB audio by running the following command. It will take care of editing your alsamixer config, setting your USB card as your default audio output, and setting volumes for the speaker and microphone. 

make configure-audio

3. Test and adjust your volumes by running the following command, speaking, and listening through your phone’s handset. If your volume is not high enough on your microphone or speaker, set it with the alsamixer command. 

# Run, speak something into the microphone, and listenmake test# Set volumesalsamixer

4. Export your project ID to an environment variable. You can retrieve your project ID by visiting this URL, selecting your project, clicking the three dots next to your profile photo in the top right, and clicking “Project Settings” 

export PROJECT_ID=your-project-id

5. Export your model ID from the Registering With Google steps to an environment variable. 

export DEVICE_MODEL_ID=your-model-id-from-the-earlier-steps

6. Run the make run command. It will take care of registering this device, and saving the configuration to disk so you won’t need the environment variables in the future. 

make run

7. Test your assistant by picking up the phone, and asking it a simple question, like “What is the capital of Canada?” If all goes well, you’ll see some logs in the terminal, and the assistant will respond. To ask another question, hang up the receiver and pick it up again.

8. Finally, run the following command to configure the assistant to run on boot. 

make configure-on-boot

Building your own smart home is easier than ever with a Raspberry Pi. Even companies like MicroNova have recognized the potential of our favorite single-board computer (SBC) by using one inside its home sound system, called AmpliPi.

The crowdfunded AmpliPi box is capable of streaming from four separate sources. Users can interact with it using a web-based interface and output audio to a maximum of 36 stereo output zones.

The system is built on top of the Raspberry Pi Compute Module 3 and can interface with the likes of Spotify, AirPlay and Pandora. Users can configure speaker zones and playlists using the AmpliPi REST API created by MicroNova.

MicroNova's web app lets users manage audio sources using a series of tabs. It includes settings to adjust groups and zones to make sure music plays in the intended room. 

Explore the AmpliPi GitHub for more in-depth information about how the system works.

If Raspberry Pi projects get you excited, check out our list of Best Raspberry Pi Projects for more fun creations from the maker community.

Want to reboot your Raspberry Pi? Don't even worry about opening a terminal window—the HomeBerry Android app, developed by Andrej Martinák, has everything you need to control your Pi remotely with a few basic functions.

HomeBerry works with a custom REST API. This API must be installed on your Raspberry Pi in order for a companion Android app to communicate the Raspberry Pi. You can read more about and download the HomeBerry API repository on Github. Once it's installed, you'll need to load the HomeBerry app onto an Android device (an Android tablet should work just as well as a smartphone).

The Android app features a user interface with plenty of options and settings. You can restart your Pi, enable and disable Bluetooth or even launch specific apps like Kodi.

If you want to take HomeBerry for a spin, you can check it out on Github. Martinák provides all of the source code and plenty of info to get you started. This isn't his first project, either. Be sure to follow him on Reddit for more projects and future updates to HomeBerry.

Any Raspberry Pi project that makes life a little easier is a success in our book. Dexcom systems already do that by helping users monitor blood sugar levels. This Raspberry Pi project shared by Paulcole710 on Reddit can help streamline readings by interacting with a Dexcom system to provide a visual depiction of the glucose data.

This DIY Dexcom tracker uses an E-Ink display to show a trend arrow informing whether or not the current glucose level is within an appropriate range. According to Paulcole710, this saved him from stressing too much over specific numbers. It also removed the burden of needing to use a phone every time he wanted to check for changes.

The project is built on top of a Raspberry Pi and relies on a Python script to manage the E-ink display. Paulcole710 used a Python API called PyDexcom, which allowed him to pull data from the Dexcom system as needed in his script. The maker used this Python library to control the E-ink display.

Paulcole710's project is very useful as-is, but the creator already has ideas for improvement. For example, the display currently updates every 9 minutes, and he is considering making one of the buttons on the E-ink display update the display on demand.

If you're interested in this project and want to keep an eye out for updates, you can follow Paulcole710 on Reddit..