fidzu : Planet Grep

Evolutie van twee bakken deze lente/zomer. Die kunnen goed tegen de hitte!

23 Jul 2026 8:07pm GMT

For the last few months my laptop has been the bottleneck in my own workflow. Not the CPU, not the RAM. The fact that it's a laptop.

23 Jul 2026 8:07pm GMT

I've been busy doing some OpenSearch upgrades and migrations the past couple of months, and I was tired of running curl with different parameters to get the default health and other OpenSearch statuses. Apart from that my muscle memory failed to get the right variety of parameters once in a while so I figured I just write a wrapper around curl that would do a bunch of these things easier for me.

23 Jul 2026 8:07pm GMT

We are halfway 2026 already so it is time to think about what you will be doing next February.

Start with blocking your calendar for 1-3 February . As usual we'll be meeting in Ghent for 3 days of Infrastructure Automation Geekery. It will be a fun mix of 2 days of conference with new and old communities, followed by a day of workshops hackathons and tutorials. You know you can't mis this.

23 Jul 2026 8:07pm GMT

You may have recently seen that MariaDB Server supports the DuckDB Storage Engine [1][2]. And that's great. After my first look at it, Roman created those 3 MDEVs with my suggestions: And he started working on it! If we also check the roadmap, we can see that the DuckDB Engine will bring support for the […]

23 Jul 2026 8:07pm GMT

As you may already know, there are many places where a MariaDB system variable can get its value. It can come from: And when several configuration files are involved, finding the effective source is not always obvious. Fortunately, MariaDB provides this information in INFORMATION_SCHEMA.SYSTEM_VARIABLES. Let's check this in action with max_connections. Checking the current value […]

23 Jul 2026 8:07pm GMT

When people hear "online schema change" in the MySQL and MariaDB world, many immediately think about pt-online-schema-change. And for good reasons: for years, changing a large table in production was one of those tasks that could ruin your day. Recently, I discovered that MariaDB includes a very useful hidden gem I completely missed: the ability […]

23 Jul 2026 8:07pm GMT

Reversing Transactions Directly from the Binary Log Some ideas never completely disappear. They remain somewhere in your brain, waiting for the right opportunity-or the right API-to come back. For me, recovering rows from the binary log is one of those ideas. More than ten years ago, I started experimenting with a simple question: If row-based […]

23 Jul 2026 8:07pm GMT

Have you ever modified a MariaDB configuration file, restarted the service, and immediately regretted it? You wanted to change: but accidentally wrote: One missing letter. That is enough to turn a perfectly healthy database server into a service that refuses to start. And of course, this kind of mistake never happens during a quiet maintenance […]

23 Jul 2026 8:07pm GMT

SQLite is fantastic. Really. For a developer starting a new project, it is difficult to find something easier: no server to install, no network configuration, no user management, no backup strategy to define on day one. You create a file, you open it from your application, and you are ready to store data. That is […]

23 Jul 2026 8:07pm GMT

Firefox has had native Tab Groups (since version 141) to help organize your browsing… and I love this feature! However, what a disappointment when I realized that once Firefox closed, the groups were lost! But hey, this is open source, isn't it? And Firefox easily supports extensions, so I am happy to announce lefred's GroupKeep […]

23 Jul 2026 8:07pm GMT

Apache Arrow Database Connectivity (ADBC) provides a standard interface for exchanging data between applications and databases using Apache Arrow. You can think of it as an Arrow-oriented alternative to traditional database APIs such as ODBC and JDBC. The important difference is that ADBC is designed around columnar data. Query results are returned as streams of […]

23 Jul 2026 8:07pm GMT

The Drupal Association is entering a new chapter. Tim Doyle is stepping down as CEO, and the Board has appointed Tiffany Farriss as interim CEO.

I am grateful to Tim for his leadership and his impact on the Drupal Association. He built a strong leadership team that helped guide Drupal through an ambitious period of innovation. That team is well positioned to continue supporting Drupal and its community.

Tiffany brings continuity and deep expertise to the Drupal Association. She has contributed to Drupal for many years and served on the Drupal Association Board for more than a decade, including serving on its Finance Committee. She helped organize DrupalCons and built a successful agency in the Drupal ecosystem. She understands our project, the Drupal Association's finances, and the realities our partners, contributors, and users face.

I have worked with Tiffany for many years. She is thoughtful, deeply committed to Drupal, and unafraid of hard questions. Although her title is interim CEO, she has the full authority and confidence of the Board, as well as my full support.

We expect Tiffany to serve for six to twelve months. During that time, she will focus on strengthening the Association's financial and operational foundation and preparing it for long-term leadership. Later in that period, the Board plans to launch a search for the next permanent CEO.

Turning innovation into momentum

Tiffany is stepping into the role at an important moment for Drupal.

Over the past few years, our community has done some of its most ambitious work. Contributors have continued to modernize Drupal Core. We launched Drupal CMS to make Drupal easier to adopt, introduced Drupal Canvas to rethink how people build, and rapidly advanced Drupal AI to change how people create and manage content.

We have also taken important steps toward marketing Drupal with the seriousness it deserves, so more organizations understand why it remains one of the most powerful and trusted platforms for building serious websites and web applications.

This progress was made possible by our contributors and the organizations that invest in Drupal every day. The Drupal Association's role is to support that work and help turn it into wider adoption, a stronger ecosystem, and more opportunity for Drupal businesses.

Sustaining Drupal's essential work

The Drupal Association operates much of the infrastructure the project depends on, from Drupal.org and our collaboration tools to the services that help keep Drupal secure.

Drupal's infrastructure alone costs roughly $3 million each year. Today, it is funded through DrupalCon revenue, partnerships, sponsorships, donations, donated services, and volunteer contributions. That model has supported Drupal for many years, but it is not durable enough for the scale of the work ahead.

This is a challenge shared by open-source stewards everywhere. The software may be free to download, but the infrastructure and stewardship that make it dependable are not free to provide.

Building a stronger Drupal Association

Our commitment to Drupal's infrastructure and community will not change. But supporting both well requires a stronger Drupal Association, and that may mean exploring new approaches. We will weigh the options carefully, guided by what is best for Drupal and the people who depend on it.

This work will not be easy, but our ambition is clear: make the Drupal Association more sustainable, help Drupal innovate faster, strengthen how we bring it to market, and better support Certified Partners.

As this work takes shape, we will be transparent about what we are learning, the choices we are considering, and what they could mean for the Drupal Association and the Drupal community.

Tiffany understands what makes Drupal special and what the community values most. She also has the experience and mandate to shape what comes next.

Every new chapter depends on people willing to step forward. I am thankful to Tim for all he has done, to the Association's staff for their dedication, and to Tiffany for taking this on. With their commitment, I am confident in Drupal's direction and excited about the work ahead.

23 Jul 2026 8:07pm GMT

In recent months, a number of Acquia customers have independently made the same strategic decision: to migrate hundreds of websites from WordPress and other platforms to Drupal.

Some of these sites will move to Acquia Cloud, our Drupal PaaS, while others will move to Acquia Source, our Drupal SaaS. Drupal CMS played an important role in these decisions by making Drupal more approachable to marketers and site builders.

Why are different organizations making the same choice? One key reason is the cost of CMS fragmentation.

A few months ago, a CMO told me that her team had purchased a new digital asset management system (DAM). The estimate to connect it to the organization's websites came back at nearly $100,000 and three months of work.

Why so much? The organization ran three CMS platforms: Drupal, WordPress, and Contentful. The DAM had to be integrated with all three. That meant not only three integrations, but also three sets of expertise, three rollout plans, and three ongoing maintenance responsibilities. One new capability had become three separate projects.

Organizations are under pressure to move faster and reduce costs. CMS fragmentation creates a recurring tax through duplicated integrations, security practices, governance policies, infrastructure, technical expertise, and more. It also fragments attention and makes it harder to share improvements across teams and websites.

Organizations pay that tax every day through higher operating costs and slower execution, not only when they introduce new capabilities. When it consistently slows their ability to improve digital experiences, it can become a competitive disadvantage.

Some of this duplication can be reduced by standardizing hosting and portfolio governance across multiple CMS platforms. That is valuable, but it addresses only one layer of the problem. Each CMS still has its own extension model, editorial experience, security considerations, and required expertise.

This fragmentation usually happens for understandable reasons. Teams often make technology decisions independently, and different sites can have genuinely different requirements.

A marketing team may need to launch a campaign site in days without involving developers, making SaaS solutions attractive. A team responsible for a high-traffic enterprise application with custom integrations may need the flexibility and control of an Open Source solution running in a PaaS environment.

Each decision can make sense for the individual project while creating significant duplication across the organization.

More than 15 years ago, I argued in a post about Acquia's product strategy that organizations should standardize on a common CMS while choosing the right operating model for each site.

Today, the case is even stronger. Websites depend on more integrations, digital experiences are more complex, and AI is becoming another shared capability that organizations need to deploy across their portfolios. With multiple CMS platforms, every new capability becomes harder and more expensive to deploy safely.

Standardizing on a single CMS lets teams reuse more of their design systems, security practices, integrations, and expertise across sites. Marketers get a more consistent way to create and manage content, while developers spend less time implementing the same capabilities on unrelated platforms.

But standardizing on Drupal does not mean forcing every site into the same architecture or operating model. Organizations can share a common CMS foundation while choosing a different balance of convenience and control for each site.

That is where Acquia Source and Acquia Cloud fit together.

Acquia Source provides the SaaS operating model. It is designed for teams that value speed and simplicity. Acquia manages the underlying platform, while marketers and site builders customize experiences through the user interface, reusable components, and supported integrations. Developers can extend sites through custom components, APIs, webhooks, and other supported tools without managing the Drupal codebase or installing arbitrary modules.

Acquia Cloud provides the PaaS operating model. It is designed for sites that need deeper customization and more developer control. Teams can build custom Drupal modules, use contributed modules, manage code through Git, run CI/CD pipelines, and integrate Drupal more deeply with other systems.

Both are built on Drupal. This gives organizations a shared foundation for skills, content practices, design systems, security, and integrations, while allowing each site to choose the right balance of speed, simplicity, flexibility, and control.

A site can begin on Acquia Source when speed and simplicity matter most. If its requirements later grow to include custom modules, deeper integrations, or more developer control, the organization can export its source code, database, and files and move to Acquia Cloud or another Drupal environment without adopting a different CMS.

I have been calling this "Open SaaS": the convenience of SaaS combined with the ownership and portability of Open Source. Organizations can choose a different operating model without leaving Drupal or surrendering control of their sites.

When organizations standardize this way, the economics change dramatically. We have helped some customers save millions of dollars each year by reusing shared capabilities instead of rebuilding them for different platforms.

The goal is not to operate every website in the same way. A campaign site and a mission-critical application require different levels of speed, flexibility, and control, but they do not need unrelated CMS platforms.

The goal is to create operating leverage across an organization's digital portfolio. Each site can use the operating model that fits its needs, while teams reuse investments in content, design, integrations, security, and expertise.

Then, when the organization adds a DAM, a personalization engine, an analytics platform, or an AI capability, teams can build on shared work rather than start over for each CMS. The result is faster execution, greater returns on digital investments, lower costs, and less risk.

One CMS foundation with multiple operating models makes that possible.

23 Jul 2026 8:07pm GMT

Years ago, I wrote about hiking the Pemi Loop. To my surprise, many people still read that post. I imagine them sitting at a kitchen table with a map spread before them, trying to figure out what the hike will actually feel like.

This post is for that same reader, with a new map spread across the table: New Hampshire's Presidential Range.

My friend Chris and I just spent four days hiking through the Presidentials, a rugged chain of peaks named mostly after American presidents.

The classic Presidential Traverse covers roughly nineteen to twenty-three miles (31 to 37 kilometers) and involves about nine thousand feet (2,700 meters) of climbing, depending on the route and which summits you include.

We traveled from hut to hut rather than carrying a tent. Our four-day itinerary included two full days on the trail, with shorter days at the beginning and end so we could drive to and from the mountains.

On paper, the distance and elevation gain look manageable. The numbers didn't capture the effort. Much of our route followed the Appalachian Trail across loose rock and exposed ridgelines, where the weather can turn quickly.

The thru-hikers we met called the Presidentials one of their favorite sections and one of the hardest. A mile here can feel like two or three on an easier trail.

Unlike the Pemi Loop, this was a point-to-point hike. We traveled south to north, beginning near Crawford Notch and finishing at the Appalachia trailhead in Randolph.

Because the trailheads are about forty minutes apart by car, we left ours at the finish and arranged a ride to the start. Four days later, when we emerged from the woods and found the car waiting for us, it felt like a small miracle.

Day 1: Up to Mizpah Spring Hut

Our first day was short, which suited us because we had driven up from Boston and did not start hiking until two in the afternoon. From the parking lot, you climb and keep climbing until eventually there is a hut.

On the way up, we passed a steady stream of hikers heading down, all of them looking pleased to be traveling in that direction.

My left quad started complaining almost immediately. My pack was noticeably heavier than Chris', thanks in part to the unreasonable number of snacks I had brought.

We reached Mizpah Spring Hut a little more than two hours later. If a short afternoon hike could leave my quad complaining, the next two days were going to be much harder.

There was nothing to do about any of it but eat and sleep, and the hut is built for exactly that. The accommodations are rustic: no showers, no heat, and no electricity for guests. What you get is a bunk, cold well water, composting toilets, a pillow, and several wool blankets. Guests are encouraged to bring a sleeping bag or liner, so we did.

Dinner improved my outlook. The portions were absurdly generous, and the pulled pork was some of the best I had ever eaten, although two hours of climbing may deserve some of the credit.

After dinner we played chess, and I beat Chris three times in a row. To keep it interesting, I removed my own queen as a handicap and beat him anyway. I mention this only because he will read this post.

The view from my bunk at Mizpah Spring Hut.

The huts pack you into bunkrooms with anywhere from six to a dozen strangers, and between Chris snoring and the general symphony of a shared room, I didn't sleep very well. The thin mattress left my shoulder and hip aching, and at one point my arm went numb. That is simply part of hut life, and it still beats sleeping in a tent.

A worn mirror, an old-school fly catcher, and an early-morning selfie.

Day 2: Pierce, Eisenhower, and the roof of the Northeast

Day two took us from Mizpah Spring Hut to Lakes of the Clouds Hut, following the high ridge of the Southern Presidentials. It was our first full day on the trail and our first sustained stretch above treeline.

We climbed Mount Pierce (4,310 ft) first, then continued toward the broad dome of Mount Eisenhower (4,780 ft). As we gained elevation, the trees thinned, shrank, and finally gave way to open rock. The trail rose into the wind, with the mountains unfolding around us in every direction.

Between Mizpah Spring Hut and Mount Pierce, the trail passed through a forest straight out of a fairy tale.

Between Eisenhower and our destination, we crossed Mount Franklin, which looks like a summit and feels like a summit but does not officially count as one.

The sign put Mount Washington 5.4 miles away. What it did not say was how difficult each of those miles would be.

By early afternoon, we reached Lakes of the Clouds, the highest and best-known of the Appalachian Mountain Club's huts. We dropped our packs, claimed our bunks, and set out for the summit of Mount Washington (6,288 ft). The climb added two and a half hours to an already long day, but with the summit just above us, we kept going.

Mount Washington bills itself as the home of the world's worst weather. In 1934, observers at the summit recorded a wind gust of 231 miles per hour, a world record that stood until 1996. It remains the strongest gust ever measured at a staffed weather station. People die on and around Mount Washington nearly every year, often after the weather turns faster than they expect. We, somehow, got sunshine and crystal-clear air, with views that stretched for more than a hundred miles.

After hours of hiking, we reached the summit of Mount Washington, where we found a weather station, satellite dishes, and tourists who had driven up. Sharing the highest summit with people who had simply driven there felt strangely anticlimactic.

The trail down from Mount Washington is a long scramble over broken rock. The small white building below is Lakes of the Clouds Hut, tucked beneath Mount Monroe, with Mount Eisenhower and Mount Pierce in the distance.

The weather spared us, but the climbing did not. Three four-thousand-footers in one day left their mark. By evening, my hiking shirt had grown salt rings from all the sweating. It was impressive, disgusting, and, with no showers at the huts, a problem for another day.

Lakes of the Clouds Hut looked peaceful from above, but the helicopter flying beside it was evacuating a hiker who had fallen ill after a difficult climb up.

At sunset, the mountains faded layer upon layer, from blue to gray, until the last ridges disappeared. Chris and I stood and watched, tired and happy, forgetting about our knees.

At Lakes of the Clouds Hut, sunset brought everyone outside, where they all took the same photo.

The bunkroom brought me quickly back to earth. The moment I opened the door, a wall of sweaty feet and damp shoes met me, thick enough to taste. The bunks were narrow and packed close together. Sometime in the night Chris gave up entirely and moved out of the room to sleep somewhere he could breathe.

Day 3: The northern peaks

This was the hardest day of the trip, and the best. We spent about eight hours on the trail, most of it above treeline, hopping from rock to rock. I had to watch every step. Mile after mile, the terrain kept us moving slowly and deliberately.

We went over the top of Mount Clay (5,533 ft), then climbed Mount Jefferson (5,712 ft), and passed Thunderstorm Junction, a huge cairn near Mount Adams where several trails meet.

Somewhere along the ridge I developed a couple of blisters, which I patched before they could take over. The heat asked for the same kind of upkeep: I drank three liters of water and took two electrolyte tablets, and I was still craving salt by dinner, when I dumped extra on my pasta shells.

Leaving Lakes of the Clouds, we rejoined the Crawford Path, which carries the Appalachian Trail toward Mount Washington. I stopped to take off my boots and treat my blisters before they got worse.

One of my favorite parts of the hike was meeting AT thru-hikers. Much of the ridge follows the Appalachian Trail, and many of them were already months into their journey from Georgia to Maine. They were friendly and much faster than we were. You could often recognize them by their strong legs, and sometimes by their strong smell, though after three days without a shower, I was hardly one to talk.

We reached Madison Spring Hut in the early evening. This time my bunk was at the top of a stack four beds high, which I started calling "the fourth floor." It was close enough to the ceiling that I learned not to sit up too fast. At my age, nature tends to call at least once a night. From the fourth floor, that meant logging extra vertical miles. By now, though, the snoring and thin mattresses barely registered.

Day 4: Down to the burger

The last day was a long walk down. We left Madison Spring Hut and followed the Valley Way Trail back into the trees and eventually to the car we had left days earlier.

On the way down, I realized I felt different from how I had at the end of the Pemi Loop. There, every mile had made me more tired and weaker. This time I was more tired but also stronger. Maybe it was the hut meals, the lighter pack, or the daily electrolytes. Whatever the reason, my legs were sore but moving better than they had on the first day.

Our timing was lucky. By evening, after we were safely off the trail, winds had reached gale force and hail was sweeping across the mountains.

We celebrated our escape the only sensible way: with burgers at Black Mountain Burger in Lincoln. Hut food is generous, but after four days it is not this. That burger tasted better than any summit we climbed.

The four-thousand-footers we climbed

New Hampshire hikers chase a famous list of forty-eight peaks over four thousand feet. In the years I have lived in New England, I have climbed quite a few of them.

To make the list, a mountain has to rise at least two hundred feet above the col, the saddle connecting it to its taller neighbor. That rule is why Mount Franklin and Mount Clay, both well over four thousand feet, do not count. They are really shoulders of bigger mountains.

Of the peaks we crossed, Franklin and Clay were also the only two not named for presidents. Benjamin Franklin and Henry Clay never reached the White House, and their mountains never reached the list. The two men who did not make it became the two mountains that did not count.

By the two-hundred-foot rule, we summited four: Pierce, Eisenhower, Washington, and Jefferson. We came up just short of Adams and walked past Monroe and Madison, which means the Presidentials still owe us a return trip.

When I think about the trip, I do not remember the blisters or the bunkrooms first. I remember standing next to Chris at sunset while the ridges faded from blue to gray, one behind another.

My legs are still sore, but I am already wondering where to hike next.

23 Jul 2026 8:07pm GMT

I kept running into the same small frustration. My site has its own search, but when I ask an AI agent whether I have written about a topic before, it searches Google instead of using my site's search directly. As a result, it often misses relevant posts that Google has not indexed.

At the same time, the web is gaining a new audience. In addition to people visiting pages, AI agents increasingly access a site's knowledge and tools directly.

That combination led me to add support for /.well-known/api-catalog to my site. A request to https://dri.es/.well-known/api-catalog currently returns:

{
  "linkset": [
    {
      "anchor": "https://dri.es/search/json",
      "service-desc": [
        {
          "href": "https://dri.es/openapi.json",
          "type": "application/openapi+json"
        }
      ]
    }
  ]
}

RFC 9727, an IETF Proposed Standard, defines /.well-known/api-catalog as a predictable location for discovering a site's public APIs.

The catalog is a small JSON document written in the Linkset format. It advertises my search endpoint and, in turn, links to an OpenAPI document that tells software how to use it.

The JSON endpoint at /search/json predates the catalog and powers my site's search. However, it was not documented or easy for software to discover. The catalog now makes it explicit.

The OpenAPI document at https://dri.es/openapi.json tells AI agents exactly how to call the endpoint and interpret the results. It removes the guesswork, reducing the time and tokens agents would otherwise spend figuring out how the API works.

In short, the API catalog announces that my search API exists, while the OpenAPI document explains how to use it. An agent can start with just my domain, check /.well-known/api-catalog, follow the link to the OpenAPI document, and learn how to search dri.es directly.

The feature has been live for a few months, but I am only now writing about it. In the meantime, I have logged every request to /.well-known/api-catalog and /openapi.json. The result so far: zero AI agents have used it.

I found the same problem when I analyzed llms.txt usage: the AI crawlers it was meant for never use it, so I never bothered implementing it.

Unlike llms.txt, the API catalog solves a problem I have, and I do not need to wait for industry adoption. I recently created an Agent Skill, a SKILL.md file that directs my agents to check the catalog and use my site's search API whenever they need information from dri.es.

My agents now search dri.es directly and find posts that Google misses. And if any AI agent adopts API catalog discovery, my site is ready.

23 Jul 2026 8:07pm GMT