📰 English IT Daily · 2026-07-21

A recent blog post by developer and founder Chip Weinberger challenges a famous idea in tech: “hardware is hard.” He wrote about building and selling a product called Jamcorder, a MIDI recorder for piano players. MIDI is a standard way for musical devices to send note information, so a MIDI recorder can capture what a person plays without recording audio directly. Weinberger says he launched the product about a year and a half ago and has already sold around 2,500 units. For him, that result shows that a small hardware product can become a real business and not just a side project.

What surprised him most was not customer demand, but the development process itself. After spending years in software, he expected hardware to be the toughest part. Many engineers hear warnings about electronics design, plastic parts, manufacturing, shipping, and parts shortages. These risks are real, and they can derail a project. But in his case, the hardware side went more smoothly than expected. To refine the process, he hand-assembled the first 500 units himself, and he said the work took only four days. He was waiting for some major problem to appear, such as a failed production run or a sourcing crisis, but that did not happen.

Instead, the real mountain to climb was the software around the device. According to the post, the total system included roughly 200,000 lines of code across firmware, an app, and manufacturing tools. Firmware is the low-level code that runs directly on a device. He said this work took more than three years and many late nights, especially before large language models became common tools for coding support. In other words, the physical product may look like the risky part from the outside, but much of the hidden complexity lived in the code and the supporting systems needed to ship the product reliably.

A key reason the hardware stayed manageable was deliberate simplicity. Weinberger explains that Jamcorder was designed to avoid unnecessary complexity from the start. Its circuit board had only 25 unique components. Most of them were off-the-shelf parts, meaning standard items that are easy to buy rather than custom-made pieces from a single supplier. The assembly process was also simple, with just one screw for one circuit board. He also cut several features that might sound useful, including low-battery detection, ambient light detection, a power button, and even USB-C. Those choices may seem austere, but they reduced the number of things that could go wrong.

This does not mean hardware is always easy. The author is careful to say that his lesson applies mainly to a simple device at a moderate scale. If the product were ten times more complex, or produced at much larger volume, the picture could change quickly. The same is true in highly competitive markets such as smartwatches or cars, where margins are thin and customer expectations are very high. In those areas, every design decision can become a double-edged sword: adding features may attract buyers, but it also raises cost, risk, and manufacturing difficulty. His broader point is narrower and more practical: hardware is often “as hard as you make it.”

The post ends with practical advice for founders and engineers who want to ship a physical product. He recommends keeping the bill of materials, or BOM, simple; avoiding parts from only one manufacturer when possible; and staying away from complex assembly and calibration steps. He also suggests working with Chinese assembly partners and suppliers, using marketplaces such as Alibaba, and protecting margins with a lean company structure. For software engineers, the message is especially interesting. Many people assume hardware is out of reach, but this story suggests that careful scope control, disciplined design, and smart supply choices can lower the barrier. The harder challenge may not be the device itself, but everything around it: tools, workflows, support, and long-term reliability.

A new debate is growing in the AI industry: should powerful models stay locked inside company services, or should they be released more openly? Recent discussion around Chinese AI companies suggests that open-weight models may be giving China an edge in some parts of the market. Open weights means the trained model can be downloaded and run by others, even if the full training code and data are not shared. This is not the same as open source, but it still gives users much more freedom than a fully closed service.

One reason this matters is that AI models themselves may not have a very strong moat. In business, a moat means a lasting advantage that is hard for rivals to copy. For many users, switching from one model to another is not very difficult, especially when models are accessed through an API. A developer can often swap one provider for another without changing the whole workflow. That means the real business value may sit elsewhere: in enterprise contracts, integration with internal systems, reliability, support, and tools that make life easier for large organizations.

This situation creates an opening for Chinese companies. Because of export controls on advanced GPUs and restrictions on sending some kinds of information to Chinese systems, Chinese firms may face limits in offering the same kind of global centralized AI service as major US companies. But open-weight releases can turn that weakness into a different kind of strength. If a model is portable and permissionless, companies, researchers, and governments can run it where they want, adapt it to local rules, and tune it for their own use cases. In that sense, distribution can matter as much as central control.

Supporters of this strategy argue that open infrastructure often gains traction faster than closed alternatives. When people can experiment freely, build tools around a model, and connect it to their own products, an ecosystem can grow quickly. This can commoditize the model layer, meaning the model itself becomes less special and less profitable on its own. If that happens, companies that depend mainly on charging for access to a closed model could come under pressure. By contrast, those who spread their technology widely may benefit from broader adoption across manufacturing, research, education, and other sectors.

Another reason the debate is heating up is that the performance gap may be narrowing. For some time, the strongest protection for leading American AI firms was simple: their top models were clearly better than most open alternatives. If that lead becomes smaller, the closed approach may look less convincing. Reports and commentary have suggested that some Chinese models are becoming much more competitive while also being cheaper to use. If users can get similar results at lower cost and with more control, they may be more willing to switch than many vendors expect.

Still, this strategy is not a clear win in every sense. Open-weight models raise questions about safety, misuse, and political influence. Critics also worry that models developed in China may reflect the views or limits of the Chinese state on sensitive topics. At the same time, the current market creates an awkward contrast: China is often seen as politically restrictive, yet some American AI firms are the ones keeping tight control over their technology. For engineers and business leaders, the key issue is not only who has the best model today, but which ecosystem will prove more resilient, adaptable, and widely adopted over time.

A federal judge in San Francisco has given final approval to Anthropic’s 1.5 billion dollar settlement in a copyright lawsuit brought by a group of authors. The writers said the AI company used their books without permission to train Claude, its chatbot. According to the Reuters report, this is the largest known settlement in a US copyright case. The decision also matters because it is the first major American lawsuit over AI training and copyright to reach a settlement instead of going all the way to trial.

The case began after authors sued Anthropic in 2024. They argued that the company had relied on pirated digital copies of books while building its large language model, or LLM. An LLM is a system trained on huge amounts of text so it can answer questions and generate writing. Last year, Judge William Alsup made a key ruling that training AI on books counted as fair use under US copyright law. However, he also said Anthropic may have broken the law by storing more than seven million pirated books in a central library that would not necessarily be used for training.

That distinction is at the heart of the case. In simple terms, the court treated the act of training the model differently from the act of keeping a large archive of pirated material. A trial had been scheduled to decide how much money Anthropic might owe for that alleged piracy. Potential damages were described as extremely large, possibly reaching into the hundreds of billions of dollars. Against that backdrop, both sides had strong reasons to avoid a long and risky courtroom fight and instead sign off on a negotiated deal.

Some authors objected to the settlement. They argued that 1.5 billion dollars was too small, that the lawyers for the class would receive too much, or that some copyright owners had been left out. But Judge Araceli Martinez-Olguin overruled those objections. In her ruling, she said complaints about the size of the settlement were not grounded in a realistic assessment of the risks and rewards of a trial. She also approved more than 101 million dollars in legal fees, although that was less than the full amount requested by the attorneys.

Anthropic said the agreement followed a landmark court ruling in 2025 that found AI training on books to be fair use, and it noted that more than 91 percent of the authors and publishers covered by the settlement had claimed their share. The authors’ lead lawyer called it a historic recovery and said payments should be distributed as quickly as possible. At the same time, not everyone accepted the deal. Some authors and publishers opted out and are still pursuing separate lawsuits, which means the wider legal battle is far from over.

The case matters far beyond one company. Dozens of lawsuits have been filed by authors, artists, and news organizations against tech firms over the materials used to train AI systems. For the industry, this settlement may offer a glimpse of how courts and companies could draw the line between fair use and unlawful copying. For engineers and product teams, the lesson is clear: how training content is collected, stored, documented, and governed can become just as important as model performance. As AI tools move into mainstream products, copyright compliance is no longer a side issue; it is becoming part of core technical and business strategy.

A cyberattack on Romania’s land registry agency has shown how deeply public services depend on digital systems. According to reports, a hacker breached the country’s cadastre agency and wiped its land registry database after a failed extortion attempt. The attack reportedly used valid credentials, which suggests the intruder did not need to force entry in a noisy way. Instead, the person seems to have logged in like a normal user, moved through internal systems, and then deleted both systems and backups. For a government agency that manages property records, that kind of disruption can quickly bring daily life to a halt.

The direct effects were serious. Romania’s real-estate market reportedly came to a standstill because official websites and apps were offline for about a week. Notaries could not record new property transactions, and citizens could not obtain proof of ownership or detailed land records. Email services at the agency were also down, making communication harder during the crisis. In practical terms, this means the attack was not only an IT problem. It became a legal, financial, and social problem as well, because land records are central to buying, selling, inheriting, and financing property.

This case is also a reminder that extortion is not always about encrypting files, as in classic ransomware. Sometimes attackers first gain a foothold, study the network, steal sensitive information, and then try to pressure the victim into paying. If the victim refuses, the attacker may wipe systems, leak stolen materials, or do both. In the Romanian case, some stolen information was reportedly offered for sale on a hacking forum. The material allegedly included employee credentials, internal documents, and details about the agency’s IT network. That raises the stakes because recovery is not only about restoring operations; it is also about limiting future misuse of exposed information.

Officials later said they were rebuilding the agency’s network from scratch, which is often necessary after a severe breach. Rebuilding from scratch can be slow and expensive, but it may be the safest path when defenders can no longer trust the existing environment. Reports also suggest the attacker claimed to have deleted backups. However, the agency appears to have had an offline copy, which may have prevented a much deeper national crisis. This point matters because offline backups are one of the few defenses that can still hold up when attackers gain broad access inside a network and try to destroy recovery options.

The incident also fits a wider pattern. Romania is not the only country whose land registry or similar public records systems have been targeted in recent years. These agencies are attractive targets because they hold critical information with real economic value. If ownership records are unavailable, even for a short time, many activities stop. If records are changed or lost, trust in the state can suffer. That is why public-sector cyber defense must go beyond perimeter security. Agencies need stronger identity controls, tighter monitoring, network segmentation, tested incident response plans, and backup strategies that are isolated from the main environment.

For technology professionals, the lesson is clear: resilience matters as much as prevention. Strong defenses can reduce risk, but no organization can assume it is untouchable. Valid credentials can be stolen, insiders can make mistakes, and attackers can spend time mapping a network before acting. That means teams must prepare for the worst-case scenario, not just the most likely one. For citizens, this event is a warning that invisible digital infrastructure supports very visible parts of life, from home purchases to legal rights. When that infrastructure goes down, the effects ripple far beyond the IT department.

Kimi Work is a new desktop AI agent aimed at knowledge workers, people whose jobs depend on reading, writing, research, and analysis. According to its product page, the tool is designed to work closely with a user’s local computer instead of staying only in a web browser. That means it can look through local folders, automate browser actions, run code in the background, and handle scheduled tasks. In simple terms, Kimi Work is trying to move AI from a chat window into the day-to-day flow of office work.

One of its main selling points is deep connection to local files. The example on the site shows Kimi searching a workspace for PDF files about quarterly reports and then creating a clear summary document without moving the original files. For many office workers, that kind of task is a major time sink. Reports, slide decks, and spreadsheets often sit in different folders, and finding the right files can be frustrating. A local agent could cut through that clutter by searching, reading, and organizing information more directly than a standard chatbot.

Kimi Work also highlights always-on automation. It includes a built-in Cron engine, which is a scheduler for running tasks automatically at set times. The company says users can schedule LLM-based briefings, Python or shell scripts, and other repeated jobs. This set-it-and-forget-it model could appeal to teams that do routine work every day, such as preparing morning summaries or processing files overnight. If it works well, the value is not just speed but consistency, because the same task can happen on time without someone remembering to start it.

Another feature is WebBridge, described as a tool for browser automation. Instead of only answering questions, the agent can click, scroll, open tabs, collect information, and complete multi-step web tasks. Kimi also promotes an agent swarm approach, where several specialized agents break down a larger job and work on different parts at the same time. After the research is done, the product says it can turn the results into office documents such as PowerPoint decks or Excel sheets. This points to a broader trend in AI: moving from single replies to end-to-end task execution.

The idea is promising, but it is also a double-edged sword. A desktop agent with access to files, code execution, and browser actions needs strong safeguards. Kimi says users stay in the driver’s seat because the system asks for permission before modifying files, overwriting content, or running code in local directories. That is an important design choice. Even so, users and companies will want to look closely at privacy, accidental actions, and how much autonomy they are comfortable giving an AI system. In real workplaces, trust is not built overnight.

Kimi Work is especially positioned for finance, with built-in access to market information for Chinese and US equities. Still, the bigger story may be what this product says about the direction of AI tools in general. More companies are trying to turn AI into a system-level assistant that can observe, plan, and act across apps and files. If these tools gain traction, knowledge work could shift from manual coordination toward supervision and review. The key question is whether desktop agents can be reliable enough for daily use while staying transparent, controllable, and safe.

Google has announced three new Gemini models: 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber. The company says these models are designed for developers and businesses that want to build AI agents at scale. In simple terms, AI agents are systems that can take several steps to finish a task, often using tools and reasoning along the way. For teams running these systems in production, speed, cost, and steady performance matter just as much as raw intelligence. Google is trying to hit that sweet spot with the Flash family, which focuses on efficiency as well as quality.

The main release is Gemini 3.6 Flash, which Google describes as its workhorse model. It is meant to handle coding, knowledge work, and multimodal tasks better than 3.5 Flash, while also using fewer output tokens. Tokens are the small pieces of text that a model reads and writes, and they are closely tied to cost. According to the source, 3.6 Flash reduces output token usage compared with 3.5 Flash, and it can also complete multi-step workflows with fewer reasoning steps and fewer tool calls. That matters because lower token use and fewer extra actions can trim both latency and total spending.

Google also says 3.6 Flash offers better quality, not just lower cost. In benchmark results mentioned in the announcement, the model showed stronger coding performance, better computer-use ability, and improved results in research-style tasks. Just as important, Google says the model makes fewer unwanted code edits and gets stuck in fewer execution loops. For developers, that can be a practical gain. A model that is a little less verbose and more precise may save time during testing, reduce noisy outputs, and make agent behavior easier to predict. In real projects, reliability often carries as much weight as headline benchmark scores.

The second model, Gemini 3.5 Flash-Lite, is aimed at teams that need the fastest and most cost-effective option in the 3.5 class. Google highlights its high output speed and says it performs much better than earlier Flash-Lite versions in agentic workflows. This suggests that not every company needs the strongest model for every task. Some jobs, such as quick classification, summarization, or routing work between systems, may benefit more from low latency and low cost than from top-end reasoning. In that sense, Flash-Lite could carve out a clear role in large systems where millions of responses must be delivered quickly.

The most security-focused release is Gemini 3.5 Flash Cyber, introduced together with CodeMender, a code security agent. Google presents this as a specialized setup for cybersecurity work, where the model is paired with agent infrastructure rather than used alone. That point is worth underlining. In security, success often depends on careful orchestration: the model must work with scanners, policies, code analysis tools, and human review. A specialized model may improve performance in this narrow field, but security teams will still need strong guardrails, clear escalation paths, and close testing before trusting automated actions.

These releases reflect a broader shift in AI. The market is moving away from a simple race for the biggest model and toward systems that are cheaper, faster, and easier to run reliably in production. For engineering teams, the real question is no longer only which model is smartest, but which model is fit for purpose. A highly capable model can be a double-edged sword if it is too expensive or too slow for everyday workloads. Looking ahead, Google says Gemini 3.5 Pro is being tested with partners, and work on Gemini 4 has already started. That means competition will remain intense, but for users today, efficiency is quickly moving to the center of the conversation.

A small open-source project called monitor-input-rs shows how a narrow tool can solve a real daily problem. The project is a command-line tool that changes the input source of a display monitor through DDC/CI, a standard that lets a computer send control commands to a monitor. In simple terms, it means a user may be able to switch a monitor from HDMI to DisplayPort without touching the monitor’s physical buttons. The project is available on Windows, macOS, and Linux, and it is also exposed as a library for developers who want to build it into other tools.

That may sound like a minor convenience, but it can remove a surprising amount of friction. Many engineers use one monitor with several devices, such as a work laptop, a personal desktop, and a game console. In that setup, changing the input source can become a repetitive task. Monitor menus are often clumsy, and the buttons are sometimes hidden under the screen or placed in awkward positions. A command-line utility can streamline that routine. It also opens the door to shortcuts, scripts, and automation, which are especially attractive to technical users who already manage parts of their environment from the terminal.

According to the project page, the tool can list connected display monitors and show information such as the current input source and the backend used to detect the monitor. Users can search for monitors by part of the monitor name, or by index number. The README also notes that the same monitor may appear twice if the system finds it in more than one way, for example through the operating system and through display driver interfaces. That detail may sound technical, but it reflects a practical reality: hardware control is rarely neat and tidy across different platforms.

The cross-platform aspect is one reason the project stands out. Hardware control tools often splinter because each operating system handles devices differently. Here, the tool aims to work across major desktop systems, although the setup is not identical everywhere. The project notes, for example, that Linux requires libudev, and Windows offers an optional application variant designed to avoid a console window popping up when launched from non-console apps. On Windows, that version shows errors through toast notifications. These details underline a broader lesson in systems programming: the same user-facing result can require different plumbing under the hood.

There are, however, trade-offs. DDC/CI support depends on the monitor, the cable path, and sometimes the graphics stack, so behavior may vary. In other words, this kind of tool is convenient, but it is not always plug-and-play. Users may need to test which backend works best or filter results when a monitor is listed more than once. For some people, a graphical utility may still be more approachable. Yet command-line tools continue to gain traction because they fit neatly into automation workflows. A simple command can be tied to hotkeys, startup scripts, or custom device-switching routines.

Projects like monitor-input-rs matter because they sit at the intersection of hardware control, operating system differences, and developer ergonomics. They do not try to reinvent the wheel; instead, they smooth out a rough edge in everyday computing. For software engineers, the project is also a reminder that useful tools do not need to be huge to have impact. A focused utility can save time, reduce small annoyances, and encourage deeper understanding of the systems we rely on. As hybrid work and multi-device desks become more common, practical tools like this may carve out a steady place in the toolkit of power users.