📰 English IT Daily · 2026-06-19

A security researcher says he found a large malware campaign on GitHub. The problem started when he searched for one of his own projects and saw another repository with exactly the same name and description. It looked like a copy of the original project, including its commit history. However, a new commit had been added recently. That update changed only the README file and inserted a link to a ZIP archive. The researcher later found another repository with the same unusual pattern.

After watching these repositories, he noticed repeated activity. Every few hours, the attackers appeared to delete the previous commit and push the same kind of commit again. The only visible change was the added archive link in the README. According to the report, many repositories were new, not forks, and came from different contributors with different names. Because of this, they were harder to connect at first. The researcher says this shared behavior helped him create a script to search for more examples.

The report says the ZIP archive usually contained four files, such as a command script, an executable file, another small file with a random name, and a DLL file. If a person checked only the archive link with a malware scanning service, the result could show no threat. But when the full ZIP file was uploaded, a Trojan was detected. A Trojan is malware that looks harmless but secretly performs harmful actions after the user runs it.

The researcher says he reported some repositories to GitHub support, but action took time. Later, he used a search pattern based on copied commits, README-only updates, archive links, and new non-fork repositories. With this method, he says he found around 10,000 repositories linked to the campaign. The case shows how attackers can abuse trusted developer platforms to spread malware. It also highlights the need for careful review of project copies, download links, and unusual commit behavior.

A new report says AMD has quietly removed a security feature from some consumer Ryzen CPUs. The feature is called memory encryption. In simple terms, it protects data stored in system memory by turning it into unreadable code. This can help stop attackers from reading sensitive information if they get low-level access to a computer. The report says the feature disappeared after newer AGESA firmware updates, but many users were not clearly told about the change.

AGESA firmware is low-level code that helps a motherboard start and manage an AMD processor. Because it controls important hardware functions, even small changes can affect performance, stability, and security. In this case, the reported change matters because users may still believe their systems have the same protection as before. If a security feature vanishes without clear notice, it becomes harder for people and companies to understand their real risk.

The issue also raises questions about transparency. According to the report, AMD engineers did not give clear public answers when asked about the removal. That silence has led to concern in the hardware community. Security features are often difficult for ordinary users to check by themselves, especially when they depend on firmware and motherboard support. As a result, many people may remain unaware that their systems are now missing a protection they expected to have.

For consumers, the practical danger may depend on the threat model, or the type of attack they worry about most. Not every user faces the same level of risk. Still, experts often say that security features should not be reduced quietly. Clear communication is important so that users, IT teams, and device makers can make informed decisions. This case is a reminder that firmware updates are not only about fixing bugs or improving speed; they can also change a system’s security posture.

A recent blog post argues that many command-line tools still use an outdated login experience, especially when developers work on remote machines. Today, many CLIs open a browser and use OAuth, a standard way to let users sign in safely through a provider. On a normal laptop, this feels simple: the tool opens a web page, the user logs in, and the CLI receives permission to continue. The process is fast, so many people never notice how it works behind the scenes.

In many cases, the CLI starts a small local HTTP server on localhost and waits for a callback from the browser. After login, the provider redirects the browser to a loopback address such as 127.0.0.1 with an authorization code. The CLI reads that code and exchanges it for tokens, often with PKCE, a security method that protects the code exchange. This pattern is recommended for native apps when the browser and the app run on the same machine.

The problem appears when that assumption is false. If a developer connects to a cloud VM or other remote host through SSH, the CLI may try to open a browser on the remote machine, where no browser exists. Some tools then fall back to a manual step: they show a long login URL, the user opens it on a different device, receives a one-time code, and pastes it back into the terminal. This can work, but the blog says it feels old and awkward for modern developer workflows.

The author’s main point is that this problem is already understood, but many tools still have not improved their design. The usual localhost flow is almost invisible on a personal computer, because the browser quickly redirects and hides the local callback step. However, in remote development, the same design becomes fragile and confusing. For engineers, the lesson is clear: authentication should match real working environments, including SSH sessions and browserless systems, instead of assuming every CLI runs next to a local browser.

As companies adopt AI tools more quickly, some people believe software development will become less strict and more experimental. But many engineers argue the opposite. They say AI increases the need for engineering discipline because systems become harder to predict, test, and maintain. When a model can produce different answers to the same question, teams need clearer processes to control quality and reduce risk.

In traditional software, developers usually define exact rules and expected outputs. With AI, especially large language models, the output is based on probability, not fixed logic. This means prompts, training data, and system design can all affect results in unexpected ways. Because of this, teams need stronger evaluation methods, careful documentation, and clear ownership. Without these practices, it becomes difficult to understand why a system failed or how to improve it.

Engineering discipline in AI also includes monitoring after release. A system may work well in a test environment but perform differently with real users, changing data, or new business needs. For that reason, companies need version control, fallback plans, and regular review of model behavior. Security and privacy are also important, since AI systems may process sensitive information or generate incorrect content that looks convincing.

Supporters of a disciplined approach say AI should not reduce engineering standards. Instead, it should expand them. Teams still need good architecture, reliable testing, and strong communication between product, legal, and engineering groups. AI may speed up some tasks, but it also introduces uncertainty. In that environment, careful design and operational discipline are not barriers to innovation. They are what make useful and trustworthy AI systems possible.

A new research report suggests that many US consumers are not impressed when brands highlight AI in their messaging. According to the study, 60% say the word “AI” in brand communication is a turnoff rather than a benefit. The report also says 61% of consumers cannot name a brand that uses AI well in its messaging. This shows a clear gap between company strategy and public reaction.

The research connects this problem to a broader change on the internet. Many people feel the web is becoming less human, and they get tired of content that sounds artificial. The report describes this feeling as “bot fatigue,” meaning users become bored or frustrated when too many interactions feel machine-made. In the study, consumers reached this point after about 40 minutes on average. For brands, this means that simply adding AI tools is not enough to build trust.

The report also introduces the idea of AI brand visibility. This means how often a company appears in answers from AI engines such as ChatGPT, Claude, Gemini, or Perplexity. It is different from traditional search engine visibility, which measures where a website ranks on a results page. A brand may rank highly in search but still not be mentioned by an AI assistant. Because of this, many enterprise teams are now trying to improve both search performance and AI visibility at the same time.

However, the report says no company has become a clear leader in this area yet. It argues that brands should build for two audiences at once: AI systems need clean, well-structured content, while human readers need useful and honest information. In other words, the technical side matters, but the human experience matters just as much. For businesses, the lesson is simple: using AI successfully may depend less on saying “we use AI” and more on creating content that feels helpful, clear, and human.

Science in the U.S. is facing a period of serious uncertainty. A recent Scientific American article argues that the long-standing relationship between science and politics has broken down. For many years, federal funding helped support basic research, meaning early-stage studies that explore big questions without promising quick business results. This kind of research often leads to major discoveries later. Now, researchers say sudden budget pressure and political decisions are making long-term planning much harder.

One example is AXIS, a proposed space telescope designed to study the early universe, including the first black holes and the formation of galaxies. The project used x-ray mirrors made from single-crystal silicon, a material chosen for its strong and precise properties. The team had received a grant from NASA to improve the idea and was working with engineers at NASA’s Goddard Space Flight Center. At first, the mission seemed to be moving forward in a normal way.

Then, according to the article, major staffing changes created what one scientist called “programmatic chaos.” NASA offered buyouts, paid leave and early retirement to many workers, and thousands accepted. As a result, some important experts left projects in the middle of development. On the AXIS team, this reportedly included engineers, managers and a scientist connected to the mirror technology. When experienced staff leave suddenly, teams can lose technical knowledge, project history and decision-making continuity.

At the same time, the Trump administration’s budget proposal called for large cuts to science funding, and one program connected to AXIS was removed from the request. Although Congress still controls final appropriation, the article says some leaders began changing priorities early to match the proposal. That shift delayed planning and cost work for the telescope team. The broader issue is not only one mission. It is whether a country can keep producing new science when funding, staffing and policy become unstable.

MicroUI is a small user interface library for programmers who want a simple way to build desktop-style controls. It is written in ANSI C, a widely supported version of the C language, and it is designed to be portable across different systems. According to its GitHub page, the project focuses on being tiny and lightweight. The code base is around 1,100 lines, which makes it much smaller than many full UI frameworks.

The library uses an immediate-mode approach. In simple terms, this means the program describes the interface again during each update, instead of storing a large UI structure over time. MicroUI includes built-in controls such as windows, buttons, sliders, textboxes, labels, checkboxes, scrollable panels, and word-wrapped text. It also has a simple layout system, and the project is designed so that developers can add custom controls without too much difficulty.

One important point is that MicroUI does not do the actual drawing by itself. Instead, it expects the user to provide input events and to handle the drawing commands that the library produces. Because of this design, it can work with different rendering systems as long as they can draw rectangles and text. The project also says it works within a fixed-sized memory region, so it does not allocate extra memory while running.

This design makes MicroUI interesting for developers who value control, small size, and portability over a long list of features. The repository presents it as a foundation rather than a complete framework, and it notes that large feature additions may not be accepted. For software engineers, especially those working close to hardware or building tools with limited resources, MicroUI shows how a focused library can solve a practical problem with very little code.

Valve has released SteamOS Linux 3.8 as a stable version for the Steam Deck. A stable release means the software is ready for general use, not only for testing. SteamOS is the operating system that runs on the handheld gaming device. An operating system is the main software that manages hardware, apps, and system resources. For users, a stable update is important because it usually brings a better balance of new features, bug fixes, and reliability.

The news is notable because SteamOS is based on Linux, an open-source operating system used in servers, development, and embedded devices. Open-source means the software is built in a way that allows its code to be shared and improved by a wider community. In the case of SteamOS, Valve adapts Linux for gaming use. This shows how Linux can support not only professional workloads but also consumer products that need smooth performance and a simple user experience.

For developers and IT professionals, a stable SteamOS release is interesting beyond gaming. It highlights how a Linux-based platform can be packaged for a specific device and updated over time. In practical terms, this is similar to how many companies maintain custom software platforms for appliances, kiosks, or internal tools. Each update must improve compatibility with hardware and applications while reducing the risk of new problems after deployment.

The release also reflects a larger trend in technology: software platforms are becoming more specialized, but users still expect easy updates and dependable performance. Even when a product is made for entertainment, the engineering challenges are familiar to many software teams. They include release management, quality testing, hardware support, and user feedback. As a result, SteamOS 3.8 is not just gaming news; it is also a useful example of how modern Linux products are built and maintained.

Lore is a next-generation open source version control system maintained by Epic Games. It is designed for projects that need to manage both source code and large binary assets, such as game files, images, audio, and video. According to its website, Lore focuses on scalability for both data and teams. It also aims to support different kinds of users, including software developers and artists, who often work on the same project but have different workflow needs.

One of Lore’s main ideas is a centralized architecture with content-addressed storage. In simple terms, files and repository data are stored and referenced by their content hash, which is a unique value created from the data itself. Lore represents repository state with Merkle trees and an immutable revision chain. This structure helps with integrity checks, meaning teams can verify that data has not been changed in an unexpected way. The system is described as tamper-evident, so changes in history should be easier to detect.

Lore is also optimized for binary-first storage and large files. It uses chunked storage, which breaks files into reusable pieces, to reduce duplication and improve transfer efficiency. Another feature is on-demand hydration, which means users do not need to download every file at the start. Instead, they can fetch data only when needed and keep sparse workspaces lightweight. The website says this approach can help large teams avoid slowdowns when working with very large repositories.

The project also highlights practical developer features such as lightweight branches, fast switching, a full command-line interface, and APIs for several languages, including C/C++, C#, Rust, Go, Python, and JavaScript. Lore is fully open source under the MIT license, and Epic Games says it wants development to happen in the open with community input. If Lore succeeds, it could become an interesting option for teams that need version control beyond traditional code-only workflows.

A repair blog recently examined a Sigma 45mm f/2.8 lens that was bought as a broken item at a heavy discount. The writer often buys non-working camera gear because it can be repaired or studied. This lens was part of Sigma’s newer I-series, which is known for a mostly aluminum body. When the lens arrived, its outside condition looked surprisingly good. There were no clear scratches on the barrel or the glass elements, so the problem did not appear to be mechanical.

After cleaning the front and rear elements carefully, the writer mounted the lens on a Lumix S5 camera. The lens clicked into place, but it felt unusually stiff when attached. The camera turned on and showed a live image, which suggested that some basic connection was working. However, none of the electronic controls responded. The switches and dials on the lens did nothing, and the camera also did not detect lens control input. This pointed to an electrical fault rather than a visible physical break.

To investigate the issue, the writer focused on the control PCB, or printed circuit board. This small board is usually located near the rear lens contacts and handles electronic communication between the lens and the camera. The repair process did not require rare equipment. Standard tools such as lint-free wipes, cleaning fluid, a microfiber cloth, a plastic spudger, magnification, and JIS screwdrivers were enough. The writer also noted that Japanese Industrial Standard screws are common in camera products, and using the wrong screwdriver can damage the screw heads over time.

The disassembly began by removing the rear plastic beauty spacer and several screws around the mount area. Two additional screws connecting the plastic terminal interface to the metal mount were also removed. To avoid mistakes during reassembly, the screws were placed on tape in the same orientation as the lens. Although this is a camera repair story, it also shows a broader engineering lesson: modern hardware may look fine on the outside while hiding a deeper electronic failure. Careful inspection, the right tools, and a clear process are often the key to finding the real cause.