📰 English IT Daily · 2026-07-23

A cyberattack on Romania’s land registry agency has shown how deeply digital systems support everyday life. According to reports, a hacker broke into the agency, failed to get money through extortion, and then wiped the country’s land registry database. As a result, websites and official apps went offline, and the real-estate market was brought to a standstill. Notaries could not record new transactions, and citizens could not get proof that they owned land or property. What may sound like a technical incident quickly became a public service crisis.

The agency involved is Romania’s national cadastre and real estate authority, which manages records about land ownership and related documents. In many countries, these records are the backbone of the property market. They help people buy and sell homes, prove legal ownership, settle disputes, and support loans. When such a system stops working, the damage spreads far beyond the IT department. Buyers, sellers, banks, lawyers, and public officials all feel the impact. This is why attacks on public databases can have real economic and social effects within days.

Reports say the attacker got in by using valid credentials rather than by breaking through a highly technical barrier. That detail matters. It suggests the breach may have started with stolen login details, weak account protection, or poor control over privileged access. After entering the network, the attacker appears to have mapped internal systems, understood how they were connected, and then moved from one system to another. After the extortion attempt fell flat, the attacker allegedly wiped both systems and backups. If true, that shows planning, patience, and knowledge of how to cause maximum disruption.

There is also a small but important sign of resilience. Even though the attacker reportedly claimed to have deleted backups, the agency appears to have had an offline copy. Officials later said they were rebuilding the network from scratch. That process is slow and costly, but it can reduce the risk of hidden malware remaining inside the environment. In security work, recovery is not just about turning services back on. Teams must check what was accessed, what was altered, what was stolen, and whether the attacker still has a foothold. Restoring trust can take longer than restoring systems.

The incident also highlights a wider pattern. Romania is not the only country whose land records have been targeted in recent years. Similar agencies in several other countries have also been hacked. Land registries are attractive targets because they hold sensitive legal information and support essential services. They may also depend on legacy systems, complex internal networks, and a mix of old and new security practices. For criminals, that can be a tempting combination. A successful attack can create pressure quickly, which gives extortionists leverage over public agencies that need to resume services fast.

For governments and private organizations alike, the lesson is clear: prevention alone is not enough. Strong identity controls, backup separation, network visibility, and tested incident response plans all matter. So does preparing for the human side of a crisis, including public communication and coordination with legal and operational teams. This case is a reminder that cybersecurity is not only about protecting files. It is about keeping core institutions running when something goes wrong. When one system underpins ownership, payments, and legal certainty, taking it offline can send shock waves through an entire country.

A recent blog post by software engineer and founder Chip Weinberger challenges a famous idea in tech: “hardware is hard.” He wrote about building and selling Jamcorder, a MIDI recorder for pianos, and said the biggest surprise was that the hardware side was not the most difficult part. Jamcorder is a small device that automatically records what a person plays on a piano through MIDI, a standard that lets electronic musical instruments send performance information. According to Weinberger, the product has sold around 2,500 units so far and can support itself as a business. For him, that result already counts as a success.

What makes the story interesting is the contrast between expectation and reality. Before starting the project, Weinberger expected electronics, plastics, manufacturing, shipping, and parts shortages to create constant problems. Instead, he said the process was smooth. To refine production, he hand-assembled the first 500 units himself, and he said it took only four days. He kept waiting for a major surprise, such as a failed production run or sourcing trouble, but that did not happen. A possible tariff problem came close, yet overall the hardware process stayed on track. In his view, the saying that hardware is always extremely difficult is often overstated.

At the same time, Weinberger did not claim that every hardware product is easy. He stressed that Jamcorder was designed to be simple from the beginning. The printed circuit board, or PCB, uses only a small number of unique components. Most parts are off the shelf, meaning they are standard items that can be bought rather than custom-made. He also limited the assembly steps to keep the process straightforward. In the article, he mentioned design decisions such as cutting low-battery detection, ambient light detection, a power button, and even USB-C. These choices may sound unusual, but they reduced complexity and removed many things that could go wrong.

The founder argues that the real heavy lift was still the software around the device. He wrote that the project involved roughly 200,000 lines of code across firmware, the companion app, and manufacturing tools. Firmware is the low-level code that directly controls a device’s hardware. Developing all of that reportedly took more than three years and many long nights. In other words, the product may look simple on the outside, but a lot of invisible work sits under the hood. This is a useful reminder for engineers: physical products often depend on a large body of code, testing, and process design, even when the electronics seem minimal.

His main takeaway is that hardware is, to a large degree, “as hard as you make it.” That idea will probably resonate with many startup teams. A product becomes much harder when it adds special sensors, custom parts, difficult calibration, or large-scale manufacturing. It also becomes harder in markets with fierce competition and thin margins, such as smartwatches or cars. Weinberger is careful about these trade-offs. He does not say that hardware is easy in every case or at any scale. Instead, he suggests that founders should not be scared off if they can keep the design lean and protect their margins.

The post ends with practical advice for people who want to ship hardware successfully at medium scale. Weinberger 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. He also recommends working with Chinese assembly partners and suppliers and using platforms like Alibaba to find them. Another key point is financial discipline: aim for at least 70% gross margin and keep the company lean. Even readers who never build a physical product can learn from this approach. In both hardware and software, simplicity, margin protection, and careful scoping often decide whether a product can stand on its own feet.

Many developers remember a simpler web. You could write an HTML file, add some CSS, upload it, and your site was live. There was no build step, no long setup guide, and no huge list of packages. Over time, that world changed. Modern frontend development now includes build tools, component systems, package managers, testing tools, and many layers of abstraction. At first, this can look absurd. However, the main idea in David Poblador’s deep dive is that this complexity did not appear for no reason. Each new tool was created to solve a real pain point.

One of the earliest problems was simple: developers wanted to update part of a page without reloading the whole thing. In the late 2000s, browsers could do this, but the process was awkward and inconsistent. Different browsers behaved differently, and direct DOM manipulation was often messy. Libraries such as jQuery gained traction because they hid many of these differences. Suddenly, common tasks felt much easier. AJAX became mainstream, menus opened smoothly, forms could validate in place, and pages felt more interactive. For a while, this approach was enough.

But as websites started to act more like applications, a deeper issue came to the surface. The real problem was not only loading data without refreshes. It was keeping the screen synchronized with the application state. If a user changed one value, a developer might need to update several parts of the interface by hand. Miss one small detail, and the UI could mislead the user. This manual process became hard to maintain, especially as products grew. That is why declarative UI became such a turning point. Instead of writing every step, developers could describe what the page should look like for a given state, and the framework would handle the updates.

This shift brought clear benefits, but it also opened the door to new trade-offs. Once teams relied on frameworks and components, they also needed better ways to organize code, share logic, and manage dependencies. Tooling expanded because the job itself expanded. Teams were no longer building only documents with a bit of scripting on top. They were building complex interfaces that had to work across devices, support collaboration, and scale over time. In that environment, abstraction can be a lifesaver. At the same time, too many layers can leave beginners in the weeds before they build anything useful.

That is why modern frontend often feels like a double-edged sword. The ecosystem can protect developers from old browser bugs and repetitive work, but it can also create heavy setup, frequent churn, and steep learning curves. A beginner may wonder why rendering a simple button seems to require so much machinery. Critics argue that the industry sometimes overengineers basic tasks. Supporters answer that many of these tools are scar tissue from years of painful lessons. In other words, the complexity is often the result of practical fixes that piled up over time, not pure fashion.

An interesting part of this story is the suggestion that the industry may be circling back. After years of adding layers, many developers now want simpler tools, faster builds, and approaches that feel closer to the old web. Even so, the past two decades still matter because they explain why the current stack looks the way it does. For engineers, the lesson is not to memorize every tool. It is to understand the wound each tool tries to heal. When you see the historical context, the frontend landscape looks less like chaos and more like a long chain of reasonable responses to real problems.

A new guide from Hatchet looks at a problem many startups learn the hard way: Postgres can feel simple at first, but it becomes much harder to manage when traffic grows. The author says the guide came from real production battles over the last two years. It is aimed at engineers who know basic SQL and understand rows, tables, and indexes, but need practical advice for the moment when things start to go off the rails. Instead of reading the full manual during an emergency, teams often want a shorter survival guide that focuses on the most common causes of trouble.

One major message is that schema design matters early because it is difficult to change later. The guide suggests building a schema step by step. Start with a rough version of your tables and primary keys, then write the kinds of queries your application will need. That process can reveal whether a table will face heavy reads, heavy writes, or frequent updates to certain columns. Traditional normalization can improve structure, but it can also clash with speed and ease of use. In a startup, where teams move quickly, a perfectly clean design is not always the best fit. Sometimes a jsonb column is a practical compromise, even if purists dislike it.

The guide also returns to a familiar lesson: good read queries depend on more than adding a single index. Teams need to think about common filters, joins, and sorting. In Postgres, compound indexes can be very useful, especially when they line up with the ORDER BY used in queries. If those pieces do not match, the database may do extra work. The author also points out that writing performant joins is essential because many real applications need information from several tables at once. A query that looks harmless at low volume can become a bottleneck at scale.

For write-heavy systems, the advice becomes even more practical. Startups often focus on user-facing reads, but writes, bulk updates, and migrations can quietly bring a system to its knees. Connection management is another area where teams can get tripped up. Too many open connections can create pressure on the database, even before query performance becomes the main issue. The guide notes that ORMs are useful, but they can be a double-edged sword. They speed up development, yet some deeper optimizations are hard to express unless engineers break past the abstraction layer and write SQL directly.

A more intermediate part of the guide explains the query planner, described as one of the leakiest abstractions in Postgres. In simple terms, the planner decides how to run a query. Engineers may expect it to use an index every time, but that is not always the best path. Sometimes a sequential scan, or seq scan, simply makes more sense. Another warning concerns autovacuum, the background process that cleans up dead rows. Default settings can become a pain point in busy systems, and table bloat can grow if cleanup does not keep pace with writes and updates.

The guide also touches on advanced topics such as FOR UPDATE SKIP LOCKED, partitioning, and tricks for large table migrations. These are not everyday tools for every startup, but they matter once a system reaches a certain level of complexity. The broader lesson is that Postgres is powerful, yet success in production depends on understanding trade-offs rather than following one-size-fits-all rules. For startup teams, that means thinking about reads, writes, schemas, and operations as one connected system. As more companies rely on Postgres for core workloads, practical advice like this is likely to gain traction among engineers who want to stay out of the weeds and keep their systems stable.

A growing debate in AI is no longer only about which model is the smartest. It is also about how models are shared and who controls access to them. Some analysts now argue that China is moving ahead with a powerful strategy: releasing open-weight AI models that others can run, adapt, and deploy more freely. In contrast, many leading US AI companies keep their strongest models behind closed, paid services. This difference matters because the market may reward wide adoption and ecosystem growth, not just top performance in a benchmark.

The basic idea is simple. A model on its own may have only a limited moat, especially if users can switch providers without much trouble. In many engineering workflows, companies call models through interfaces that can be replaced fairly easily. If one vendor becomes cheaper, faster, or better for a task, customers may move. That means long-term value may sit less in the model itself and more in the surrounding enterprise services: contracts, support, security features, integration with internal systems, and tools that fit daily work. In this view, the model layer can become commoditized over time.

This is where China’s position becomes interesting. US export controls on advanced GPUs have made access to high-end chips harder for Chinese firms. There are also rules that limit sharing sensitive information with Chinese-hosted services in many situations. Together, these factors reduce China’s ability to compete in the same centralized, global service model used by some US companies. But they also create an incentive to lean into a different path. By releasing open-weight models, Chinese companies can turn a compute disadvantage into a distribution advantage, because developers and businesses can host the models in their own environments.

Supporters of this approach say open technologies often gain traction in infrastructure because they are more permissionless and portable. Users do not need to depend on one provider’s platform, pricing, or roadmap. They can tweak a model for a specific use case, run it where regulations allow, and connect it to local systems more directly. Open weights are not the same as full open source, because the training methods and full code may not be shared. Still, they lower barriers to experimentation and can spread quickly across sectors such as manufacturing, research, and business automation.

Another reason this strategy is drawing attention is that the performance gap may be narrowing. Reports suggest that some Chinese models from companies such as Moonshot and Alibaba are approaching the quality of top US systems while offering lower costs. Even before that, open-weight adoption had already been gaining momentum among startups. If strong enough models are available at lower cost and with fewer restrictions, many teams may decide that is good enough for real products. In fast-moving markets, being good enough, cheap enough, and easy to deploy can sometimes outweigh having the absolute best model.

Still, this trend is a double-edged sword. Open-weight models can accelerate innovation, but they also raise concerns about safety, misuse, and political influence. Critics worry that some models may reflect the views or limits of the governments and companies behind them. Others argue that closed models offer more control and accountability, especially for high-risk applications. The bigger picture is that AI competition is no longer just a race to build the most advanced model. It is also a race to shape the global ecosystem. For developers, enterprise architects, and policymakers alike, the key question is which approach will prove more resilient at scale.

OmniRoute is an open-source AI gateway that tries to solve a simple but growing problem: developers now have access to many AI providers, including free and low-cost tiers, but those options are scattered across different services and rules. According to its GitHub page, OmniRoute offers one endpoint for hundreds of providers and models. It also works with coding tools such as Claude Code, Codex, Cursor, Cline, OpenCode, and Copilot. The basic idea is clear. Instead of setting up each provider one by one, a developer can connect through a single layer and switch models more easily.

This matters because AI development is becoming more fragmented. A team may use one model for code generation, another for long-context reading, and a third for cheaper background tasks. Free tiers can be useful, but they often come with strict limits, changing quotas, or slower performance. That can turn experimentation into a time-consuming task. OmniRoute tries to smooth out that process by acting as a gateway between tools and many model providers. In practice, this means a developer may spend less time in the weeds of account management and request routing, and more time testing real workflows.

One of the project’s key features is quota-aware auto-fallback. In simple terms, if one provider hits a limit or becomes unavailable, the system can move the request to another option. For developers who rely on AI tools during coding sessions, that kind of continuity can be attractive. The project also says it uses compression methods to reduce token usage, which can lower costs and stretch limited free quotas further. If those savings work well in real use, they could be a strong selling point for individuals, students, and small teams trying to keep expenses under control.

The project’s appeal also comes from timing. As AI tools gain traction in daily development work, many users do not want to bet everything on one model vendor. They want flexibility, price awareness, and a way to compare results across models without rebuilding their setup each time. An open-source gateway fits that mood. It gives users a central place to manage access while staying relatively vendor-neutral. The GitHub repository has also attracted a large community, which suggests that the idea resonates with developers who want practical solutions rather than polished marketing promises.

Still, a tool like this is a double-edged sword. A gateway can simplify access, but it can also add another layer that must be trusted, maintained, and secured. When one service sits between users and many AI providers, questions come up about reliability, privacy, abuse controls, and long-term support. Free and cheap tiers are especially unpredictable, so performance may vary a lot. There is also a broader question about whether routing across many providers will remain easy as vendors tighten policies or change their interfaces. Convenience is valuable, but it does not remove operational risk.

Even so, OmniRoute points to a bigger shift in the AI ecosystem. Developers are no longer choosing only the “best” model in isolation; they are thinking about availability, price, limits, and workflow fit. In that environment, routing and fallback logic may become almost as important as model quality itself. Projects like OmniRoute show how the market is maturing: users want AI access that is flexible, resilient, and economical. The next thing to watch is whether such gateways can hold up at scale while keeping setup simple enough for everyday use.

Google has introduced three new Gemini models: 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber. The company says these releases are designed for teams that build AI agents in real products, not just demos. In practice, those teams usually care about three things at the same time: speed, cost, and stable performance. Google presents the Flash family as the sweet spot between quality and efficiency, especially for agentic workflows, where a model must reason through several steps, call tools, and return useful results without wasting tokens or time.

The main release is Gemini 3.6 Flash, which Google describes as its workhorse model. According to the company, it improves coding, knowledge work, and multimodal tasks while also using fewer output tokens than 3.5 Flash. That matters because token use has a direct effect on cost, and it also affects how quickly a system can finish a task. Google says 3.6 Flash can complete multi-step work with fewer reasoning steps and fewer tool calls. In simple terms, the model is supposed to get to the point more efficiently instead of producing long, unnecessary answers. The company also says the new model is cheaper per token than 3.5 Flash.

Google highlighted several benchmark results to support that claim. In coding-related tests, it reported higher precision and fewer unwanted code edits. It also pointed to gains in machine-learning research tasks, computer-use tasks, and knowledge work. Another point of emphasis was lower verbosity, meaning the model can answer in a more concise way. For developers building agents at scale, this is more than a style issue. If a model is too wordy, costs rise, latency can increase, and downstream systems may need to process more text than necessary. A more concise model can therefore improve both user experience and operational efficiency.

The second release, Gemini 3.5 Flash-Lite, focuses even more sharply on speed and cost-effectiveness. Google describes it as the fastest and cheapest model in the 3.5 class, and it says the model delivers very high output speed. This version seems aimed at cases where fast responses matter more than top-end reasoning power. That could include lightweight assistants, classification flows, or large-volume internal tools. In those settings, shaving off delay can make a visible difference. If an application handles many requests every minute, even small improvements in latency and price can add up quickly.

The most security-focused announcement is Gemini 3.5 Flash Cyber, which Google is pairing with its CodeMender code security agent. Here, the message is slightly different. Google is not simply saying that one model solves cybersecurity by itself. Instead, it stresses careful orchestration between the model and a broader agent infrastructure. That is an important point, because security work often requires multiple steps: reviewing code, checking context, applying policies, and deciding whether a finding is real or a false alarm. A specialized cyber model may raise the bar in this area, but the surrounding system still matters a great deal.

For the wider market, these announcements show where AI model competition is heading. It is no longer only about who has the biggest model or the highest score on a headline benchmark. Customers increasingly want reliable systems that can run at scale, control cost, and fit into production workflows. Still, there are trade-offs to watch. A cheaper and faster model may not always be the best choice for complex reasoning, and benchmark gains do not guarantee the same results in every business setting. Google also mentioned that Gemini 3.5 Pro is being tested with partners and that work on Gemini 4 is already underway. That suggests the pace of change remains intense, and buyers will need to keep an eye on practical performance, not just marketing claims.

Bento is a new kind of office suite that tries to put many work tasks into a single file. Instead of opening separate apps for slides, notes, layout, and simple interactive elements, users build everything in one place. The idea sounds simple, but it points to a larger shift in productivity tools. Many teams are tired of moving content between different programs, exporting versions, and fixing small design problems again and again. Bento’s approach is to reduce that friction and make a presentation file feel more alive, more portable, and easier to share.

From the source material, Bento Slides supports visual features that are usually associated with more specialized design tools. A full-slide image can become a full-bleed background, with text placed on top and a dark overlay, called a scrim, to improve readability. It also supports ambient motion, such as a slow Ken Burns drift effect, so a cover slide does not look dead static. Other effects include animated lines for flows or timelines, highlight motion along a path, and count-up effects for large headline numbers. In short, Bento is not just showing static pages; it is trying to turn presentations into smoother visual stories.

Another notable idea is that Bento treats the file as a container for more than slides alone. The source context mentions speaker notes that travel in the file, which suggests a stronger all-in-one philosophy. It also refers to keeping an element’s ID stable across slides so it can morph in place during transitions instead of suddenly appearing and disappearing. This may sound technical, but the user benefit is straightforward: objects behave more consistently, and presentations can feel polished without forcing people to work in the weeds of animation settings. That kind of design can lower the barrier for users who want motion without becoming motion experts.

This matters because modern office work is often fragmented. A team may write notes in one tool, build slides in another, create charts somewhere else, and then lose track of which version is current. A one-file model pushes back against that sprawl. It can also be useful for portability. If notes, visuals, transitions, and layout logic stay together, sharing becomes simpler and there is less room for assets to go missing. For people who present often, that convenience could gain traction quickly. It also fits a broader desire for tools that are easier to hand off between teammates and easier to revise under time pressure.

Still, this model is a double-edged sword. When one file holds many functions, that file becomes more valuable, but also more central. If the format is not easy to inspect, edit, or export, users may worry about lock-in. Rich motion and visual polish can also distract from content if teams go overboard. A self-audit checklist in the source material reflects this risk. It asks whether numbers should be charts, whether related slides should share IDs and use morph transitions, and whether the deck has too many fonts or colors. In other words, Bento seems aware that good presentation design is not only about adding effects, but also about restraint.

Looking ahead, Bento is worth watching as part of a wider movement in office software. Users increasingly expect documents to be interactive, visually strong, and easy to reuse across contexts. They also want fewer handoffs between tools. Bento appears to lean into that trend by combining layout, motion, and presentation logic in one package. Whether it can break into mainstream workflows will depend on how reliable, flexible, and shareable that package feels in everyday work. But even at this stage, the concept highlights an important point: the future office suite may not be a bundle of separate apps. It may be a single, portable artifact that carries much more context with it.

vocabulary_en? Actually exact key must be vocabulary, so correct below. Wait need strict JSON only. Fix structure.