📰 English IT Daily · 2026-06-24

A project on GitLab shows a new use for the Raspberry Pi Pico W. Instead of working only as a small development board, it can be used as a USB Wi-Fi adapter for another computer or device. In simple terms, a USB Wi-Fi adapter is hardware that gives network access through a USB connection. This idea is interesting because the Pico W is low-cost, compact, and widely available to hobbyists and engineers.

The project appears to focus on firmware, the basic software that runs directly on hardware. With the right firmware, the board can present itself over USB and help a host system connect to a wireless network. This kind of setup can be useful in embedded systems, testing, or education, where teams often need flexible tools. It also shows how programmable hardware can take on roles that are usually handled by dedicated products.

For developers, the main value is experimentation. A small board used as a network device can help people learn more about drivers, interfaces, and device compatibility. A driver is software that lets an operating system communicate with hardware. Compatibility means whether different systems can work together correctly. In real projects, these issues matter because a clever prototype is only helpful if it is stable enough for practical use.

The broader lesson is about reuse and customization in hardware design. Engineers often look for ways to adapt existing parts instead of buying a new component for every task. Projects like this can support faster prototyping and deeper learning, even if they are not the best choice for every production environment. As open development communities share ideas, simple boards such as the Pico W may continue to inspire creative solutions in networking and device engineering.

Cloudflare engineers said they found a difficult bug in hyper, an open-source HTTP library for Rust. The problem appeared after the company changed how its Images binding connected the Workers runtime to the Images service. Soon after the rollout, some image transformation requests began to fail, but only from time to time and mostly with larger images. Even more confusing, the server returned a 200 status code and logged no clear errors.

The main symptom was that image data was cut short. For example, a response that should have contained a full processed image could arrive with only part of the bytes. This made the bug hard to notice at first, because the request looked successful from the outside. According to the engineers, they spent about six weeks investigating the issue before identifying it as a race condition, a timing-related software bug that happens only under very specific conditions.

To understand the problem, it helps to know how the system works. The Images binding lets a Worker send image data to an image-processing service and get the result back as a stream. The service uses a socket connection, which is a communication channel between two processes. Hyper reads requests from the socket and writes responses back. After the Images service encodes the final image, it passes the response to hyper, which stores the bytes in an internal buffer before sending them onward.

The bug affected the handoff from hyper’s internal buffer to the socket’s outbound buffer. Because of the timing of reads and writes, some large responses could be sent only partially even though hyper considered the work complete. In the end, the fix was surprisingly small: just four lines of code. The case is a reminder that modern systems depend on many layers, and a tiny bug in a widely used library can cause serious and very confusing production problems.

Security researchers have described a new exploit called Usbliter8 that affects some Apple devices using A12 and A13 chips. An exploit is a method that uses a weakness in a system to do something the designer did not intend. In this case, the reported weakness is in SecureROM, a very early part of the device startup process. Because SecureROM is built into the chip itself, problems there are especially important for security experts.

According to reports, the exploit works through USB during a special recovery state. This means an attacker would need physical access to the device and would have to connect it to another machine. That requirement limits the risk for most everyday users. However, researchers still pay close attention because low-level attacks can help with security testing, device research, and understanding how hardware protections work.

SecureROM is sometimes called immutable code because it cannot be changed after the chip is manufactured. For that reason, a weakness in this area usually cannot be fully fixed on affected hardware through a normal software update. Software may still reduce some practical risks, but the original flaw in the startup code remains. This is why SecureROM issues often receive strong interest from both defenders and attackers.

The news is another reminder that hardware security matters as much as software security. For companies, the main lesson is not panic but preparation. Teams should think about physical security, device handling, and incident response when sensitive phones or test devices are involved. For engineers, the case offers a useful example of how trust starts at the lowest level of a system and how a small weakness there can have wider effects.

Mozilla says many internet users are now seeing more CAPTCHAs, login requests, and block pages than before. According to the company, websites are facing more abusive traffic from bots, which are automated programs that can send large numbers of requests. In response, many sites are using stronger anti-abuse tools. However, Mozilla argues that these tools often make the web harder to use for normal people and can also reduce privacy.

The company explains that privacy-focused browsers have made progress by limiting third-party cookies, reducing fingerprinting, and hiding IP addresses. These steps help stop tracking, which is the collection of data about users across websites. But the same signals are also used by anti-abuse systems to decide whether a visitor looks suspicious. As a result, improving privacy can sometimes make it harder for sites to tell the difference between a real person and a harmful bot.

Mozilla warns against proposals that ask users to prove their devices or software are 'trusted' before they can access websites. It says this kind of model could give too much power to a small number of operating system and hardware companies. In Mozilla’s view, that would weaken user choice and move the web away from its open design. Instead of checking who a person is or what device they use, Mozilla suggests focusing on whether activity stays within a reasonable rate limit, meaning a limit on how often actions can happen.

Mozilla says it is starting a new initiative with Cloudflare, other browser makers, and web stakeholders to explore this problem. The idea is to reduce abuse at scale while keeping the web anonymous by default. In simple terms, a site may only need proof that a visitor is behaving like a normal user within set limits, not a permanent identity that can be tracked. Mozilla also suggests that an existing relationship, such as with another trusted service, might one day quietly vouch for a user without revealing who they are.

A recent blog post by developer Akseli Lahtinen argues that code descriptions should be short, clear, and focused on the reason for a change. He says many commit messages, merge request descriptions, and code comments have become too long and full of extra detail. In code review, this can make it harder for people to understand the main point quickly.

The writer says the most important question is not what changed, but why it changed. In many cases, the code itself already shows what was done. If more detail is needed, reviewers can ask questions during the review process. He also connects this issue to accessibility, explaining that very long explanations can be difficult for people who already struggle to concentrate.

The post also discusses atomic commits. An atomic commit is a small change that can stand on its own and has one clear purpose. According to the writer, this is especially helpful during merge review, because large commits with huge diffs are harder to check. He suggests using tools like amend, rebase, and squash before merging so that the history is cleaner and easier to read.

Finally, Lahtinen says developers should write their own comments and commit messages even if they use LLM tools. He believes this helps them understand the work better and makes review more accessible for others. His message is simple: keep descriptions on a need-to-know basis, explain the reason for the change, and avoid turning technical communication into a long story.

A developer working on the hobby operating system Astral has described the difficult process of porting Wine to the platform. Wine is a compatibility layer that lets many Windows programs run on other systems. This work mattered because many games are closed source and only available as Windows software. The developer especially wanted to run Cogmind, a 32-bit Windows-only game, on Astral, which is otherwise a 64-bit-only operating system.

The first step was to improve basic Wine functionality. The developer downloaded MinGW and enabled it in the Wine build so that PE DLLs could be compiled correctly. After that, notepad.exe became more stable and no longer crashed when the user selected "Save as." However, graphics support was still missing. Although Astral already had OpenGL, Wine also needed EGL, a layer that connects graphics APIs to the windowing system so programs can start graphics properly.

Adding EGL was not simple. Astral's Mesa port did not provide it, and Mesa did not support EGL on the xlib backend. Because of this, the developer had to switch to the DRI backend, which allows software to communicate more directly with the GPU instead of going through the X server. This change led to more low-level work, including patching Mesa so that the X.org server could start even without /dev/dri. After these fixes, a real game, Deltarune, was able to start.

Running Cogmind required another major step: support for 32-bit Windows programs through Wine's WoW64 mode. This approach avoids the need for a full 32-bit userspace by running 32-bit Windows binaries inside a 64-bit process and translating data as needed. To make this work, Astral's kernel needed Local Descriptor Table support and some extra signal and syscall handling changes. In the end, Cogmind became playable, with only some online features not working. The story shows how one application can reveal missing parts across the kernel, graphics stack, and compatibility layer.

A new debate is growing around the business model of generative AI. Critics say some AI platforms attracted users by offering very cheap access at first, while the real cost of running the systems was much higher. This strategy created strong demand and helped justify huge investment in data centers, chips, and software. The concern is that users may later face much higher prices when companies try to earn a return.

Writers and analysts have warned about this problem since 2023. They argued that AI companies were giving large subsidies to users, especially through subscription plans with high usage limits. In simple terms, a subsidy means a company pays part of the real cost so the customer can pay less. Recent reporting said that some heavy users could consume far more in tokens than the price of their monthly plan, suggesting that the gap between price and cost may be very large.

This matters because tokens are the basic units of text that AI models process and generate. If users can burn many tokens for a low fee, demand will rise quickly, but the provider may lose money on each active customer. Some analysts also questioned gross margin, which is the money left after direct operating costs are removed. If gross margin is negative, a company is effectively paying more to serve customers than it earns from them.

The issue became more serious after reported financial data about OpenAI drew attention in June 2026. According to the source cited in the blog post, revenue was far below total costs and expenses, leading to very large losses. The numbers added force to a wider argument: AI is not only a technology story but also an affordability story. For businesses, the key question is whether today’s AI prices are sustainable, or whether token costs and subscription fees will rise sharply in the future.

Anthropic has updated its privacy terms and related policies for users of its website and AI services, including Claude.ai. The policy says the new version was published on June 8, 2026 and becomes effective on July 8, 2026. One notable change is that Anthropic may verify a user’s age or identity in some situations. The company presents this as part of how it manages access to its services and handles personal data.

In the policy, Anthropic explains that it collects several kinds of personal data. This includes identity and contact data such as a name, email address, and phone number when a person creates an account or asks for information. It also collects payment information if a user pays for access. In addition, the company says it collects inputs and outputs from interactions with its systems. Inputs are the text, files, or other content a user sends, and outputs are the responses or actions created by the AI.

The policy also notes that some AI features can take actions outside the service if the user gives permission. For example, an AI assistant may send communications, modify files, or interact with connected third-party services. Anthropic says feedback can also be stored. If a user rates an output, the related conversation may be kept as part of that feedback. The company also mentions research studies, surveys, and interviews, where it may collect responses and associated account data.

For users, the update highlights a wider trend in AI: companies are trying to balance easy access with stronger safety, privacy, and compliance measures. Age or identity verification can help reduce misuse and support legal requirements, but it also raises questions about data protection and user trust. For businesses and developers, the main issue is understanding what data is collected, when verification may happen, and how permissions can affect actions taken by AI systems.

OpenAI has announced its first custom chip, built with Broadcom. The new chip is designed for inference, which means running AI models after they have already been trained. This step shows that OpenAI wants more control over the hardware behind its services. Instead of depending only on general-purpose chips from other suppliers, the company is starting to develop technology that matches its own AI needs.

A custom chip is a processor made for a specific task rather than for many different uses. In AI, this can bring better efficiency, lower power use, and faster performance for some workloads. Inference is especially important because it happens every time a user asks a question, creates an image, or uses an AI tool in an app. If inference becomes cheaper and more efficient, companies may be able to serve more users at a lower cost.

Broadcom is known for designing networking and semiconductor products, so the partnership is important. It suggests that OpenAI is not only focused on software and models, but also on the infrastructure needed to run them at large scale. Building custom hardware is difficult, expensive, and time-consuming, but it can reduce supply risk and improve long-term planning. For a company with growing AI demand, hardware strategy is becoming almost as important as model strategy.

The announcement also reflects a wider trend in the AI industry. As demand for computing power grows, more companies are exploring custom chips to improve performance and manage costs. However, designing a successful chip is only one part of the challenge. Companies also need the right systems, manufacturing partners, and software support. OpenAI’s move may not change the market overnight, but it shows how closely AI progress is now linked to chip design and infrastructure decisions.

Meta has paused an employee-tracking program after an internal data leak raised new security concerns. According to reports, the company stopped the program while it reviews what happened and how the leaked information may have been exposed. The case shows how companies can face risks not only from outside attackers but also from problems inside their own systems and processes.

Employee-tracking programs are usually designed to monitor work devices, activity, or access to company resources. Businesses may use them to protect sensitive data, check compliance, or investigate suspicious behavior. However, these systems can also collect personal or private information about workers. If that information is not handled carefully, a leak can damage trust inside the company and create legal or ethical questions.

An internal data leak means information from inside an organization becomes available to people who should not have it. This can happen because of weak access controls, human error, poor system design, or a security breach. In cases involving monitoring tools, the risk may be higher because the tools often gather detailed records. Security teams must therefore limit who can view the data and how long it is stored.

The Meta case highlights a broader challenge in corporate security: finding the right balance between protection and privacy. Companies want visibility into threats, but workers also expect clear rules and responsible data use. For IT teams, the lesson is practical. Any system that collects sensitive information should be reviewed regularly, protected with strong controls, and explained clearly to employees before problems appear.