📰 English IT Daily · 2026-06-21

The Linux kernel has removed the strncpy API after a long cleanup effort that lasted about six years. Reports say the work involved around 360 patches. This change is important because the kernel is one of the world’s most widely used open-source software projects, and even small coding rules can affect many developers and systems.

The function strncpy is an old C library API used to copy text into a fixed-size buffer, which is a limited area of memory. However, developers have argued for years that it can be confusing and sometimes unsafe. Its behavior is not always easy to understand, especially when a copied string is too long or when the destination buffer is larger than the source text. These details can lead to bugs, wasted work, or security problems.

To solve this, Linux developers gradually replaced strncpy with clearer and safer alternatives. In general, modern APIs are preferred when they better show the programmer’s intent and reduce the chance of mistakes. Removing a long-used API from a huge codebase is not simple. It requires careful review, testing, and many small fixes across different parts of the kernel so that behavior stays correct.

This news is also a reminder that software engineering is often about maintenance, not only new features. Large projects improve over time by reducing technical debt and making code easier to read and audit. For engineers, the lesson is clear: even familiar tools should be questioned if they create risk or confusion. Cleaner interfaces and safer defaults can make systems more reliable in the long term.

A recent technical article compared epoll and io_uring, two Linux systems for handling asynchronous I/O. Asynchronous I/O means a program can continue working while it waits for network or disk operations to finish. The writer said this topic became important during work on a simple reverse proxy project. After an early version showed clear architectural limits, the team studied how high-performance tools reduce overhead and manage many connections at the same time.

For many years, epoll was the standard choice on Linux. It tells an application when I/O is possible, such as when a socket is ready to read or write. However, the program must still call functions like read() or write() after that notification. This means extra syscalls, which are requests from user space to the kernel. Each syscall can add overhead because the CPU must switch between user mode and kernel mode. With many connections, that cost can become significant.

io_uring, introduced much later, uses a different model. Instead of telling the program when I/O is possible, it reports when I/O is done. It uses shared memory between the application and the kernel, organized as ring buffers for submissions and completions. In simple terms, the program places work into one queue, and the kernel posts results into another. By processing many operations in a batch, io_uring can reduce the number of syscalls compared with epoll-based designs.

The article also noted an important trade-off. By default, a program still needs a system call to tell the kernel to check new submissions. But one call can handle a whole batch of work, which is more efficient than making separate calls for each operation. There is also an option called SQPOLL, where a kernel thread checks the queue continuously, reducing syscalls further but using CPU time. For developers building servers or proxies, the choice between epoll and io_uring depends on workload, performance goals, and complexity.

AMD says it will bring back a memory encryption feature to Ryzen 9000 desktop CPUs through a BIOS update in July. The feature, called Transparent Secure Memory Encryption, or TSME, helps protect data stored in system memory. System memory, also called RAM, holds information that the computer is actively using. AMD said the change follows valuable community feedback, showing that users strongly wanted the feature to return.

Memory encryption is a security function that makes data in RAM harder to read if someone gets low-level access to the machine. In simple terms, it scrambles information while the system is running. This does not solve every security problem, but it can reduce risk in some attack situations. For users who care about privacy, sensitive workloads, or stronger device protection, the return of this option may be important.

The update will arrive through BIOS firmware, which is low-level software that helps the motherboard start the computer and manage hardware settings. A BIOS update can add support for features, improve compatibility, or fix problems after a product has launched. In this case, AMD is using a firmware update instead of new hardware, which means current Ryzen 9000 owners may be able to get the feature without replacing their CPU.

The news also shows how hardware companies sometimes adjust product decisions after launch. Community feedback can influence feature planning, especially when users point out security or enterprise needs. At the same time, BIOS updates must be installed carefully because they change core system behavior. For PC builders, IT teams, and engineers, this story is a reminder that platform security is not only about the operating system. It also depends on firmware, hardware design, and support after release.

A Lithuanian startup and a group of activists have launched an open-source system to detect Shahed-type drones. The project is called Drone Radar. It connects data from volunteers’ phones to create a shared detection network. According to the organizers, the goal is to add another layer of public safety and improve national resilience. The system is designed as a civic tool, meaning ordinary people can join and help build the network.

Verified volunteers take an unused Android smartphone, connect it to power, and place it near a window at home. An app on the phone continuously listens to ambient sounds, which means the normal background sounds in the area. It looks for low-frequency sound patterns linked to the engines of Shahed-type drones. When the app notices a suspicious sound, an embedded algorithm studies the acoustic signature, or the unique sound pattern, to decide whether it may match a drone.

The system becomes more useful when several nearby devices detect the same signal. By comparing reports from different phones, the network can estimate the possible location of the object. The initiative includes a monitoring platform with an interactive public map, as well as the sensor app for participants. The team behind the project includes specialists and partners from technology and security organizations, including experts connected to artificial intelligence and defense-related groups in Lithuania.

The organizers want to recruit 10,000 active users and later expand across the Baltic states and Poland. In the future, the network may include not only smartphones but also audio from surveillance cameras used by residents. The team is also discussing possible cooperation with public institutions. The project shows how existing consumer devices can be turned into a distributed sensor network. It also highlights the growing role of open-source and community-based technology in responding to modern security threats.

Loupe is a free, open-source app for iPhone and iPad that helps users understand digital privacy. It was created by Mysk and is available as a project on GitHub. The app gives people a hands-on look at the information that native apps can read from public iOS APIs. In simple terms, APIs are software tools that let apps ask the operating system for data or system details.

The main goal of Loupe is to raise awareness about device fingerprinting. Device fingerprinting is a method of recognizing a device by combining many small signals, even when a person does not share their name, email, or location. Loupe shows these values in raw form, which means the data is displayed directly instead of being simplified or hidden. According to the project description, each signal may not identify a person alone, but several signals together can create a fingerprint that follows a user across apps and websites.

Loupe organizes what it finds into three tiers. The first is passive data, which any app can access without asking the user. Examples include locale, time zone, screen details, and battery information. The second tier is data that needs permission, such as contacts, photos, location, and calendars. The third tier is called advanced, and it includes side-channel techniques using public APIs, such as checking URL schemes through canOpenURL or using Keychain persistence across reinstalls.

The project also makes a strong privacy promise. It says that nothing Loupe reads leaves the device unless the user chooses to export it. The app does not upload, sync, or share the collected values. The repository notes that Loupe was built almost entirely with AI coding tools, which is also interesting from a software engineering view. For developers, Loupe is a useful reminder that even public APIs can expose more information than users expect, so privacy-aware design matters from the start.

A new case study from Bayer and Thoughtworks shows how companies are trying to build reliable agentic AI systems for real work. Their platform, called PRINCE, is used in preclinical drug research, where teams must search through many years of safety study reports. In the past, researchers often depended on keyword-based search and strict Boolean logic. These methods could find documents, but they were not always good at answering complex questions in natural language.

PRINCE developed from a basic search tool into an intelligent research assistant. It combines Retrieval-Augmented Generation, or RAG, with Text-to-SQL. RAG means the system first retrieves relevant information from trusted data sources and then uses a language model to generate an answer based on that information. Text-to-SQL lets users ask questions in everyday language, while the system turns them into database queries. This approach can help researchers access data more quickly and draft regulatory documents more efficiently.

The article says reliability depends on more than just a strong model. The team focused on context engineering, which means shaping and routing the right information to different specialized agents. For example, one agent may clarify user intent, another may research the data, and another may write the final response. They also worked on orchestration, recovery, and observability. In simple terms, this means managing how the agents work together, handling errors, and watching system behavior closely.

Trust was a major goal of the project. The system was designed with transparency, explainability, and human-in-the-loop review so users can understand where answers come from and check them before using them in important work. The case study also highlights evaluation, monitoring, and iterative development as key parts of building production-ready AI. The main lesson is clear: successful agentic AI is not only about model intelligence. It also requires strong engineering, governance, and careful system design.

A recent science-related blog post by engineer Marc Brooker explains a surprising idea about waiting time in digital services. He introduces “Alice,” an impatient user who says a web service feels slow. The service team answers that the mean, or average, request time is only about 100 milliseconds. However, Alice says her average wait feels closer to one second. According to the post, both views can be correct at the same time.

The reason is that engineers and users often measure time in different ways. Service teams count requests or outages as separate events. Users experience time in seconds and minutes. If one request takes much longer than usual, a user spends more real time inside that slow request. In the same way, a long outage feels much more important than a short outage because people live through every extra minute. This effect is linked to the inspection paradox, a statistical idea where long events are more likely to be noticed simply because they last longer.

Brooker says users do not experience the normal latency distribution directly. Instead, they experience a time-weighted version of it, where long waits have greater influence. This means a system can show a reasonable average while still feeling bad to customers. In examples about recovery time, a service may report a mean time to recovery of about an hour, while customers experience something much longer because rare but very long outages dominate their experience.

The post argues that tail latency and long recovery times matter more than many teams realize. “Tail” means the slowest and rarest cases in a set of results. The author also warns against relying too much on trimmed measurements, such as trimmed means, because they remove extreme values. Those extreme values may be exactly what shapes the customer experience. For engineering teams, the lesson is clear: reducing very slow requests and very long outages can improve user trust more than improving already-fast average performance.

A new discussion in AI is questioning the idea that bigger models are always better. According to a recent comparison, GLM-5.2, an open-weight model released under the MIT license, performed close to much larger proprietary systems on a general intelligence ranking. At the same time, it reportedly produced far fewer hallucinations than some of the biggest models, including GPT-5.5. In AI, a hallucination means giving a wrong answer with confidence instead of saying “I don’t know.”

The source says GLM-5.2 has 753 billion parameters, with about 40 billion active at one time. Even so, it came close to models believed to be much larger. This has led some people to argue that simple scaling may be reaching its limits. In other words, adding more parameters and more training data does not always create a clearly smarter system. Some researchers now think model design, data quality, and the ability to reason safely may matter more than size alone.

One striking claim in the comparison is about hallucination rates. On a benchmark that tests whether models admit uncertainty, GLM-5.2 reportedly scored much better than GPT-5.5 and some other very large models. The article argues that huge models trained on large amounts of factual material may learn to answer almost everything, even when they should refuse or express doubt. That behavior can be dangerous in technical work, where a confident but false answer may look convincing to users.

The article also describes a Python architecture question used as a test. In that example, GLM-5.2 quickly identified a technical impossibility in the prompt, while another large model generated a detailed but incorrect solution. This suggests that a useful AI system is not just one that answers often, but one that knows when a task cannot be done as described. For engineers and companies, the lesson is practical: model reliability, honesty about limits, and lower hallucination rates may be more valuable than model size.

OCaml version 5.5.0 has been released. The announcement was made on June 19, 2026, and it highlighted several language and tooling improvements. OCaml is a programming language known for strong type checking, which helps developers catch mistakes early. The new release focuses on making code easier to write, easier to reuse, and faster to manage in real projects.

One important new feature is module-dependent functions. In simple terms, a module can now be passed as a function argument in a lighter and more direct way. This helps developers write reusable functions for data structures such as maps without using more complex patterns. The release notes explain that this works when the module is statically known, meaning the compiler must know the module at compile time rather than choosing it later at runtime.

Another improvement is support for higher-rank polymorphic functions as function arguments. Although the name sounds difficult, the idea is practical: developers can now express some very general functions more directly with type annotations. In earlier versions, they often needed extra wrappers such as records or objects. OCaml 5.5.0 also expands substring search and replace functions in the String module, which should make everyday text processing tasks simpler.

The release also introduces a relocatable compiler. This means a compiler installation can be moved or copied more safely, without causing hidden problems from incompatible runtime parts. In practice, this should reduce the time needed to create local opam switches when the same compiler version and configuration already exists globally. For teams, these changes may improve developer productivity by reducing setup time and by making advanced language features easier to use in a clean and reliable way.

A 2023 online post argued for a system that would connect all internet traffic to a real identity. The idea was presented as a way to protect children and reduce harmful content. Supporters of stronger controls often say anonymous users can spread abuse, threats, or illegal material more easily. In this debate, “real ID” means a verified identity linked to a person, not just a screen name or email address.

In practice, such a system would require identity verification before people could use websites, apps, or network services. Identity verification is the process of checking that a user is a real person and confirming who that person is. This could involve government documents, phone numbers, or another trusted record. A real-ID model could also create a record of online activity, making it easier to trace posts, messages, and uploads back to an individual.

However, critics say this approach creates serious privacy and security risks. If every action is tied to one identity, a data breach could expose very sensitive information. A central database of identities and browsing records would become a valuable target for attackers. Experts also warn that surveillance could increase, because governments, companies, or other groups might track people more closely. For journalists, activists, or whistleblowers, anonymity can be an important protection.

The discussion is not only about law or politics; it is also about system design. Engineers must think about access control, data retention, encryption, and misuse prevention. Even if a policy aims to improve safety, it can produce new risks and technical challenges. The wider lesson is that online safety tools need careful design, clear limits, and strong accountability, especially when they affect the privacy and freedom of all users.