eBPF: Kernel Superpowers for Devs

Tapping into the Linux Kernel’s Pulse

In the dynamic landscape of modern software development, where microservices, containers, and distributed systems reign supreme, the ability to observe, secure, and optimize system behavior at a granular level is paramount. Traditional tools often struggle to keep pace, introducing overhead or requiring intrusive modifications. This is where eBPF (extended Berkeley Packet Filter)emerges as a transformative technology, fundamentally changing how developers interact with the Linux kernel. It allows for the safe and dynamic execution of custom code within the kernel, opening up unprecedented possibilities for deep system introspection, enhanced security, and high-performance networking without altering kernel source code or loading traditional kernel modules.

Photo by Chris Stein on Unsplash

eBPF isn’t just a niche tool; it’s a foundational technology poised to redefine how we build, monitor, and secure applications from the ground up. For developers, understanding eBPF means gaining a direct line to the heart of their operating systems, enabling them to diagnose elusive bugs, enforce robust security policies, and build lightning-fast network services. This article will provide a comprehensive, developer-centric guide to eBPF, demystifying its concepts, offering practical steps to get started, exploring essential tools, and illustrating real-world applications that deliver tangible value in today’s complex development environments. Our core value proposition is clear: empower you, the developer, with the knowledge to harness eBPF’s unique capabilities for unparalleled visibility and control over your Linux-based systems.

Demystifying eBPF: Hands-On for Beginners

Diving into kernel-level programming might sound intimidating, but eBPF has been designed with safety and accessibility in mind, making it surprisingly approachable. For developers, the journey often begins with understanding the core concept: eBPF programs are small, sandboxed bytecode snippets that run in a virtual machine inside the Linux kernel. These programs can attach to various “hook points” within the kernel, such as syscalls, network events, function entries/exits, or tracepoints.

Here’s a step-by-step guide to your first interaction with eBPF:

1. Check Your Kernel Version:eBPF capabilities have evolved significantly. You’ll need a relatively modern Linux kernel, ideally 4.9 or newer for many features, and 5.x for CO-RE (Compile Once – Run Everywhere) and other advanced functionality.

   uname -r
   

   If your kernel is too old, consider upgrading your OS or kernel.

2. Choose Your Entry Point: bpftrace for Quick Wins: For beginners, bpftrace is an excellent starting point. It’s a high-level tracing language that compiles down to eBPF bytecode. It abstracts away much of the complexity, allowing you to write powerful one-liners.

   • Installation: On Ubuntu/Debian:

     sudo apt update
     sudo apt install bpftrace
     

     On Fedora/RHEL/CentOS:

     sudo dnf install bpftrace # or yum install bpftrace
     

     On Arch Linux:

     sudo pacman -S bpftrace
     

     You might also need llvm and clang for compilation dependencies, which bpftrace usually pulls in.

   • Your First eBPF Script with bpftrace: Let’s trace all execve (program execution) syscalls and print the process name and arguments. This is a fundamental operation for security and process monitoring.

     sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("PID %d executing: %s %s\n", pid, comm, str(args->argv[0])); }'
     

     Run this command in one terminal, then open another terminal and execute a few commands (e.g., ls, pwd, echo "hello"). You’ll see the execve calls captured in the bpftrace terminal.

     • Explanation:
       • sudo bpftrace -e '...': Executes a bpftrace script directly from the command line.
       • tracepoint:syscalls:sys_enter_execve: This is the hook point. It attaches the eBPF program to the kernel’s sys_enter_execve tracepoint, which fires just before an execve syscall.
       • { ... }: The eBPF program code block.
       • printf(...): Prints formatted output.
       • pid: Built-in variable for the process ID.
       • comm: Built-in variable for the command name.
       • str(args->argv[0]): Accesses the first argument of the execve syscall, casting it to a string. args is a context-specific variable provided by the tracepoint.

3. Basic eBPF Development Environment (BCC/Python): For more complex eBPF programs, the BPF Compiler Collection (BCC) is a robust framework that provides Python (and Lua) bindings for writing eBPF programs. This allows you to write the kernel-side eBPF code in a C-like syntax and the user-space interaction logic in Python.

   • Installation (Ubuntu/Debian example):

     sudo apt update
     sudo apt install -y build-essential git cmake libelf-dev llvm clang linux-headers-$(uname -r) python3-dev
     git clone https://github.com/iovisor/bcc.git
     mkdir bcc/build && cd bcc/build
     cmake ..
     make
     sudo make install
     cmake -DPYTHON_VERSION=3 .. # If you need Python 3 bindings specifically
     sudo make install
     sudo apt install python3-bcc # For a quicker, pre-built install (might be slightly older)
     

   • Simple BCC Example (Python): Let’s create a Python script that uses BCC to trace open syscalls.

     # save as opensnoop.py
     from bcc import BPF # Define the eBPF program in C
     bpf_text = """
     #include <uapi/linux/ptrace.h>
     #include <linux/limits.h> struct data_t { u32 pid; char comm[TASK_COMM_LEN]; char fname[NAME_MAX];
     }; BPF_PERF_OUTPUT(events); int kprobe__sys_openat(struct pt_regs ctx, int dfd, const char __user filename, int flags, umode_t mode) { struct data_t data = {}; data.pid = bpf_get_current_pid_tgid(); bpf_get_current_comm(&data.comm, sizeof(data.comm)); bpf_probe_read_user_str(&data.fname, sizeof(data.fname), filename); events.perf_submit(ctx, &data, sizeof(data)); return 0;
     }
     """ # Load the BPF program
     b = BPF(text=bpf_text)
     b.attach_kprobe(event="sys_openat", fn_name="kprobe__sys_openat") print("Tracing openat() syscalls... Hit Ctrl-C to end.") # Header for output
     print("%-10s %-16s %-20s" % ("PID", "COMM", "FILENAME")) # Process event from the perf buffer
     def print_event(cpu, data, size): event = b["events"].event(data) print("%-10d %-16s %-20s" % (event.pid, event.comm.decode('utf-8'), event.fname.decode('utf-8'))) b["events"].open_perf_buffer(print_event)
     while True: try: b.perf_buffer_poll() except KeyboardInterrupt: exit()
     

     To run this: sudo python3 opensnoop.py. Then open/access some files in another terminal (e.g., cat /etc/passwd, ls -l).

     • Explanation:
       • The C code defines an eBPF program that attaches to the sys_openat kprobe (a kernel probe).
       • It collects the process ID, command name, and the filename being opened.
       • BPF_PERF_OUTPUT(events); declares a perf buffer map for sending data from kernel to userspace.
       • bpf_get_current_pid_tgid(), bpf_get_current_comm(), bpf_probe_read_user_str() are eBPF helper functions to interact with kernel data safely.
       • The Python script loads this C code, attaches it, and then continuously polls the events perf buffer to print the captured data.

This hands-on approach with bpftrace and a simple BCC example provides a solid foundation. You’ve now written and executed custom code directly within the Linux kernel, a testament to eBPF’s power and relative ease of use.

Essential Tools to Conquer eBPF

To truly harness the power of eBPF, developers need a robust set of tools and resources. Beyond bpftrace and BCC, several other projects simplify development, debugging, and deployment of eBPF programs.

• BCC (BPF Compiler Collection):As seen above, BCC is more than just a bpftrace backend; it’s a comprehensive framework for creating eBPF tools. It offers Python, Lua, and C++ interfaces to write both kernel-side eBPF code (in a C-like syntax) and user-space control logic. BCC includes a vast collection of ready-to-use eBPF tools for various observability tasks (e.g., execsnoop, biosnoop, cachestat, tcpconnect). These scripts are invaluable for understanding common eBPF patterns and serve as excellent starting points for custom development.

  • Installation:(Refer to the previous section for detailed steps.)
  • Usage Example:sudo /usr/share/bcc/tools/execsnoop will show all executed commands across your system, a powerful debugging tool.

• libbpf and BTF/CO-RE (Compile Once – Run Everywhere):While BCC provides high-level abstractions, libbpf is a lower-level C/C++ library that’s becoming the preferred way for writing production-grade eBPF applications. libbpf, combined with BTF (BPF Type Format) and the CO-RE principle, allows you to write eBPF programs that compile once and run on different kernel versions, dramatically improving portability and maintainability. This eliminates the need for dynamic compilation on the target system, which BCC often requires.

  • Installation:libbpf is often included with your system’s clang and llvm installations or can be built from the kernel source tree (tools/lib/bpf). For development, you’d typically include libbpf as a dependency in your C/C++ project.
  • Usage:Projects like BPF-Portability/libbpf-bootstrap provide excellent templates for starting libbpf projects with CO-RE support, often involving a Makefile to compile your C-based eBPF program and link it with libbpf. This is generally a more involved setup than bpftrace or BCC’s Python interface but offers greater control and stability for production deployments.

• eBPF Foundation and Community Resources:

  • eBPF.io:The official website is an invaluable resource for documentation, tutorials, and a comprehensive overview of the eBPF ecosystem. It lists many projects, tools, and learning materials.
  • Brendan Gregg’s Blog and Tools:Brendan Gregg is a pioneer in performance analysis and has extensively documented eBPF. His blog contains numerous practical examples, deep dives, and an extensive list of eBPF tools. Searching “Brendan Gregg eBPF” is highly recommended.
  • GitHub Repositories:The iovisor organization on GitHub (home to BCC) and the cilium project (which heavily leverages eBPF for networking and security) are excellent places to find code examples and active development.

• IDE Support and Debugging: While there isn’t a dedicated “eBPF IDE,” you can get excellent support with standard development tools:

  • VS Code:With C/C++ extensions (like Microsoft’s C/C++ extension), you get syntax highlighting, autocompletion, and basic linting for your kernel-side eBPF C code.
  • bpf_debug:A command-line tool that can help debug eBPF programs by printing map contents, attaching to running programs, and more.
  • dwarfdump and llvm-objdump:For inspecting the generated eBPF bytecode and debugging information.
  • bpftool:A powerful utility included in the Linux kernel source (tools/bpf/bpftool) for managing eBPF programs and maps. You can list loaded programs, inspect their bytecode, check verifier logs, and more. This is crucial for understanding why your eBPF program might be rejected by the kernel’s verifier.
    • Installation:Often part of linux-tools-common or similar packages on your distribution.
    • Usage Example:sudo bpftool prog show lists all currently loaded eBPF programs. sudo bpftool prog dump xlat id <ID> can show the verifier’s translation of your eBPF program.

These tools, from high-level scripting to low-level library development, equip developers to tackle eBPF challenges at various complexities, facilitating everything from quick observability checks to building robust, production-ready kernel extensions.

From Theory to Practice: eBPF in Action

eBPF’s ability to safely run custom logic inside the kernel has unlocked a myriad of practical applications across observability, security, and networking. Here, we’ll explore concrete examples and discuss best practices.

Photo by Jürgen Jester on Unsplash

Practical Use Cases

1. Advanced System Observability and Performance Monitoring: eBPF excels at providing deep insights into system behavior without traditional overhead.

   • Network Latency Monitoring:Trace TCP connection states, measure RTT (Round Trip Time) at the kernel level, and pinpoint network bottlenecks. Tools like tcplife (from BCC) show TCP session lifetimes, helping identify transient network issues.

   • Application Performance Monitoring (APM):Instead of relying on application-level agents that consume resources, eBPF can trace syscalls, disk I/O, memory allocations, and CPU usage for specific processes or containers, providing a holistic view of application performance from the kernel’s perspective.

   • Function Latency Profiling:Attach kprobes to critical kernel functions or uprobes to user-space application functions to precisely measure their execution times, helping optimize hot paths.

   • Code Example (Disk I/O Latency with bpftrace): This script traces blk_account_io_start and blk_account_io_completion to measure the latency of disk I/O operations.

     sudo bpftrace -e '
     tracepoint:block:block_rq_insert { @start[args->rq->__data_loc] = nsecs; }
     tracepoint:block:block_rq_complete /@start[args->rq->__data_loc]/ { @latency = hist((nsecs - @start[args->rq->__data_loc]) / 1000); delete(@start[args->rq->__data_loc]);
     }
     interval:s:5 { print(@latency); clear(@latency); }
     '
     

     • Explanation:
       • tracepoint:block:block_rq_insert: Records the timestamp (nsecs) when an I/O request starts, using the request’s data location as a key in a map @start.
       • tracepoint:block:block_rq_complete: When an I/O request completes, it calculates the latency, stores it in a histogram @latency, and deletes the start timestamp.
       • interval:s:5: Every 5 seconds, it prints the histogram of I/O latencies and clears it for the next interval.

2. Robust Security Enforcement: eBPF’s ability to intercept and modify kernel events makes it ideal for building powerful security solutions.

   • Runtime Security:Implement dynamic security policies that inspect syscall arguments, network packets, and process behaviors. For instance, you can block specific syscalls for certain containers, prevent unauthorized file access, or detect malicious activity based on predefined patterns.

   • Container Sandboxing:Enhance container isolation by enforcing fine-grained network policies or restricting kernel capabilities more effectively than traditional methods.

   • Denial-of-Service (DoS) Protection:Write eBPF programs that identify and drop malicious network traffic patterns directly within the kernel network stack, before they reach user-space applications.

   • Practical Use Case (Blocking Unauthorized File Access): Imagine wanting to prevent a specific application (my_app) from writing to /etc/passwd. An eBPF program could attach to sys_openat (or kprobe:do_sys_open) and, if the comm matches my_app and the filename matches /etc/passwd with a write flag, return an error (-EPERM).

3. High-Performance Networking and Load Balancing: eBPF can inject custom logic directly into the kernel’s networking stack, enabling highly efficient and programmable network functions.

   • Custom Load Balancers:Projects like Cilium and Cloudflare use eBPF for highly efficient, programmable load balancing at Layer 3/4 and even Layer 7. It allows for advanced traffic steering and policy enforcement without the performance overhead of traditional proxies.
   • Firewalling and DDoS Mitigation:Dynamically filter packets based on complex rules, significantly outperforming traditional iptables for certain scenarios due to direct kernel execution and optimized lookup structures (eBPF maps).
   • Traffic Control:Implement advanced traffic shaping and prioritization directly at the network interface level.

Best Practices and Common Patterns

• Safety First (BPF Verifier):Always remember that eBPF programs run in the kernel. The BPF verifier is your guardian, ensuring programs are safe (no infinite loops, out-of-bounds memory access, uninitialized variables, excessive complexity). Learn to read verifier output for debugging.
• Minimalism:Write eBPF programs to be as small and efficient as possible. Kernel resources are precious. Do only what’s absolutely necessary in the kernel and offload heavier processing to user-space.
• Efficient Data Structures (BPF Maps):Use BPF maps for efficient communication between kernel and user-space, and for storing state within the kernel (e.g., hash maps, arrays, perf buffers, ring buffers). Choose the right map type for your use case.
• CO-RE for Portability:Prioritize libbpf with BTF/CO-RE for building production-ready eBPF applications to ensure portability across different kernel versions without recompilation.
• Incremental Development:Start with simple bpftrace scripts to prove a concept, then move to BCC for more complex logic, and finally to libbpf for robust, portable solutions.
• Error Handling:Always consider what happens if a bpf_probe_read_user or similar helper function fails. Handle potential errors gracefully.
• Resource Management:Ensure your eBPF programs don’t consume excessive CPU or memory. Monitor their performance impact carefully.

By adhering to these principles and leveraging the diverse toolset, developers can effectively utilize eBPF to build highly performant, secure, and observable systems, truly extending the capabilities of the Linux kernel.

Beyond Traditional Monitoring: How eBPF Stacks Up

When evaluating eBPF, it’s crucial to understand how it compares to existing approaches for system observability, security, and networking. eBPF isn’t always a replacement, but often a powerful enhancement or a superior alternative in specific scenarios.

eBPF vs. Traditional Kernel Modules

• Traditional Kernel Modules (LKM):These are compiled C code loaded directly into the kernel. They offer maximum flexibility but come with significant downsides:

  • Safety:A buggy LKM can crash the entire kernel, leading to system instability or security vulnerabilities. They bypass the kernel’s safety mechanisms.
  • Maintainability & Portability:LKMs are tightly coupled to specific kernel versions. They must be recompiled for every new kernel release, making deployment and maintenance a nightmare across diverse environments.
  • Deployment:Requires root privileges and careful management, often involving insmod/rmmod.

• eBPF:

  • Safety:The BPF verifier rigorously checks every eBPF program before loading, preventing dangerous operations (e.g., infinite loops, illegal memory access). Programs run in a sandboxed environment.
  • Maintainability & Portability (CO-RE):With CO-RE, eBPF programs are largely kernel-version agnostic, compiling once and running on various kernels without recompilation, simplifying deployment significantly.
  • Dynamic Loading:Programs are loaded and unloaded dynamically without kernel recompilation or reboot, often with lower overhead.

• When to use eBPF:Almost always preferred over LKMs for observability, security, and networking tasks due to superior safety, portability, and ease of deployment. LKMs are now mostly reserved for device drivers or extremely specialized hardware interactions where eBPF hooks aren’t sufficient.

eBPF vs. ptrace / LD_PRELOAD

• ptrace:A system call used by debuggers (like GDB) and tracing tools to observe and control the execution of another process. It works by pausing the target process, allowing the tracer to inspect/modify its state.

  • Performance:Extremely high overhead due to frequent context switching between the traced process and the tracer, and repeated pauses. Unsuitable for production monitoring.
  • Scope:Limited to user-space process interactions; cannot directly observe kernel internal events efficiently.
  • Security:Requires significant permissions, making it a potential attack vector if misused.

• LD_PRELOAD:A mechanism to load a custom shared library before any other libraries, allowing developers to override functions in dynamic link libraries (e.g., libc functions like open, read, write).

  • Performance:Lower overhead than ptrace but still involves user-space interception and function wrapping, which can add latency.
  • Scope:Limited to user-space functions. Cannot intercept kernel syscalls directly unless they are wrapped by a user-space library function.
  • Security:Can be used for malicious purposes (rootkits, code injection) as it allows arbitrary code execution within another process.

• eBPF:

  • Performance:Incredibly low overhead. Programs run directly in the kernel, minimizing context switches and leveraging kernel-native data structures and helper functions.
  • Scope: Unparalleled visibility into both user-space (via uprobes) and kernel-space (via kprobes, tracepoints, networking hooks). Can observe any event or data point within the kernel’s reach.
  • Security:Sandboxed by the verifier, making it far safer for dynamic program injection than LD_PRELOAD or ptrace.

• When to use eBPF:For high-performance, low-overhead, deep observability, and security enforcement at the kernel level. ptrace is best for interactive debugging, and LD_PRELOAD for user-space function hooking where performance is less critical or kernel access is not needed.

eBPF vs. Existing Tracing Tools (perf, sysdig, DTrace on other OS)

• perf:The standard Linux performance analysis tool. It uses kernel performance counters and tracepoints, some of which are implemented with BPF internally.

  • Strength:Excellent for general CPU profiling, hardware performance counters, and basic tracing. It’s built into the kernel and very mature.
  • Limitation:While powerful, perf provides pre-defined events and aggregated statistics. Custom, complex logic (e.g., tracking a specific state across multiple events, enforcing policies) is difficult or impossible.

• sysdig:Uses a kernel module to capture system calls and other kernel events, then processes them in user-space.

  • Strength:Provides a high-level, human-readable view of system activity and container events.
  • Limitation:Relies on a traditional kernel module (with its associated safety and portability concerns), and data processing happens in user-space, potentially adding overhead.

• eBPF:

  • Strength: Offers the ultimate flexibility. Developers can write any custom logic to process events in the kernel, store state in maps, and filter data before sending it to user-space. This means less data transfer and more efficient analysis. It can replace or augment many perf and sysdig functions with more tailored, performant solutions.
  • Customization:Create highly specific monitoring or security tools that are perfectly tuned to your application’s needs, something difficult with generic tools.

• When to use eBPF:When you need deep, custom, programmable insights into kernel behavior, complex correlation of events, or dynamic policy enforcement that goes beyond what static tools offer. For quick, high-level system checks, perf and sysdig still have their place. eBPF often underpins the next generation of these tools.

eBPF represents a paradigm shift, offering a safe, performant, and highly programmable interface to the Linux kernel. Its advantages in safety, portability, performance, and customizability make it the go-to technology for cutting-edge observability, security, and networking solutions in modern, distributed environments.

Embracing the eBPF Revolution: What’s Next for Developers

eBPF is not just a passing trend; it’s a fundamental advancement that is profoundly reshaping how we interact with the Linux kernel and, by extension, how we build and manage complex software systems. For developers, understanding and integrating eBPF into your skillset is becoming increasingly crucial, offering a unique competitive edge in a world demanding ever-greater visibility, security, and performance.

We’ve journeyed from its core concepts to hands-on examples, explored essential tools, and compared its capabilities against traditional methods. The key takeaway is clear: eBPF provides an unparalleled ability to extend the Linux kernel’s functionality safely and dynamically, unlocking new frontiers in system observability, robust security enforcement, and high-performance networking. From diagnosing elusive performance bottlenecks in microservices architectures to crafting custom runtime security policies for containerized applications, eBPF offers a direct, low-overhead pathway to the heart of the system.

For those eager to dive deeper, the eBPF community is vibrant and growing. Continuously learning from resources like eBPF.io, exploring the BCC tools, and experimenting with libbpf for production-grade applications will be invaluable. The future of eBPF holds even more promise, with ongoing advancements in tooling, language support (like Rust for eBPF), and broader adoption in cloud-native ecosystems (Kubernetes, service meshes).

As developers, embracing the eBPF revolution means empowering ourselves with the ultimate toolkit for building more resilient, performant, and secure software. It’s an invitation to elevate your understanding of system internals and contribute to the next generation of Linux-powered applications.

Diving Deeper: Common eBPF Questions & Key Terms

Your Burning Questions About eBPF Answered

1. Is eBPF safe to use? Will it crash my kernel? Yes, eBPF is designed with safety as a core principle. Every eBPF program must pass a rigorous validation process by the BPF Verifierbefore being loaded into the kernel. The verifier ensures the program will terminate, won’t access invalid memory, and won’t cause system instability. This sandboxing mechanism makes eBPF significantly safer than traditional kernel modules.

2. What programming languages can I use to write eBPF programs? The kernel-side eBPF code is typically written in a restricted C dialect, often compiled with clang into eBPF bytecode. However, user-space programs that load and interact with eBPF can be written in various languages, including Python (via BCC), Go (via libbpf-go), Rust (with libbpf-rs), and C/C++ (via libbpf).

3. Does eBPF require modifying the Linux kernel source code? No, absolutely not. One of eBPF’s greatest strengths is its ability to extend kernel functionality dynamically without requiring any changes to the kernel source code or recompilation. You write your eBPF program, and if it passes verification, the kernel loads and executes it at designated hook points.

4. What is the performance overhead of using eBPF? The performance overhead of eBPF is remarkably low, often measured in single-digit percentages, and sometimes even negligible. This is because eBPF programs run directly in the kernel, are highly optimized by the JIT (Just-In-Time) compiler, and can filter or aggregate data efficiently before passing it to user-space, minimizing data transfer overhead.

5. How is eBPF different from the original BPF? The “e” in eBPF stands for “extended.” The original BPF (Berkeley Packet Filter) was primarily designed for filtering network packets. eBPF significantly extends this capability, transforming BPF into a general-purpose, programmable virtual machine within the kernel. It supports more instruction types, more registers, a larger instruction set, and can attach to a much wider array of kernel hook points beyond just networking.

Essential Technical Terms Defined

1. eBPF (extended Berkeley Packet Filter):A powerful, programmable virtual machine inside the Linux kernel that allows custom code to be executed safely at various kernel hook points, enabling advanced observability, security, and networking.

2. BPF Verifier:A critical kernel component that performs static analysis on eBPF programs before they are loaded. It ensures the program is safe, won’t crash the kernel, terminates, and adheres to strict security rules, preventing malicious or buggy code from compromising the system.

3. BPF Maps:Kernel-resident data structures that allow eBPF programs to store state and communicate with user-space applications. Examples include hash maps, arrays, ring buffers, and perf buffers, enabling efficient data sharing and lookup operations.

4. Kprobes/Uprobes: Dynamic instrumentation points. Kprobes allow eBPF programs to attach to almost any instruction address in the kernel. Uprobesprovide similar functionality for user-space applications, enabling deep introspection into both kernel and application behavior without recompiling either.

5. BCC (BPF Compiler Collection):A toolkit and framework that simplifies the development of eBPF programs. It provides Python (and Lua) bindings for writing user-space logic and a C-like syntax for the kernel-side eBPF code, along with a rich collection of pre-built eBPF tools.

6. CO-RE (Compile Once – Run Everywhere):A principle and set of techniques (enabled by BTF) that allow eBPF programs to be compiled once and then run on different Linux kernel versions and configurations without needing recompilation. This significantly improves the portability and maintainability of eBPF applications.

Published on November 11, 2025