Reducing cross-AZ latency with the AWS Lambda metadata endpoint

Post Syndicated from Daniel Abib original https://aws.amazon.com/blogs/compute/reducing-cross-az-latency-with-the-aws-lambda-metadata-endpoint/

Customers use AWS Lambda to build applications that connect to stateful, latency-sensitive backends such as Amazon ElastiCache, Amazon Relational Database Service (Amazon RDS), and other services that expose per-Availability Zone (AZ) endpoints. For high availability, Lambda automatically provisions your execution environments across multiple Availability Zones in a Region. That resilience is transparent to your code. It also means that, until now, a function had no way of knowing which Availability Zone it was running in. When a function in one AZ connects to a resource in another AZ, the request crosses the AZ boundary, adding network latency and, in some cases, cross-AZ data transfer costs.

Lambda now exposes Availability Zone metadata through a metadata endpoint in the execution environment. Your function can now discover its AZ ID (for example, use1-az1) with an HTTP request. You can use that information to prefer same-AZ endpoints for downstream services, reduce cross-AZ latency, and implement AZ-aware resilience patterns such as AZ-specific fault injection testing. The feature is available at no additional cost in all commercial AWS Regions where Lambda is available. It works across all runtimes, including custom runtimes and container images, and is compatible with SnapStart, provisioned concurrency, and functions in a virtual private cloud (VPC). For more information about these compatibility details, see Using the Lambda metadata endpoint.

In this post, you will learn how the Lambda metadata endpoint works, how to retrieve the AZ ID using Powertools for AWS Lambda or by calling the endpoint directly, and how to apply the AZ ID to route to same-AZ resources for lower latency.

Why Availability Zone awareness matters

Consider a latency-sensitive read path: an API-backed Lambda function that reads from an ElastiCache cluster with a node in each of three Availability Zones. Lambda places your execution environments across those same AZs for resilience, but the placement is independent of where each cache node lives. Roughly two out of three invocations end up talking to a cache node in a different AZ than the one the function is running in.

A same-AZ round trip typically completes in single-digit milliseconds. A cross-AZ round trip adds latency on top of that, and on a hot read path executed thousands of times per second, those milliseconds compound into higher p99 latency and additional cross-AZ data transfer charges. Before this feature, avoiding cross-AZ traffic from Lambda required custom workarounds. These included embedding AZ hints in environment variables per function version, or inferring locality from IP ranges, none of which were reliable.

The same pattern appears across many of the VPC-based, AZ-scoped services your functions connect to. With Amazon RDS and Amazon Aurora, the writer instance lives in a single AZ, and each read replica lives in an AZ of its own. A read-heavy function that spreads its queries across replicas will, more often than not, reach a replica in a different AZ. Once your function knows its own AZ ID, you can direct reads to the replica that shares it. This keeps the hot query path in-AZ while still failing over to another replica when no same-AZ one is available. For more information, see Configuring Aurora read replica load balancing.

Amazon MemoryDB extends the same idea to a durable primary/replica topology: writes go to the shard’s primary in one AZ, while reads can be served from replicas spread across the others. Consider a high-volume, read-mostly path that tolerates eventual consistency, such as looking up reference data or serving cached lookups. Steering reads to the replica in the function’s AZ keeps the hottest part of the workload in-AZ, while writes continue to route to the primary wherever it lives. Because replicas lag the primary by a small, asynchronous delay, send any read that must reflect its own write directly to the primary rather than to a same-AZ replica.

Container platforms exhibit the same behavior when Lambda calls into them. If your function invokes a service running on Amazon Elastic Kubernetes Service (Amazon EKS) or Amazon Elastic Container Service (Amazon ECS), the pods or tasks behind that service are distributed across AZs, and by default a request can land on any of them. You can combine the function’s AZ ID with topology-aware routing to keep east-west traffic within the AZ. Examples include Kubernetes Topology Aware Routing or an internal load balancer with cross-zone balancing tuned. The same reasoning applies to a function calling a private service fronted by an internal Application Load Balancer or discovered through AWS Cloud Map: knowing the caller’s AZ turns “any healthy target” into “the nearest healthy target.”

The metadata endpoint removes that guesswork. Your function asks the execution environment where it is running, gets back a stable AZ ID, and routes accordingly.

Diagram showing a Lambda function reading from same-AZ resources and routing writes to a centralized primary using the AZ ID from the metadata endpoint

Figure 1: AZ-aware reads and centralized writes with the AWS Lambda metadata endpoint

How the metadata endpoint works

The metadata endpoint is a loopback HTTP API available inside the Lambda execution environment, accessible to both runtimes and extensions. Lambda automatically sets two environment variables in every execution environment:

  • AWS_LAMBDA_METADATA_API – The metadata server address in the format {ipv4_address}:{port} (for example, 169.254.100.1:9001). For more information about how this address and port are assigned, see Using the Lambda metadata endpoint.
  • AWS_LAMBDA_METADATA_TOKEN – A unique authentication token for the current execution environment, generated automatically at initialization. You include it in every metadata API request.

You retrieve metadata with an authenticated GET request:

GET http://${AWS_LAMBDA_METADATA_API}/2026-01-15/metadata/execution-environment

The response is a small JSON document:

{
  "AvailabilityZoneID": "use1-az1"
}

The Authorization header must contain a Bearer token (Authorization: Bearer <token>). This token-based authentication provides defense in depth against Server-Side Request Forgery (SSRF) vulnerabilities. Each execution environment receives its own randomly generated token, so a leaked or guessed URL alone is not enough to read metadata.

The response is immutable within an execution environment and returns a Cache-Control: private, max-age=43200, immutable header. We recommend that you cache the response and respect the TTL rather than calling the endpoint on every invocation. For SnapStart functions, the TTL is reduced during initialization so that clients refresh the metadata after restore, since a restored execution environment might come up in a different AZ. For more information, see Lambda SnapStart metadata behavior.

Retrieving the AZ ID with Powertools for AWS Lambda

The most direct way to consume the endpoint is with the Powertools for AWS Lambda metadata utility, available for Python, TypeScript, Java, and .NET. The utility caches the response after the first call and handles SnapStart cache invalidation automatically, so you don’t need to manage tokens, HTTP requests, or TTLs yourself. The following examples show how to use Powertools in each language.

Python

Install the Powertools package:

pip install "aws-lambda-powertools"

Use the metadata utility in your handler:

from aws_lambda_powertools.utilities.metadata import LambdaMetadata, get_lambda_metadata

def handler(event, context):
    metadata = get_lambda_metadata()
    az_id = metadata.availability_zone_id  # e.g., "use1-az1"

    return {"az_id": az_id}

TypeScript

Install the Powertools package:

npm install @aws-lambda-powertools/commons

Use the metadata utility in your handler:

import { getMetadata } from '@aws-lambda-powertools/commons/utils/metadata';

const metadata = await getMetadata();

export const handler = async () => {
  const { AvailabilityZoneID: azId } = metadata;
  return azId;
};

Java

Add the Powertools dependency to your pom.xml:

<dependencies>
    <dependency>
        <groupId>software.amazon.lambda</groupId>
        <artifactId>powertools-lambda-metadata</artifactId>
        <version>2.10.0</version>
    </dependency>
</dependencies>

Use the metadata client in your handler:

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import software.amazon.lambda.powertools.metadata.LambdaMetadata;
import software.amazon.lambda.powertools.metadata.LambdaMetadataClient;

public class App implements RequestHandler<Object, String> {

    @Override
    public String handleRequest(Object input, Context context) {
        LambdaMetadata metadata = LambdaMetadataClient.get();
        String azId = metadata.getAvailabilityZoneId(); // e.g., "use1-az1"

        return "{\"azId\": \"" + azId + "\"}";
    }
}

.NET

Install the Powertools package:

dotnet add package AWS.Lambda.Powertools.Metadata

Use the metadata class in your handler:

using Amazon.Lambda.Core;
using AWS.Lambda.Powertools.Metadata;

public class Function
{
    public string Handler(object input, ILambdaContext context)
    {
        var azId = LambdaMetadata.AvailabilityZoneId;
        return $"Running in AZ: {azId}";
    }
}

Calling the metadata endpoint directly

If you use a custom runtime, a container image, or prefer not to add a dependency, you can call the endpoint directly using the environment variables Lambda sets for you. The following example uses curl and jq to read the AZ ID:

# Variables are automatically set by Lambda
METADATA_ENDPOINT="http://${AWS_LAMBDA_METADATA_API}/2026-01-15/metadata/execution-environment"

# Make the request
RESPONSE=$(curl -s -w "\n%{http_code}" -H "Authorization: Bearer ${AWS_LAMBDA_METADATA_TOKEN}" "$METADATA_ENDPOINT")

HTTP_CODE=$(echo "$RESPONSE" | tail -1)

if [ "$HTTP_CODE" != "200" ]; then
  echo "Metadata request failed with status $HTTP_CODE" >&2
  exit 1
fi

# Parse the AZ ID
AZ_ID=$(echo "$RESPONSE" | sed '$d' | jq -r '.AvailabilityZoneID')

echo "Function is running in AZ ID: $AZ_ID"

Notice the configuration:

  • AWS_LAMBDA_METADATA_API: Lambda sets this to the metadata server address, so you never hardcode the host or port.
  • Authorization: Bearer ${AWS_LAMBDA_METADATA_TOKEN}: The token is required on every request. A missing or invalid token returns 401 Unauthorized.
  • GET only: The endpoint accepts GET requests. Any other method returns 405 Method Not Allowed.

When you call the endpoint directly, retrieve the AZ ID once during initialization (outside the handler) and cache it for the life of the execution environment, rather than calling on every invocation. If your function uses SnapStart, refresh the value after restore, because the restored environment might run in a different AZ.

Understanding Availability Zone IDs

The endpoint returns an AZ ID (for example, use1-az1), not an AZ name (for example, us-east-1a). Before you use it, it helps to read the ID itself. An AZ ID follows the pattern <region-code>-az<number>:

  • use1 is the shortened Region code, in this case US East 1 (us-east-1). Other Regions follow the same convention, such as usw2 for US West (Oregon) and euw1 for Europe (Ireland).
  • az1 identifies the individual Availability Zone within that Region. So use1-az1 reads as “Availability Zone az1 in us-east-1.”

This distinction matters. AZ IDs always refer to the same physical location across all AWS accounts, while AZ names might map to different physical infrastructure in each account in certain Regions. In other words, the us-east-1a name in your account and the us-east-1a name in another account can point to two different physical Availability Zones, but use1-az1 is the same physical zone in every account. There is no fixed mapping between a name like us-east-1a and an ID like use1-az1. AWS assigns names independently per account to balance resources across zones. That’s exactly why the endpoint returns the ID: comparing AZ IDs gives you a consistent, account-independent result about whether your function and a downstream resource share a physical Availability Zone. For more information, see AZ IDs for cross-account consistency.

If you need the AZ name (for example, for logging or for an API that expects a name), convert the AZ ID using the Amazon Elastic Compute Cloud (Amazon EC2) DescribeAvailabilityZones API. To call it, add the ec2:DescribeAvailabilityZones permission to your function’s execution role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:DescribeAvailabilityZones",
            "Resource": "*"
        }
    ]
}

Routing to same-AZ resources

Retrieving the AZ ID is only useful if you act on it. The following Python example shows the common pattern illustrated in Figure 1: look up the AZ ID once at initialization, select the connection endpoint that lives in the same AZ, and fall back gracefully when there is no same-AZ match.

from aws_lambda_powertools.utilities.metadata import LambdaMetadata, get_lambda_metadata

# Map each cache node to the AZ ID it lives in.
# Populate this from configuration (for example, environment variables or Parameter Store).
CACHE_NODES_BY_AZ = {
    "use1-az1": "cache-node-1.example.use1-az1.cache.amazonaws.com",
    "use1-az2": "cache-node-2.example.use1-az2.cache.amazonaws.com",
    "use1-az3": "cache-node-3.example.use1-az3.cache.amazonaws.com",
}

# Read the AZ ID once during initialization (cached across warm invocations).
AZ_ID = get_lambda_metadata().availability_zone_id

# Prefer the same-AZ node; fall back to any node if there isn't one.
CACHE_ENDPOINT = CACHE_NODES_BY_AZ.get(AZ_ID) or next(iter(CACHE_NODES_BY_AZ.values()))


def handler(event, context):
    # Use CACHE_ENDPOINT for your read path. When AZ_ID matches the node's AZ,
    # the request stays within the Availability Zone.
    return {"az_id": AZ_ID, "cache_endpoint": CACHE_ENDPOINT}

Notice the design choices:

  • Resolve at initialization: AZ_ID and CACHE_ENDPOINT are computed once per execution environment, not per invocation, so the metadata lookup and endpoint selection don’t add latency to the request path.
  • Always provide a fallback: If there is no node in your function’s AZ (for example, the service isn’t deployed in every AZ the function runs in), fall back to any available endpoint. Correctness must not depend on a same-AZ match being present.
  • Compare AZ IDs, not names: Because the endpoint returns AZ IDs, and services like ElastiCache and RDS expose the AZ of their nodes, you can compare the two directly for a reliable same-AZ decision.

Beyond latency-aware routing, the same AZ ID unlocks resilience testing. You can, for example, inject faults only in functions running in a specific AZ to validate that your application degrades gracefully during a simulated AZ impairment, without affecting traffic served from other AZs.

Best practices

Based on the endpoint’s behavior, keep these recommendations in mind:

  • Cache the metadata: The response is immutable for the life of an execution environment. Read it once at initialization and reuse it. If you call the endpoint directly, respect the Cache-Control TTL rather than requesting on every invocation.
  • Handle SnapStart correctly: A restored SnapStart environment might resume in a different AZ than the one it was snapshotted in. Refresh the AZ ID after restore. Powertools handles this invalidation for you automatically.
  • Ignore unknown fields: Additional fields might be added to the response in the future. Parse defensively and don’t fail if new fields appear.
  • Degrade gracefully: Treat same-AZ routing as an optimization, not a requirement. Always keep a working fallback path so your function stays correct when no same-AZ resource is available.
  • Keep the token server-side: The AWS_LAMBDA_METADATA_TOKEN is scoped to a single execution environment. Never log it or forward it outside the function.

Conclusion

In this post, you learned how the Lambda metadata endpoint helps your functions discover the Availability Zone they run in. With a single authenticated HTTP request, or one call through Powertools for AWS Lambda, your function can retrieve a stable AZ ID and use it to route to same-AZ resources, cutting cross-AZ latency and data transfer on hot paths, and to build AZ-aware resilience patterns like targeted fault injection. The feature works across all runtimes, integrates with SnapStart, provisioned concurrency, and VPC-enabled functions, and is available at no additional cost in all commercial AWS Regions where Lambda is available.

The key takeaway: if your Lambda function reads from or writes to AZ-scoped resources such as ElastiCache or RDS on a latency-sensitive path, resolve the AZ ID at initialization, prefer the same-AZ endpoint, and always keep a fallback. You get lower, more predictable latency with no change to how Lambda manages high availability for you.

To get started, see Using the Lambda metadata endpoint in the AWS Lambda Developer Guide.

Additional resources

Introducing Clef-omni with full multimodality, plus a faster Clef and a cheaper Clef-flash

Post Syndicated from Michelle Chen original https://blog.cloudflare.com/clef-faster-cheaper-multimodal/

Following last week’s release of Clef and Clef-flash, Cloudflare’s open-weight decision models, we decided to bring forth more gifts. Today, we’re releasing Clef-omni, which takes in audio and video input alongside text and image. We also cut the price of Clef-flash so it is now cheaper than Jev, and we made Clef faster.

Although the model game is still early for Cloudflare, innovation and iteration is in our DNA, and we apply these principles to everything we do. In fact, the story of Clef came together over the course of less than a week. We decided we wanted to do something in the decision model space on a Friday evening, trained the model over the weekend, and launched it on Thursday. Even with such a short timeline, we were able to ship performant, high-quality, open-weight models for the community — imagine what more we can do in the future.

For today, we’re excited to keep up the momentum with new additions and improvements to our Clef family of models. This is just the beginning, and we’ll continue to get better, faster, cheaper, and more innovative.

Clef-omni takes audio, video, image, and text input

Our new Clef-omni model is able to take audio, video, image, and text input. This changes the paradigm for decision models, which have been largely text-only since the debut of Jev from TypeSafe. With Clef, we supported images and video frame arrays, but Clef-omni is able to take in audio (wav or mp3) and video (mp4 or webm) alongside text and images.

Instead of setting up cascading pipelines of models that transcribe speech-to-text, or splitting audio and image channels from video, you can just call one model to make decisions across any modality. We are now one step closer to a model that is able to interact with the world as we experience it — through audio, visual, and textual communication, all in one.

Check out our developer docs for the new Clef-omni model. We also released the model open-weights on HuggingFace. For a quick start, here’s how you can send new modality inputs to Clef-omni:

Clef-omni expands our open-weight decision architecture to natively handle multimodal workflows. We built this on a Qwen3-Omni-30B-A3B-Instruct mixture-of-experts (MoE) foundation, where the model was already capable of processing text, imagery, audio, and video directly within a single pipeline. However, we adopt the primary comprehension backbone while discarding the text-to-speech output components. In production, Clef-omni executes a quick prefill pass across the complete payload, scoring all modalities and valid parameter options simultaneously.

Because we skip output token generation since Clef models are not Large Language Models (LLMs), we remove the overhead of transcribing or captioning incoming files. Media elements map straight into the unified sequence, where video and audio are synced with visual frames for joint processing. Clef-omni then pulls candidate values directly from internal embeddings using our two-stage attention routing: every valid option gathers key evidence from the input (regardless if they are buried in text snippets, visual elements, or audio streams) before field vectors cross-attend across the full context to compute confidence scores. We add a built-in lexical grammar that preserves option semantics, so that we can deliver fast, schema-constrained scoring across every input type.

We train the model with the same techniques as we did with Clef — freezing the Qwen3 backbone, training low-rank adapters (LoRA), and applying our standard post-training approach: combining label-smoothed cross-entropy loss with Brier score calibration. The result is a model that is resilient and designed to succeed regardless of schema variations, field ordering, and prompt structures.

This brings several core upgrades to the Clef model family. Calibrated, schema-bound decisions now seamlessly handle text, images, audio, and synchronized video in a single API call. It's also fast. Text-only decisions return in about 130 ms at the median, image inputs in about 150 ms, and audio clips in a few hundred milliseconds. Even a full 21-second video clip with sound is scored in about 1.5 seconds, all in a single API call.

Our benchmarking shows strong performance across benchmarks, even with new modalities and MoE architecture.

Benchmark

Clef-omni

Clef

Clef-flash

Jev

BFCL · case exact

98.2

98.47

98.76

95.75

ToolRet · nDCG@10

66.6

69.19

66.43

65.28

API-Bank · accuracy

92.7

91.93

93.11

88.19

Home appliances · case exact

69.3

82.95

97.73

52.27

When2Call · accuracy

63.3

72.37

65.58

80.97

BANKING77 · macro-F1

94.8

94.20

90.93

79.74

CLINC150+OOS · macro-F1

97.7

97.43

66.77

89.27

BRIGHT · nDCG@10

42.0

45.91

39.26

47.52

Amazon ESCI · macro-F1

57.8

57.48

57.39

55.21

PhishNChips · accuracy

73.2

79.60

75.05

62.55

We also benchmarked against the TypeSafe evals to show how Clef-omni performs.

Workflow

Metric

Clef-Omni

Clef

Clef-flash

Jev

Invoice processing

Exact actions

60.2

64.7

57.1

61.8

Invoice processing

Primary action

82.0

86.2

73.3

83.1

Customer service

Exact actions

71.6

76.3

77.0

76.0

Security incidents

Exact actions

61.7

62.9

61.7

61.7

Agent trace observability

Primary action

65.8

68.5

69.8

71.6

Clef-flash model is now cheaper

We heard your feedback — you want a decision model affordable enough to incorporate into any workflow. We’ve made a few optimizations and can now offer Clef-flash at cheaper prices. We want Clef to be able to make decisions that scale for you across all your agentic workflows, and now our pricing also incentivizes that.

We were able to optimize the model to the point where Clef-flash is now cheaper than Jev while still being performant and high-quality. Check out the developer docs for the most up-to-date pricing information at all times, including more detail on how image and audio modalities are converted to input tokens for pricing.

  • Clef-flash – originally $0.09 per M input tokens, now $0.038 per M input tokens
  • Clef – remains at $0.24 per M input tokens
  • Clef-omni – launched today at $0.15 per M input tokens

However, one trade-off we have to make in order to have cheaper pricing is to cut the context window of Clef-flash. The hosted version of Clef-flash now has a context window of 24k, instead of 64k as previously advertised. The model weights on Hugging Face are untouched and were trained to support a 256k context window should you choose to self-host it.

From our usage data, we see that only 0.24% of requests exceed 24k input tokens. Based on this data, we decided to make the call to drop the context window to 24k for Clef-flash in order to price it at a more accessible entry point. Our Clef model remains at a 64k context window, and we encourage folks with larger context needs to switch to Clef instead of Clef-flash.

Clef model is now faster

Speeds are also faster for the Clef model, with new optimizations to the hosted version of Clef on Workers AI. No new model weights are released because most of the optimizations we made are at the serving infrastructure layer, not materially to the model weights or architecture. Check out our new speeds below:

Input size

Before: median / p95 (ms)

Now: median / p95 (ms)

Median speedup

~800 tokens

262 / 438

152 / 351

1.7×

~3,400 tokens

616 / 777

305 / 531

2.0×

~16,000 tokens

2,721 / 3,250

1,635 / 1,805

1.7×

One of the optimizations we made was to move to SGLang for serving the model. We worked with the SGLang team and made pull requests to incorporate Clef (PR #42721), which will be released in SGLang 0.5.22. You can also self-host Clef since we released the weights, and the new SGLang launch commands are available on our updated Hugging Face repo as well as the SGLang cookbooks.

How are people using Clef?

At Cloudflare, we’ve had teams experimenting with Clef as a model that can help classify over general domains. The coolest thing about watching teams adopt Clef is that the capability to do detections and classifications have moved into the model layer, where it is accessible for anyone to start incorporating decision models into their use cases. Previously, even with zero-shot classifiers, the small models may not have been powerful enough to classify across any domain without further tuning. You might have needed to stand up a specialized machine learning team to help train over your particular domain, and gather a corpus of data in order to train a better model. Now, all you need to do is call a model to instantly parse through input data with precision.

A few highlights of how teams at Cloudflare are using Clef: Our public GitHub docs repo uses Clef to instantly detect and close spam issues. EmDash, our content management system, moderates plugin libraries for phishing. Our data loss prevention team is scanning data for potential personally identifiable information (PII) like government IDs. And our threat intelligence team is using Clef to help detect malicious domains.

Give it a try!

We’re excited to bring you more from the Clef family of models, including new modalities like audio and video, as well as making the model more accessible with cheaper pricing and faster speeds. Clef is fully Jev-API compatible and available via AI Gateway, so it is as simple as changing the model ID to try out Clef today. Check out our developer docs for more information.

Thank you for all the love and warm reception around Cloudflare’s first models — we are focused on bringing you more. Try out our Clef family of models, and tell us what you think.

Python 3.15 released

Post Syndicated from jzb original https://lwn.net/Articles/1099602/

Version
3.15 of the Python programming language has been released. Notable changes
in this release include the addition of the sentinel and frozendict built-in types,
the use of UTF-8 encoding by default, package
start-up configuration files, as well as improvements in the experimental
JIT compiler. See the “What’s new in Python
3.15” article for an in-depth look at new features in this release, and the
changelog
for a full list of changes.

[$] Adding kernel control-flow-integrity checking to GCC

Post Syndicated from corbet original https://lwn.net/Articles/1098670/

While many developers are struggling to keep up with the flood of
vulnerability reports, others are still focused on preventing those reports
from happening in the first place. Control-flow integrity (CFI) is the
term for preventing (or at least detecting) exploits that divert the flow
of control from its intended paths. At the 2026 GNU Tools Cauldron, Kees Cook
presented his changes to the GCC compiler suite to support forward-edge CFI
for the kernel.

„Сан Себастиан 2026“. Песъчинки и перли

Post Syndicated from Нева Мичева original https://www.toest.bg/san-sebastian-2026-pesuchinki-i-perli/

„Сан Себастиан 2026“. Песъчинки и перли

След като разказахме за лауреатите на Златна и Сребърни раковини от 74-тото издание на един от най-значимите европейски форуми за кино (18–26 септември), както и за испаноезичните попадения и единствения български филм в програмата му, сега ще обърнем внимание на

още една малка подборка от любопитни произведения.

„Див кон девет“ е подобен на предходните четири заглавия на своя автор Мартин Макдона – характерни актьори за персонажи чешити, колоритни сцени и реплики, готови за цитиране. Само дето е по-стегнат, по-гневен и по-нацелен от всичките. И тук както в „Баншите от Инишерин“ и „В Брюж“ действието се върти около приятелството на двама сурови и леко нелепи мъже, но този път насилието е директна заемка от реалността – не сценарийна фриволност, а черният хумор борави със заметени под килима на света ръбати истини.

Крис (Джон Малкович, купа „Волпи“ от Венеция) и Лий (Сам Рокуел във вихъра си) са агенти на ЦРУ в поредната страна, където Щатите ще събарят властта – Чили малко преди 11 септември 1973-та. Първият е смъртно болен и все по-откровен в разговорите си с непознати, а вторият се озовава пред задачата да го убие, възложена му от: а) самия Крис, който предпочита да си отиде от ръката на приятел, и б) шефа на ЦРУ (Стив Бушеми), притеснен, че Крис е на път да издаде важни тайни. Цветовете са ярки като в седемдесетарското кино; бардът Виктор Хара все още не лежи мъртъв със строшени пръсти, а изнася концерт; споменаваните безчинства на американците по планетата са достатъчно назад във времето, за да може шегите с тях да звучат не като безвкусица, а като призив за осъзнаване.

Чудесна идея е „Киномания 2026“ да бъде открита на 12 ноември именно с прожекция на „Див кон девет“. (Конят от заглавието е от свободно препускащите хергелета на остров Рапа Нуи, а деветката не е обяснена от автора: „Мисля, че ще я оставя да тъне в мистерия, докато не се сетя какъв да е отговорът…“)

„Сан Себастиан 2026“. Песъчинки и перли
„Сан Себастиан 2026“. Песъчинки и перли

Момент от „Просто илюзия“ на френския тандем Накаш и Толедано / Кристоф от „Корсетът“ на Луи Клиши

Друг много силен филм извън конкурсната секция очаквано се оказа „Просто илюзия“ (по заглавието на популярната песен на „Имаджинейшън“). Неговите сценаристи и режисьори Оливие Накаш и Ерик Толедано работят винаги заедно и винаги майсторски. И каквото и да разкажат, можем да бъдем сигурни, че няма да ни подведат – способни са да правят многопластови комедии и от най-неподатливата суровина. А тук тя никак не е неподатлива. „Просто илюзия“ е весело надникване в 80-те през компилация от личните спомени на авторите, в която едно 13-годишно момче прекрачва в нов етап от живота, докато узнава важни неща за света и за себе си. Актьорският състав е фантастичен; темпото, цветовете, обратите и диалозите носят радост. В Сан Себастиан Толедано каза нещо съществено:

Мултикултурализмът във Франция днес страда – всеки утвърждава идентичността си в противоречие с идентичността на другия. Но общество се гради чрез смесване… Истината е, че всичките ни филми говорят за това как да живеем заедно.

Анимационният „Корсетът“ (награда на журито в „Особен поглед“ на Кан и призове на журито и на публиката от фестивала на анимацията в Анси) има ред общи елементи с „Просто илюзия“ – възрастта на главния герой и споделеното му влюбване в по-отворено момиче, епохата, семейния състав и климат. Историята на Луи Клиши също е по спомени от детството – поради необходимостта, както твърди, „да изследва връзката баща–син по трагикомичен начин“ в контекст, където „свободните разговори са трудни, а чувствата – табу“. И е с гласа на собствения му син в ролята на Кристоф – фермерското момче, което, принудено да носи ортопедичен корсет, се отклонява от коловозите, типични за своите роднини и връстници, и става музикант… Останете в залата, докато текат финалните надписи, и ще чуете една кичозна дископесен от онази епоха – „Ураган“ на принцеса Стефани Монакска, – изпълнена от хор и орган. Прекрасен детайл, в който паметта и обичта превръщат песъчинката в перла.

„Сан Себастиан 2026“. Песъчинки и перли
„Сан Себастиан 2026“. Песъчинки и перли

„Плетеници“, режисьор Леа Нелсън / Чанинг Тейтъм и Мейсън Рийвс в „Джоузефин“ на Бет де Араужо

Също анимационен и пределно личен е „Плетеници“ на Леа Нелсън (Tangles – по едноименния комикс на канадката Сара Ливит), който деликатно, но с променлив успех говори за отношения майка–дъщеря, за алцхаймер в семейството и за доста от скритите и явните битки на онзи, който поема отговорността да се грижи за безпомощен близък. И все пак голямото американско постижение „от семейния фронт“ тази година сякаш беше „Джоузефин“ на Бет де Араужо (награда на публиката и награда на журито от „Сънданс 2026“).

Рано една сутрин осемгодишно момиченце излиза да спортува с татко си в парка и става свидетел на изнасилване. Престъпникът е заловен с помощта на бащата; един съкрушен жест на нападнатата жена засяда в паметта на детето; следва процес по осъзнаване, в който уж щадящият избор на възрастните да не коментират станалото само задълбочава травмата. Авторката е работила впечатляващо с малката си актриса Мейсън Рийвс и е дала на Чанинг Тейтъм една от редките му роли, в която той показва актьорство, не сексапил.

„На мен като дете мълчанието не ми помогна“, казва в The Moth Де Араужо за въпросния момент от собствената си биография и обяснява как животът ѝ завинаги се е променил след онзи ден. Част от тази промяна всъщност е и самият филм и си струва да се чуе целият ѝ разказ, за да се направят интересни наблюдения за пренасянето му на екран.

Завръщания

По повод удостояването на Вернер Херцог с награда за цялостно творчество „Доностия“ (баското име на град Сан Себастиан) в програмата беше включен и най-новият му игрален експеримент – „Кибано шопеле“. В него Руни и Кейт Мара играят двойка налудно усмихнати сестри в низ от еднакви рокли, които се движат и говорят като една. Понятията им за света са ту зрели, ту инфантилни, действията им – често с неясна полза. Двете са имали любовник, който ги е изоставил и когото те сега преследват (кибаното шопеле, както веднъж неволно го наричат)… Нещото е хем вдъхновено от реалността, хем неправдоподобно дори в зададените от Херцог фикционални рамки. Калка матастрофа.

„Сан Себастиан 2026“. Песъчинки и перли
Кадър от „Фиорд“, оператор Тудор Владимир Пандуру

Във „Фиорд“ на Кристиян Мунджиу (втора „Златна палма“ след тази за „4 месеца, 3 седмици и 2 дни“ преди 20 години) норвежците най-сетне идват и вземат нечии деца почти без да питат. Някъде по средата между реален спорен случай от работата на социалните служби и хипотетично упражнение ала „Ловът“ на Томас Винтерберг (но без крайностите му), филмът излага как правилата могат да се оплетат с предразсъдъците, но без да напомни достатъчно ясно защо вторите процъфтяват без първите и нанасят доста по-тежки поражения от тях. Проблем е също, че персонажите, особено тези на родителите, пестеливо изиграни от Себастиан Стан („Прясно“) и Ренате Райнсве („Най-лошият човек на света“), остават само маркирани, без осезаема личност. А това доста пречи на вчувстването в събитията. Интелектуално „Фиорд“ сякаш не доизрича, а емоционално – не довъвлича. Иначе съм напълно съгласна с думите на Мунджиу в Сан Себастиан:

Би било идеално убеждаването да става чрез образование, но когато нямаме търпение и просто се опитваме да се наложим, не стигаме доникъде… Добре е, напук на всички рискове, да обръщаме внимание и на аргументите на онези, които не ни е приятно да слушаме.

Най-голямото ми разочарование беше акламираният от критиката „Минотавър“ – завръщането на Андрей Звягинцев („Левиатан“, „Нелюбов“) след дълга творческа пауза и множество лични изпитания. Филмът не само беше отличен в Кан с Гран при и награда за саундтрака си, но и беше посочен за френско предложение за Оскарите. Говорим за римейк по „Невярната съпруга“ (недобре остарял сюжет на Шаброл от 1969-та за една изневяра, завършила с убийство), в който действието е пренесено в руски провинциален град, портрет на Путин виси на стената и е обявена частична мобилизация. Персонажите се движат като роботи с паднали батерии в среда с убити цветове, баналността на делника и на злото е всепроникваща, общуването е вяло и дори сексът не е секси, а избликът на чувства в пиковия момент е представен толкова равно, че не прилича на пик. Всичко сякаш скучае в „Минотавър“.

„Сан Себастиан 2026“. Песъчинки и перли
Кадър от „Наза“, режисьори Ювал Абрахам и Рейчъл Шор

Като пред видеоигра –

така се чувстват, по собствените им думи, някои от изпълнителите на „геноцида“ в Газа (също техен словесен избор, както впрочем и „чистка“). „Наза“ (награда на журито от 83-тата венецианска „Мостра“) е новото разследване на израелците Ювал Абрахам и Рейчъл Шор, които през 2024 г. заедно с палестинците Базел Адра и Хамдан Балал спечелиха Оскар и над 60 други награди с пълнометражния си дебют „Единствена земя“ – свидетелство за ставащото през последните десетилетия в Западния бряг, втората палестинска територия.

В новата си работа Абрахам и Шор се срещат очи в очи с около 25 представители на елитни военни и шпионски части в родината си и разговарят нощем по плоските покриви на телавивски сгради за онова, с което израелската държава реагира на чудовищното изстъпление на „Хамас“ от 7 октомври. А именно: системно („като във фабрика“) убиване, изселване и лишаване от храна и подслон на десетки хиляди, повечето от които – без никаква връзка с терористичния акт. Плюс медиен и правен саботаж на пострадалите, търсещи подкрепа в Хага и по света. „Ролята ми е чисто техническа“, чуваме. „Газа е пълна с трупове, ядат ги кучетата.“ „[В Газа] видях въоръжен човек само веднъж.“ „Трябва да вярваме в системата, иначе всичко ще се срине…“

„Наза“ е съкращение на иврит за незек агави – „съпътстващи щети“, така че в разговор за убитите покрай всеки заподозрян за връзки с „Хамас“ (роднини, съседи, случайни минувачи) не се казва „човек“, а „щета“. Не 20 или 30, или дори 500 „жертви“ или „души“ взривени дистанционно наведнъж, а „толкова и толкова наза“. Над 70 000 дотук. Как се решава кой да бъде подозиран ли? С изкуствен интелект, съставящ профил на всеки жител на Газа според телефонната му активност.

Гласовете и профилите контражур на събеседниците на Абрахам са променени дигитално, за да не доведат до разпознаването им, което, струва ми се, в крайна сметка е неизбежно – всички те са в такава позиция и знаят толкова, че едва ли се заблуждават, че ще им се размине. Това прави факта, че са решили да проговорят, още по-трагичен, самоунищожителен.

Докато въпросите и отговорите се редуват, камерата се отклонява от събеседниците и обхожда отдалеч прозорците на жилищните сгради наоколо. В рамките им попадат парчета обикновен живот, кротки жестове, телевизори. Много включени телевизори, които разнасят официалната версия: в Газа „всички са виновни“. И чак в края се вижда мъничко от самата Газа. Миг чист ад, за да сме пределно наясно за какво говорим, когато говорим за наза.

През ноември филмът ще бъде качен на сайта на The Guardian. Но може би е най-добре да се гледа в киносалон – заради невидимата подкрепа на другите, макар и непознати.

„Сан Себастиан 2026“. Песъчинки и перли
„Фалшивата Вечер“

Да бъдем свободни!

Фестивалът в Сан Себастиан беше закрит с „Фалшивата Вечер“ на Михаел Роскам. Преди прожекцията авторът припомни за отишлата си през юни Марджане Сатрапи, от чиито ръце на същата сцена в конгресния център „Курсаал“ през 2014 г. той получи наградата на журито за „Мръсни пари“. И пожела: „Да бъдем свободни като нея!“.

„Фалшивата Вечер“ възкресява един сюрреалистичен момент от Втората световна война: група съмишленици успяват да изработят фалшив брой от брюкселския ежедневник „Вечер“, в който профашистките текстове са сменени с бунтовно хумористично съдържание, и да го пласират на мястото на оригинала по будки и улици (вж. умната употреба на музиката! красивата печатарска машинария! неприкритото убеждение, че героизмът е делничен избор…). Странирането, отпечатването и разпространението на хартиено издание биха били трудоемка задача днес и явно, камо ли тогава и тайно. И все пак заговорниците се справят величаво и част от тях успяват дори да запазят живота си, не само достойнството.

Та нека да завършим с прочутите думи на Вонегът за смисленото групово действие:

Няма причина доброто да не побеждава толкова често, колкото и злото. Победата на каквото и да било е въпрос на организация. Ако има нещо от сорта на ангели, надявам се те да са организирани подобно на мафията.

[$] The state of systemd: 2026 edition

Post Syndicated from jzb original https://lwn.net/Articles/1099024/

At the 2026 All Systems Go!
conference, systemd maintainers Luca Boccassi and Zbigniew Jędrzejewski-Szmek
delivered the traditional “state of the project” session with an overview of the
systemd project’s accomplishments in the past year. That was followed by a
maintainer round table where Boccassi, Jędrzejewski-Szmek, Daan De Meyer, and
project leader Lennart Poettering fielded questions about systemd’s size,
health, and if it might replace Kubernetes. (It will not.)

Scaling RL rollouts with Firecracker on Amazon EC2 metal

Post Syndicated from Karsten Ploesser original https://aws.amazon.com/blogs/compute/scaling-rl-rollouts-with-firecracker-on-amazon-ec2-metal/

Modern reinforcement learning (RL) systems rely on thousands of rollout environments running in parallel. For large language model (LLM) training using Verifiable Rewards (RLVR) each rollout environment runs in a tightly isolated sandbox so state never leaks between environments.

The faster you can recycle sandboxes, the more training steps you can run per hour. That means higher rollout density per host which directly lowers your cost per step.

But density is a tuning knob with two failure modes. Push it too high and you hit a tail latency cliff. Play it too safe and you overprovision, leaving money on the table. The sweet spot depends on your instance type, workload profile, and how your training algorithm amplifies stragglers.

This post shows how to find that setting. We walk through the tunables that control density on Amazon EC2 metal. We then introduce labsweep, a measurement harness for mapping your latency and density curve. Throughout the post, we draw on lessons learned from production deployments with customers. The post is written for readers familiar with Kernel-based Virtual Machine (KVM), Firecracker, and container orchestration.

Background: EC2 metal, Nitro, and Firecracker

The AWS Nitro System offloads networking, storage, and security to dedicated hardware. Amazon EC2 instances expose a stable CPU topology you can inspect and pin workloads against. On Amazon EC2 metal, applications run directly on the underlying hardware.

Firecracker is a lightweight virtual machine monitor (VMM) designed for high density workloads. Each microVM boots quickly, runs its own Linux kernel, and has a small memory footprint.

Running Firecracker on Amazon EC2 metal combines direct access to underlying hardware with lightweight virtualization to support high density sandboxing. The key question is how far you can increase density before tail latency hurts the RL training loop.

Solution overview

The following diagram shows the reference architecture of a production RL sandbox node. This architecture serves as the foundation for the rest of the post. An Amazon EC2 metal instance runs a host agent that manages Firecracker microVMs, CPU pinning, non-uniform memory access (NUMA)-aware memory placement, and the warm pool used for dispatch.

Reference architecture of a production RL sandbox node showing host agent orchestration of Firecracker microVMs, resource preparation, warm pool management, workload dispatch, and telemetry collection on Amazon EC2 metal

The host agent runs as a DaemonSet on each Amazon EC2 metal node in the Kubernetes cluster. At startup, it discovers the CPU topology, creates per-microVM cgroup hierarchies, and orchestrates Firecracker jailer processes throughout the microVM lifecycle.

To reduce dispatch latency, the system maintains a warm pool of pre-booted microVMs. The host agent applies CPU pinning, NUMA-aware memory placement, and memory sizing on a per-microVM basis. labsweep identifies the combination of these settings that best balances dispatch latency, density, and tail latency for a given workload.

Prerequisites

  • Amazon EC2 metal instance (for example, we tested m8i.metal-48xl, m8a.metal-48xl, and m8g.metal-48xl).
  • Linux kernel 6.2+ (required for cgroup partition isolated mode).
  • Firecracker 1.7+ and the Firecracker jailer.
  • Go 1.22+ (to build labsweep).
  • AWS CDK v2 with Python 3.11+ (to deploy the accompanying stack).
  • Guest rootfs image (a builder script is included in the accompanying repository).

Scope note: this post focuses on CPU and memory placement for Firecracker microVMs. Other system variables including storage architecture (Amazon Elastic Block Store (Amazon EBS), local SSD) and network latency to the LLM endpoint were held constant to isolate the effects of CPU and memory placement.

Density tunables on EC2 metal

Your density ceiling depends on tunables whose availability varies by instance type. Not every knob exists on every instance type, and where a knob does exist its underlying mechanism can differ. The following table shows which tunables are available across the three metal instance types this post considers: m8i, m8a, and m8g. You can derive availability and mechanism from each instance type’s published CPU topology. The measured latency and throughput results later in the post currently cover m8i and m8a, with m8g results to follow.

Tunable m8i.metal-48xl m8a.metal-48xl m8g.metal-48xl What it does
Core pinning (cpuset.cpus) ✓ ✓ ✓ Dedicates a physical core to each microVM. Eliminates scheduler-induced tail latency
NUMA node confinement (cpuset.mems) ✓ ✓ ✓ (2 NUMA nodes on the 48xl) Keeps memory allocations local. The remote-node latency penalty varies by instance type. Check the NUMA distance matrix for your instance before pinning
SMT state (smt/control) ✓ (on/off) N/A (no SMT) N/A (no SMT) Doubles vCPUs when on. Workload-dependent: helps I/O-bound sandboxes, hurts compute-bound loops
L3 cache domain pinning ✓ (place workloads within NUMA-aligned cache domains) ✓ (24 domains, 8 cores each) ✓ (single shared L3 per socket. Pin on NUMA/socket boundary) Reduces cache contention for working sets above 4 MiB per microVM
cgroup partition (isolated) ✓ ✓ ✓ Removes kernel workqueue interference from pinned cores. Requires kernel 6.2+
Guest memory size ✓ ✓ ✓ Primary cost driver. Determines how much of your memory-to-core budget each guest consumes; M-series gives 4 GiB per vCPU

Key observation: different instance types expose different optimization opportunities. Among the instances evaluated, simultaneous multithreading (SMT) is available on m8i but not on m8a or m8g. Cache-local placement also differs by instance type: some present many discrete L3 domains, some a shared L3 that is effectively partitioned along NUMA boundaries, and some a single mesh-shared L3 per socket where the meaningful locality boundary is the NUMA/socket rather than a cache-domain count. Each instance type’s L3 layout is described in its own row of the table above and in its published CPU topology. As a result, the set of tunables and their impact on density vary by instance type. This is why measuring your own configuration matters more than following generic engineering best practice lists.

To make this concrete, here is what configuring one tunable looks like in practice: a cpuset pin that dedicates a single physical core to one microVM.

# Create an isolated cgroup for one microVM on core 12
mkdir -p /sys/fs/cgroup/microvm/vm-012
echo "12" > /sys/fs/cgroup/microvm/vm-012/cpuset.cpus
echo "0" > /sys/fs/cgroup/microvm/vm-012/cpuset.mems
# Launch the jailer into this cgroup
firecracker-jailer --id vm-012 \
  --exec-file /usr/bin/firecracker \
  --parent-cgroup microvm/vm-012 \
  --uid 1000 --gid 1000

From tunables to measurement: labsweep

These tunables interact in ways that depend on your workload and instance type. You cannot predict their combined effect from the specification sheet alone. You must measure the resulting system behavior.

labsweep is the test harness we built to do exactly that. It is a Go tool that:

  1. Discovers your host topology through sysfs (cores, NUMA nodes, L3 domains).
  2. Plans a matrix of configurations and densities.
  3. Launches jailed Firecracker microVMs at each density with bounded concurrency.
  4. Runs the workload in every guest concurrently and records per-microVM latency.
  5. Outputs raw samples, percentile aggregates, and variance data with full host provenance.

Methodology note: each experiment is performed at fixed microVM density. Dynamic churn is outside the scope of this evaluation.

The following command launches a typical labsweep run on an m8a.metal-48xl:

labsweep -configs A,B \
  -densities 90,120,150,186 \
  -repeats 5 \
  -resident-kib 131072 \
  -steps 14 \
  -write-kib 4096

Each run produces percentile latencies for every configuration, variance across repeated trials, and raw samples for recomputing any statistics. Results include full provenance (instance type, CPU model, kernel version, and Firecracker versions) making runs reproducible and comparable over time. If a microVM fails to respond, the harness reports failed samples instead of silently omitting them. This prevents failures from biasing the reported results.

The accompanying repository includes everything needed to reproduce these experiments: the labsweep harness, guest agent, rootfs builder, and the CDK application that deploys the complete stack on an Amazon EC2 metal instance (github.com/aws-samples/sample-firecracker-microvm-density-lab).

Results on representative workloads

Using labsweep we benchmarked workloads representative of the execution patterns in production RL systems: short-lived verification tasks (run a test suite, check the result), build-heavy tasks (compile and link), full 14-turn replayed RL episodes, and a synthetic compute loop as a control. Across all evaluated instance types, we collected more than 100,000 samples across 500+ configurations.

The 1.0x ratio rule

Tail latency remains flat as density increases until the workload reaches one microVM per vCPU. Beyond that threshold, p99 latency rises sharply over the next 15% increase in density before reaching a new plateau while median latency remains essentially unchanged. Expressing density as microVMs per vCPU rather than as an absolute microVM count makes this threshold portable across instance types. The latency cliff occurs at the same 1.0x density threshold regardless of instance size. Only the maximum number of microVMs scales with available vCPUs. The complete per-density measurements supporting this figure are provided in the appendix.

Rollout latency versus density (microVMs per vCPU): the p99 latency cliff occurs at approximately 1.0x density while median latency remains stable.

Core pinning reduces the tail latency for most real workloads

On the synthetic compute loop, core pinning made no measurable difference at equal density. On real sandbox workloads however, core pinning measurably tightened the tail: it reduced the p99/p50 ratio toward roughly 1.1x. The p99/p50 ratio measures tail spread by dividing the 99th-percentile latency by the median. Lower values indicate a tighter, more predictable latency distribution. The advantage grows with density, so pinning matters most where you are pushing the host hardest.

Why does this matter when choosing the right density? If you run Group Relative Policy Optimization (GRPO), every gradient step waits for the slowest rollout in the group. At a group size G=64, a p99 event affects ~47% of gradient steps. The effect becomes more pronounced as deployment density increases.

Density / cores G=8 G=16 G=64
0.94x 1.01x 1.01x 1.04x
1.04x 1.01x 1.03x 1.13x
1.15x 1.01x 1.04x 1.32x

Past the 1.0x ceiling the amplification climbs steadily, and by the time you are well above it a p99 event can dominate the group’s completion time. Median-focused dashboards do not surface this because the median stays flat. Core pinning keeps the p99/p50 ratio low across density, holding tail latency amplification far closer to flat than an unpinned configuration even at a group size of 64. Oversubscription can appear to provide spare capacity until tail latency amplification dominates training time. Set the density to the highest value where the amplification factor remains flat.

SMT depends on your workload

The optimal SMT setting depends on the workload:

  • I/O-bound workloads: SMT-on provides higher throughput. At high density it delivers 1.49x throughput because the vCPU count stays above the 1.0x ratio.
  • Compute-bound workloads: SMT-off produces more predictable tail latency, with a markedly tighter p99 spread than SMT-on.

Most RL sandbox workloads are I/O-bound, spending much of their time waiting on file operations, process creation, or git operations. For these workloads, keep SMT enabled. With SMT enabled, you can place more microVMs before reaching the 1.0x ratio, for higher density without crossing the latency cliff.

Configuration matters as much as hardware

Hardware selection is only one factor affecting performance. Configuration choices produce measurable differences. To isolate the effect of configuration, we compare identical workloads on the same m8i instance with SMT enabled and disabled. The results show that changing a single configuration parameter measurably affects peak throughput per host.

The table below shows how enabling and disabling SMT affects peak throughput across a representative set of RL workloads, expressed as the SMT-on to SMT-off throughput ratio. The workloads were selected to represent the major execution patterns encountered in RL systems. Collectively, they cover short-lived verification tasks, interactive sessions, and full RL episodes.

Workload Throughput gain from SMT
Verification task 1.14x
Build task 1.13x
Replayed RL episode 1.17x

The optimal SMT configuration depends on the density at which the workload is intended to run. With SMT enabled, the host exposes more vCPUs, which supports higher microVM densities before reaching the 1.0x microVM per vCPU threshold. This increases throughput at higher densities by delaying the onset of the tail latency cliff. At densities at or below one microVM per vCPU, SMT disabled delivers slightly better per-task performance and tighter tail latency. These results demonstrate that no single SMT configuration is universally optimal. The best choice depends on the target operating density. You should therefore determine the optimal configuration through measurement rather than assuming it in advance.

When memory becomes the limiting resource

We ran all experiments on M-series metal instances, which provide 4 GiB of memory per vCPU. At this memory-to-vCPU ratio, every workload we tested remained vCPU-bound. We exhausted vCPUs before memory. If your workloads require a higher memory-to-vCPU ratio, the bottleneck shifts from vCPUs to memory. In that case, a memory-optimized instance family may be the better choice. It provides more memory per vCPU but fewer vCPUs per host. As a result, the maximum sandbox density is lower. Consider this trade-off when selecting an instance family.

Reproduce these results on your own workloads

You do not need to take these numbers on faith. With labsweep, you can reproduce them on your own workloads. Clone the accompanying repository and deploy the CDK stack on the instance type you plan to run in production. Build a rootfs from your real workload. Sweep across densities below and above your expected level so you can see where expected performance drops off (the -densities flag in the preceding example is a reasonable start). Repeat each configuration a few times using the -repeats flag so you can see the variance, then read the p99/p50 ratio and the amplification table for your group size. Tune your system based on the curve you measure for your own workloads. That is more reliable than tuning to synthetic benchmarks.

Clean up

If you deployed the accompanying CDK stack for labsweep, tear down these resources when you are done:

  • Delete the CDK stack (cdk destroy).
  • Terminate any running Amazon EC2 metal instances.
  • Remove the guest rootfs images from Amazon Simple Storage Service (Amazon S3) (if uploaded).
  • Delete the Amazon CloudWatch log groups created by the harness.

Conclusion

Sandbox density on Amazon EC2 metal is determined by a small set of tunables whose optimal values depend on both the workload and the underlying instance type. Because those values vary across workloads, there is no single density setting or configuration that is optimal for every deployment. Instance type specifications give you a starting point but only measurement can identify the right operating point for your workload. labsweep is designed to make that measurement straightforward so you can optimize against your own production workloads.

Blog resources

Appendix

Full per-density measurements behind the tail-latency chart in “The 1.0x ratio rule.” Conditions: m8i, SMT off, 96 physical cores, config A (unpinned). Amplification columns give the GRPO group-completion factor (group max over rollout p50) at group sizes G=8, G=16, and G=64.

Density Density / cores Rollout p50 Rollout p99 G=8 amp G=16 amp G=64 amp
45 0.47x 7,768 us 7,857 us 1.01 1.01 1.01
90 0.94x 7,740 us 8,035 us 1.01 1.01 1.04
100 1.04x 7,740 us 8,601 us 1.01 1.03 1.13
110 1.15x 7,737 us 9,909 us 1.01 1.04 1.32
135 1.44x 7,743 us 15,601 us 1.03 1.20 2.01
186 1.94x 7,744 us 15,697 us 1.22 1.56 2.03

Let’s Encrypt moving to 64-day certificate lifetimes in 2027

Post Syndicated from jzb original https://lwn.net/Articles/1099588/

Let’s
Encrypt, the nonprofit that provides free TLS certificates for millions of
sites, has announced that
it will be moving to certificates with 64-day lifetimes on February 10,
2027:

This means that any certificate we issue or renew on and after that date will
have a 64 day validity period, and we expect the last 90-day certificate to
expire on May 11, 2027. We will not revoke valid certificates as a part of this
process.

This is the second stage of Let’s Encrypt’s plan, announced in 2025,
to move to 45-day certificate lifetimes as required by the the CA/Browser
Forum Baseline Requirements. In 2028, Let’s Encrypt will switch to 45-day certificates.

Security updates for Friday

Post Syndicated from jzb original https://lwn.net/Articles/1099587/

Security updates have been issued by AlmaLinux (bind, bind9.16, freerdp, glibc, kbd, mod_auth_openidc, openssl, perl-DBI, python3.12, python3.14, and tftp), Debian (rails and twitter-bootstrap3), Fedora (barman, cockpit, hcloud, libmodsecurity, nginx-mod-modsecurity, perl-DBI, sudo, and xorg-x11-server-Xwayland), Mageia (libxfont2), Oracle (bind9.18, firefox, kernel, nodejs24, perl-DBI, and vim), Red Hat (kernel, libreswan, opentelemetry-collector, osbuild-composer, rhc, and runc), SUSE (alloy, amazon-ecs-init, bind, busybox, distribution, emacs, ghostscript, glibc, GraphicsMagick, hauler, helm, helm3, jackson-annotations, jackson-core, jackson-databind, kernel, libpoppler-cpp3, libxtst, logback, nvidia-open-driver-G07-signed, perl-DBI, php-composer2, pi-coding-agent, portprotonqt, pvetui, python-hpack, python313-GitPython, and wpa_supplicant), and Ubuntu (apache2, bluez, libarchive, libde265, libgit2, libpng1.6, libxml2, linux, linux-aws, linux-aws-6.8, linux-aws-fips, linux-fips, linux-realtime, linux-realtime-6.8, linux-aws-7.0, linux-azure, linux-azure-6.8, linux-azure-fde, linux-azure-fde-6.8, linux-azure-fips, linux-azure-7.0, linux-azure-fde-7.0, linux-gcp, linux-gcp-6.8, linux-gcp-fips, linux-gcp-7.0, linux-hwe-7.0, linux-oracle-7.0, linux-gke, linux-gkeop, linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, linux-oracle, linux-ibm-6.8, linux-nvidia, and linux-oem-6.17).

Introducing on-demand CPU and memory profiling with flamegraphs for Workers and Durable Objects

Post Syndicated from Dominik Picheta original https://blog.cloudflare.com/workers-on-demand-profiling/

Understanding why an application is using more resources than expected, whether that is CPU or memory, can be challenging. Logs and aggregate metrics can only get you so far. Thankfully there is a better way: CPU or memory profiling can show you the exact function where your application is using CPU or allocating memory.

Today we are happy to announce support for CPU and memory profiling of Workers and Durable Objects. From the Workers Observability page, you can now request an on-demand CPU or memory profile of an active Worker, inspect it as an interactive flamegraph, and download the profile file for further analysis.

This method of profiling gives you a useful perspective into what your code is doing and how you can improve it in a real-world setting. That’s because the best way to understand your application is to profile it in production.

To try this on one of your Workers, you have a choice of using the CLI or the Cloudflare Dashboard. 

To use the CLI, make sure you have the cf package installed, then simply run:

To use the dashboard, head to the Cloudflare dashboard and then access the list of Workers on your account by navigating through Build → Compute → Workers & Pages.

Select your Worker and navigate to its Observability tab. You can then use the drop down to select “Flamegraph”:

You can then request both CPU and memory profiles for your Worker on this page. The duration determines how long the profiler should run for on your Worker. You can also select different versions of your Worker to be profiled. Your Worker needs plenty of traffic to be successfully profiled, so make sure you choose a version that has enough traffic.

Once you click the Capture Profile button, the profiler will run for the duration that you have selected, and you will then see a flamegraph representing the results of the profile being rendered. Each rectangle in the flamegraph represents a function call, with the width representing the amount of CPU time or memory being used by that function. You can click on different functions to focus on and hover to see more details about them:

Don’t be afraid to capture a couple of profiles, then look for the widest functions to determine what is using the most resources in your Worker. You might also find that the table view is useful to get a quick sense of which functions are most commonly seen in the profile.

If your Worker is implemented in TypeScript, then you should make sure that you have source maps enabled for your project, otherwise your profile may show obfuscated function names that aren’t easy to understand.

We have already seen multiple teams at Cloudflare using CPU and memory profiling to identify opportunities for optimizing memory and CPU usage, fixing out-of-memory (OOM) errors, and improving performance. Below are some examples of this.

Using CPU profiling to find optimizations

Let’s look at a real example of how you can use CPU profiling to optimize your Workers. We will look at a CPU profile of the Worker that implements the R2 binding. This Worker receives a lot of traffic and so eliminating even the smallest amount of wasted CPU cycles can have a massive impact on its performance.

We set up the profiler to capture CPU traces, with a duration of 50 seconds. Once we received the rendered profile, we saw this:

As mentioned previously, the widest boxes are those which are using up most of the CPU time. Some of them aren’t surprising, for example decryptBlock is R2 decrypting object data on the way out, and fillResponse is just moving bytes. There weren’t any clear ways to optimize these functions.

As some of the boxes are less visible, it can be a good idea to take a look at the table view. Sorting by Samples points us at genericR2JsonReplacer:

This function represented over 5% of the CPU time, but what caught our attention was the function calling itself recursively. This looked like wasted work, and it was.

Even though the replacer was being called by JSON.stringify on every node in the JSON tree, the replacer itself was also walking the tree. This meant that a value nested five levels deep was processed five times. Fixing this enabled us to eliminate the duplicate work and make the genericR2JsonReplacer function 2.7x faster.

The second candidate in the profile that we looked at was a duplicate call to metrics.

When looking at the code, we saw something close to this:

The metrics call was heavy enough that just one call represented 1% of the CPU time in the profile. So storing the result of the first call in a variable and then not calling it again saved us a fair chunk of CPU time.

How we used Worker profiling internally to fix memory problems

Internally we had a Worker with a memory problem. P999 memory sat around 133 MB against the 128 MB Worker memory limit. This caused the Worker to be evicted frequently with an “Exceeded Memory” error.

The image above shows a screenshot of the “Errors by invocation status” graph, with the number of “Exceeded Memory” errors clearly dropping as a result of the fixes identified through profiling.

What was hard to work out was what was causing these errors. The errors and metrics pointed at memory as the source of the problem, but it didn’t explain which part of the code caused it.

The team took a heap profile of one of the Workers running in production and opened it with pprof. They saw that their Prometheus code accounted for roughly 66.7% of allocations in the profile. This code was supposed to be disabled, but enough of it was still running that it created a problem. Because it was instrumenting a lot of the code paths in the Worker, it ended up using a lot of its memory, even though the collected data never actually left the Worker.

This code wasn’t suspected as a culprit of the memory issues, because it was thought to have been disabled. The profiler showed that the code was only partially disabled, with the memory cost still being paid as if it was fully enabled.

The team removed the Prometheus code path completely. This quickly improved the memory usage of the Worker:

Percentile

Before (MB)

After (MB)

P50

70

54

P90

94

79

P99

113

97

P999

133

118

This gave the P999 about 10 MB of headroom below the 128 MB limit.

Following a profiling request to the edge

Workers have supported local profiling through Chrome DevTools for a while, but it has not been possible to start a profiling session on Workers running in production. While profiling a Worker locally is useful, the Worker does not receive the same kinds nor number of requests as one does in production. So how do we profile a Worker or a Durable Object running there?

One of the best features of Workers is that their requests are routed to the data center that is nearest to the requesting client. This reduces latency, but it does mean that Workers must be replicated across different data centers and metals (physical servers). In addition, when a Worker is receiving a lot of requests in a particular data center, it can be replicated in a particular metal multiple times to handle all the traffic.

Durable Objects add another layer of indirection: they can be placed dynamically and can move.

This and a few other features of Workers means that before we can start a profiling session, we need to first answer a few questions:

  • Which version does the developer want to profile?
  • In which data center has that version run recently?
  • Is the Worker’s isolate still loaded in that data center?
  • Does the isolate belong exclusively to the requesting account?
  • For a Durable Object, where is the exact live primary actor?

A few of these questions are answered by the client making the profiling request. In most cases this will be the dashboard, but you can also send these requests yourself (or have your coding agent do it for you). An example request might look something like this:

Notably, this specifies both the script name and version that should be profiled as part of the request URL.

Right now, a new isolate is not started to produce a profile, because the goal is to observe real production execution. This means that if your Worker is receiving very little traffic, you may find that it is hard to profile. So it’s important you pick a version of your Worker that is deployed.

Profiling an isolate without stopping the Worker

A profile is useful only if the application can continue to execute while samples are collected. The Workers Runtime therefore holds the isolate lock only for profiler lifecycle operations. For a CPU profile, the process looks like this:

  1. Acquire the isolate and its lock.
  2. Create a V8 CPU profiler and begin sampling at a one millisecond interval.
  3. Release the lock so normal requests can run.
  4. Wait for the requested duration.
  5. Reacquire the lock and stop profiling.
  6. Release the lock and serialize the result outside the critical section.

Holding the lock through the duration of the profile would prevent JavaScript execution from continuing, which would make the profile useless.

Durable Objects

Durable Objects are different from Workers. Regular Workers are stateless: no one Worker is special or different from the rest, and we pick a running isolate of the requested Worker at random. Durable Objects are stateful, and they have a name. That provides us with the very helpful ability to grab a profile of a specific isolate and a specific object anywhere in the world. When profiling a Durable Object, you can choose by name which object to profile. The runtime will then route the profiling request to the right metal that owns the specific actor and provide a profile of the specific isolate running that object.

What’s next?

On-demand profiling is just the start. It enables you to explore your Workers performance in ways that have not been possible before. But it does have some limitations worth noting:

  • You must explicitly start the profiling session. This can mean that you miss important time periods in which your Worker is misbehaving, and where you would like to see a profile to understand what went wrong.
  • The memory profiler can only show you allocations that occurred during the profiling window. So if your Worker is allocating a lot during start-up, you will not see it.

In order to resolve this we are already working on something new: continuous profiling. The idea is that we will capture profiling samples for your Worker automatically, so that you can simply explore the profiles in the dashboard. This should make it easier to capture more rare events.

To learn more about profiling in Workers, including the feature presented in this blog post, check out our documentation.

Special thanks to the Workers Control Plane team and the Cloudflare Observability Platform team, in particular William Perron, who helped with dashboard implementation for this project.

„Сан Себастиан 2026“. „Трябва да се живее!“

Post Syndicated from Нева Мичева original https://www.toest.bg/san-sebastian-2026-tryabva-da-se-zhivee/

Любимецът на зрителите

„Сан Себастиан 2026“. „Трябва да се живее!“

стана ясен още на четвъртия ден. В ежедневно публикуваната във фестивалния вестник класация

„Черната топка“ литна напред с оценка 9,4 от 10 и вече нямаше не само кой да го изпревари, но и да го доближи.

„На първия ни спектакъл в залата имаше 15 души“, казаха авторите му, познати с общия прякор Лос Хавис (Хавиер Амброси и Хавиер Калво, театрални и телевизионни режисьори), докато на закриването на сансебастианския фестивал приемаха наградата на публиката. Същия уикенд филмът им – който спечели приза за режисура в Кан през май, а през септември взе най-голямото отличие в Торонто и беше избран да представлява Испания на Оскарите – тръгна по испанските кина и с над 600 000 зрители отвя блокбастъра „Одисея“.

„Черната топка“ e „любовна история“, разхвърляна в три исторически момента (1932, 1937 и 2017 г.) и куп стилове и настроения. В нея има и впечатляващи визуални попадения, и страхотна игра на епизодици, и средняшко присъствие на водещи персонажи, и любопитни хрумвания, и досадни пренавивания. В двата часа и половина зрелище ще се намери по нещо, което да зарадва и да подразни мнозина: я сърцераздирателната сцена с детето, което поздравява по фашистки, или шеметното камео на Пенелопе Крус, я палуващите войници, разголени като в кадър от „Зулендър“, или неубедителната главна роля на самоукия музикант Алваро Лафуенте.

„Черната топка“ е заглавието на последната, недописана пиеса на Федерико Гарсия Лорка, чиито четири начални страници са онагледени в най-ранната сюжетна линия на филма – членовете на малко затворено общество в Гранада гласуват с топки дали младият Карлос да се присъедини към тях. Белите са „за“, а черните – „против“ и наброяват много повече, понеже Карлос е гей в хомофобски времена. Втората сюжетна линия „инсценира“ по-скоро волно пиесата „Черен камък“ на Алберто Конехеро¹, в която драматургът си представя срещата между юношата франкист Себастиан и обречения на разстрел републиканец Рафаел Родригес Рапун (реалния последен любим на Лорка). Третата линия е съвременна, но заедно с плодотворния контраст вкарва и допълнителна порция шум… („Страхливец“ на Люкас Донт, за който вече говорихме, е далеч по-изпипан етюд на тема любов/война от реколтата „Кан 2026“ – заслужава си „Черната топка“ да се гледа успоредно с него за сравнение.)

„Сан Себастиан 2026“. „Трябва да се живее!“
„Сан Себастиан 2026“. „Трябва да се живее!“

Jaleos: Росио Молина, байлаора (танцьорка на фламенко) / Кадър от Jaleos на Исаки Лакуеста

„Трябва да се живее!“,

изкрещява един от „Комедиантите“ на Марио Камус (1963) и избухва в неистов танц, цитиран в Jaleos, първа част от документален диптих за корените, контекста, представителите и същината на фламенкото, включена във фестивалния раздел за експерименти „Отворено пространство“.

Битува представата, че фламенкото е нещо много старо и много нашенско, но истината е, че то е доста ново и се е формирало от стичането на милион обстоятелства с най-разнообразен произход,

каза авторът. Филмът е прелюбопитен обзор на не особено познати факти: какво танцува Карменсита от Алмерия (първата жена, снимана за киноекрана през 1894 г. в студиото на изобретателя Томас Едисън); защо на испански flamenco е „фламенко“, „фламинго“ и „фламандец“; как така „Саета“ на Майлс Дейвис се причислява към най-доброто в жанра…

Началото на Jaleos (дума, ползвана за типичните за фламенкото окуражителни възклицания към изпълнителите) е архивен откъс с хубава жена, която ритмично тропа с токове, докато съвременни коментатори обсъждат зад кадър: фламенко – друг път… нищо общо с Испания… виж я как си тътри краката… ух, какъв скован кръст. Жената, оказва се, е Лени Рифенщал, прочутата режисьорка на нацистката пропаганда по Хитлерово време, тук – в ролята на фатална южнячка. Филмът ѝ „Низината“ е по едноименната пиеса на каталонеца Анджел Гимера̀ от ХIХ век, а 120-те фигуранти в същия този филм – роми, изведени за целта от два концентрационни лагера. Докато Лени монтира произведението си години по-късно, над 100 от тях вече са убити в Аушвиц… Ето, значи, само един от многото детайли в Jaleos, които разкриват цели бездни: статистите на Рифенщал са лагерници, а днес, за да се използват кадри с техните лица и движения, се плащат авторски права на нейните наследници.

„Фламенко“, режисьор Карла Симон

Институтът за външна търговия ICEX е орган на испанското Министерство на икономиката и се грижи да популяризира местните производители, изобретатели и предприемачи така, че светът да ги опознае и хареса. Една от най-новите му инициативи поощрява аудио-визуалния сектор, за да покаже красивото многообразие на made in Spain чрез авторски късометражки по характерни теми. Тази година резултатът са три творби, чийто дебют се състоя в Кан. А една от тях – „Фламенко“ на Карла Симон, получи номинация за предстоящите „Грами“ (латино) в категорията „Най-добро дългоформатно видео“. Отварям дума не само защото „Фламенко“ дели с Jaleos предмет и участници и го гледах в Сан Себастиан, а и защото неовладяно заблазявам на всички държави, способни да ангажират за общата кауза истински таланти и да им позволят да постигнат подобно качество.

„Сан Себастиан 2026“. „Трябва да се живее!“
„Сан Себастиан 2026“. „Трябва да се живее!“
„Сан Себастиан 2026“. „Трябва да се живее!“

Марианхел Вийегас и Даниела Марин Наваро във „Винаги съм твоето майчино животно“ / Росио Гусман и Дарана Алварес в мексиканския филм „Тъжни момичета“ / „Илюзията за безкрайно лято“: Гилермина и Белинда

Три по две от Латинска Америка

От дузината селектирани през 2026 г. в „Латинохоризонти“ специално внимание заслужават три чудни филма с непрофесионални изпълнителки: две сестри, две приятелки, две братовчедки.

Дебютът на Валентина Маурел (Коста Рика) „Сънувам електрически сънища“ разказваше в необичаен ключ за едно артистично семейство в разпад и особено за отношенията баща–дъщеря – с поезия, лутане и вулканични чувства. Вторият, чието заглавие е заето от стихотворение на майката на режисьорката и буквално означава „Винаги съм твоето майчино животно“, следва сходен модел и привлича същите магнетични изпълнители на две от главните роли, но не успява да „лумне“ като предишния, при все че нито доскучава, нито фалшиви. Персонажите са в криза и пред отпътуване, градът и музиката са с присъствието на действащи лица, а вниманието този път е обърнато към най-младите. Но Маурел трудно може да бъде обобщена, което, струва ми се, е един от най-хубавите комплименти.

„Тъжни момичета“ на Фернанда Товар (Мексико) е за фантастичната сила на тийнейджърските приятелства и за „специфично женската тъга“ от определени житейски дадености, която никоя от нас не успява да избегне дори в най-безгрижните си години, както отбеляза авторката. Две млади състезателки по плуване се носят из басейна и из града и неспирно бърборят – чувстват се безсмъртни и докато не става ясно, че не са, всъщност наистина изглеждат такива: неземни, окрилени, легендарни, щастливи. Един от визуално най-красивите филми в програмата, в който има десетки възможности за любуване.

„Мълнията търси белите животни и блестящите неща“, обяснява възрастна жена в „Илюзията за безкрайно лято“ – прощъпулник в киното на фотографката от „Магнум“ Алесандра Сангуинети, която в Сан Себастиан спечели наградата в раздела „Латинохоризонти“ и приза на младежкото жури (150 души между 18 и 25 години, които имаха да избират измежду 21 заглавия). Някъде през 1998-ма в дълбоката аржентинска провинция Алесандра започва да снима своите десетинагодишни съседки Гийермина и Белинда: те играят, пеят, скитат, изразяват схващания за света, започват работа, стават млади майки, за първи път отиват в чужбина. Четвърт век в 80 часа суров материал, сведени до 90 минути есенция – семпли, но същевременно богати и изненадващи като живота. „Искам да съм пеперуда – казва едното дете, – защото те живеят само ден. Така ще се раждам отново и отново.“

„Сан Себастиан 2026“. „Трябва да се живее!“
„Сан Себастиан 2026“. „Трябва да се живее!“

Валерия Върбанова в „Обувките на баща ми“ / Част от екипа на „Обувките на баща ми“: Христо Симеонов, Катя Тричкова, Валерия Върбанова, Веселин Христов

Чий е човек?

Този объркващ въпрос ни принуждава да си зададем пълнометражният дебют на Христо Симеонов. „Обувките на баща ми“ беше избран заедно с още 13 заглавия за конкурсния раздел с първи и втори филми „Нови режисьори“, с победа в който преди 12 години започнаха фестивалния си път Кристина Грозева и Петър Вълчанов. В ядрото му е реално събитие: три жени, отдавна изоставени от един мъж, получават мъртвото му тяло и докато уреждат погребението му, започват да се чудят дали това е същият човек. Доколко познаваме ключовите фигури в живота си? Има ли близостта давност?

Валерия Върбанова (дъщерята), Таня Шахова (майката) и Вяра Коларова (сестрата) са триото, което трябва да преодолее ситуацията, и изборът на Симеонов на типажи с различна гъвкавост и ритъм е много подходящ: топлота, инат и твърдост влизат в интересни сблъсъци. „Дано да е момиче“ е освежаващо неочаквана фраза от екрана, нищо че като цяло диалозите са най-бледата част от цялото… „Обувките на баща ми“ понякога оставя едно усещане за тук могат, но невинаги смеят, но то като цяло не препъва удоволствието от нетипичната за новото българско кино нежност в повествованието, от умението на оператора Веселин Христов, съобразителността на композитора Милен Апостолов и много още.

В Сан Себастиан авторът Христо Симеонов беше така любезен да ни отговори на няколко бързи въпроса.

Как решихте да се занимавате с кино и как избирате какво да разказвате?

Покрай филмите на Кен Лоуч, и то след гимназията. Реших, че трябва да правя силно социално кино. Семейството ми е от работническата класа и идеята за изкуство и за професията на режисьора за мен беше твърде абстрактна. Та в киното се впуснах наивно. Сестра ми, бог да я прости, ме окуражи – на нея го дължа. Защото за майка ми и баща ми мисълта, че киното може да се учи и от него да се изкарва прехрана, беше чужда… Първото, което тръгнах да разказвам и от което се вълнувах, беше свързано с неща от детството. Това се промени с времето и в един момент, като изгубих желание да говоря за него, сякаш изчезна и желанието ми за социалната форма. Сега ми се разказва за семейството ми, за формиращи и травмиращи неща, с които човек трябва да се справя. Замислям един проект, свързан с баба ми Васила, много добра жена, ужасно търпелива. Тя и дядо ми са в основата. В него ще се разказва за влашките роми, които бяха много по нашия край. И тъй като не мога да си представя, че ще го снимам на български, реших, че трябва да е на езика, който говорят копанарите в България, за да бъде автентично за мен поне – да взема роми, които много често живеят в катуни извън селата.

Какво според вас е нужно на един филм, за да бъде разбран?

Аз лично, ако усетя, че не съм докрай честен със себе си, знам, че това ще бъде пречка за зрителя. Но кой зрител? Не можем да слагаме под общ знаменател всичките. Така че аз си избирам по-критичния. И се питам: окей, той ще разбере ли тук компромиса? Ще усети ли, че съм фейкнал?

Как дойде идеята за „Обувките на баща ми“?

По истински случай, който ми разказа една дознателка от Видин. Куриозна ситуация, която в реалността, за разлика от филма, завършва неоптимистично. Първата ми идея беше за късометражка, но вече не ми се правят късометражки. Трябваше ми доста време да разбера, да усетя какво всъщност искам от тази история. Отначало имахме вариант, който се развива през погледа на дознателя и завършва без надежда за героите. И той като текст беше супер. Но чак в последния вариант на сценария, примерно месец или два преди да започнем да снимаме, си дадох сметка, че за мен е много важно да се погрижа за тях и да не ги третирам просто като част от сюжета. В моето семейство се случи нещо, което много ме разтърси, и то ми даде емоционалното разбиране за героите – какъв ключ да търся извън анекдота. И тогава всичко се обърна и героите станаха главни. Извън абсурда дойде и този слой, но за целта вероятно е трябвало първо да получа някакво лично знание.

Кога сте най-щастлив, докато правите кино?

Снимачният период е най-пълнокръвен за мен. Работата на терен. Да пробваме неща с актьорите, с оператора, да експериментираме, да импровизираме. Да виждам как се случват нещата, да хвърля сценария в кофата.

От кое сте най-удовлетворен след прожекцията на „Обувките на баща ми“ в Сан Себастиан?

Колкото и критично да го гледам, аз все още се вълнувам от него. Има моменти, които ме оставят безразличен и си казвам: лошо. Те са просто регистрирани и то се усеща. Но има и такива, в които усещам искреност и че нещата са станали, че са живи. Конкретни сцени, където всичко е пълнокръвно и меко, носи настроение. Меко. Това винаги ми е било целта. Да намеря баланса, при който да не се натрапвам на зрителя, но и да не го оставям безразличен. В някои сцени се е получило много добре, в други – не.

1 Превод на „Черен камък“ на български е на разположение на читателите на „Тоест“ в сайта на Нева Мичева.

Патриоти за мъртвите – страхливци за живите

Post Syndicated from Емилия Милчева original https://www.toest.bg/patrioti-za-murtvite-strahlivtsi-za-zhivite/

Патриоти за мъртвите – страхливци за живите

Лесно е да показваш патриотизъм, който не изисква особена политическа смелост, тъй като е свързан с миналото. Трудно е да отстояваш българското национално достойнство в настоящето, когато това означава да назовеш агресор и да заемеш позиция, която струва повече от всички патриотични речи.

Само за четири дни българските управляващи се придвижиха от единия полюс до другия. Демонстрираха смелост пред историята с пренасянето на тленните останки на цар Самуил в днешна България и се свиха смълчани и предпазливи пред заплахата, ударила два кораба в изключителната икономическа зона в Черно море. Бившият президент Румен Радев, овладял изпълнителната власт със своята „Прогресивна България“, наложи комбинацията от патриотична реторика и снишаване пред Русия още в първите месеци на управлението си.

Самуил е мъртъв повече от хилядолетие, но властта е готова да защитава неговите царски достойнства и да се перчи пред Скопие. Съпротивата му срещу една империя е повод за национална гордост днес, но днешната заплаха от друга имперска сила не среща Самуиловата решителност. 

Управляващите, подкрепени от лидера на ГЕРБ Борисов, не назоваха Русия като заплаха за сигурността ни, макар че ЕС и НАТО – съюзите, към които принадлежим, отдавна я определиха по този начин. На Консултативния съвет за национална сигурност (КСНС), свикан неохотно от президентката Илияна Йотова, Радев и назначените от него министри и шефове на служби не събраха смелост да посочат извършителя на атаките. Избегнаха го и при взривовете, избухнали преди около месец в склад – собственост на оръжейната фирма ЕМКО и Емилиян Гебрев.

Руският интерес към българската оръжейна индустрия не е новина. Още през 2021 г. българската прокуратура посочи шестима руски граждани, свързани с военното разузнаване ГРУ, като заподозрени за четири взрива в оръжейни складове. 

Но през 2026-та КСНС настоя да бъдат събрани доказателства, за да бъде установен извършителят на атаките с дронове срещу двата кораба в Черно море, а премиерът увери, че няма непосредствена заплаха за националната сигурност. Допусна, че логиката сочи Русия, но без доказателства не може да я обвини. Така България остана без отговор кой е атакувал корабите, но с уверението, че няма от какво непосредствено да се страхува. 

Когато говорим за национална сигурност, ние не можем да работим с хипотези, 

заяви Радев. И е прав, че за установяването на извършителя на конкретно нападение са необходими доказателства. 

Украинският президент Володимир Зеленски обаче заяви още на 6 октомври, че украинските военноморски сили са се свързали с българските си колеги и след уточняване на информацията е установено, че става въпрос за комбинирана руска атака с морски и въздушни дронове. 

Радев отрече такава комуникация, позовавайки се на докладите на министъра на отбраната и службите пред КСНС. Ден по-късно обаче външната ни министърка Велислава Петрова-Чамова заяви, че българските служби поддържат постоянен контакт с украинските си колеги, но няма потвърждение от българска страна за руска атака.

Така остава неизяснено не само кой е изпратил дроновете, но и каква информация е обменена между София и Киев. И защо при толкова категорично твърдение на Зеленски българските власти не са изяснили публично противоречието.

Но едно е да не си сигурен кой е изпратил дроновете, друго е да избягваш оценката за държавата, която води война в Черно море и чиито действия застрашават сигурността на региона. За първото е нужно разследване, но за второто България разполага с достатъчно факти, както и с оценките на съюзниците си. 

Вместо да постави пред Москва въпроса за рисковете, които руската война създава за гражданското корабоплаване, и да използва наличните дипломатически инструменти, КСНС поиска от ЕС и НАТО засилване на мерките за сигурност в Черно море. 

По предложение на Радев Европейската агенция по морска безопасност (EMSA) е изразила готовност безвъзмездно да изследва останките на потъналия кораб за следи от дронове.

Но същността на онова, което Йотова огласи след заседанието на КСНС, беше призивът за дипломатически усилия за прекратяване на войната в Украйна и за постигане на мир. Призивът за мир обаче не казва кой e започнал агресията и кой трябва да я прекрати. Така Русия и Украйна се оказват поставени на една плоскост, което се прави не за първи път, а въпросът за отговорността се заменя с пожелание за прекратяване на военните действия.

Избирателният суверенитет

Националното достойнство има различна цена според това срещу кого трябва да бъде отстоявано. Пред Скопие България говори от позицията на историческата правота, пред Москва предпочита дипломацията на васал и оставя на съюзниците да назовават заплахите. 

Атаките край България и Румъния ще бъдат обсъдени на Европейския съвет на 15 и 16 октомври като част от ескалацията на руските хибридни действия. Това потвърждава говорител на Европейския съвет пред Клуб Z.

Властта мобилизира армията, Православната църква и институциите, за да посрещне с невиждани държавни почести останките на средновековен цар – символ на българската държавност. Самуил, воювал почти непрекъснато с Византия, беше представен като образец на държавническа доблест и съпротива срещу чуждото господство. Двойки изтребители МиГ-29 и F-16 ескортираха военнотранспортния „Спартан“ с останките му, прозвучаха 21 артилерийски салюта, а премиерът Радев говори за национално единство.

Днес ние посрещаме неговия дух, неговата непримиримост, неговата безпределна вяра в Отечеството и завета му да пазим България.

На площад „Княз Александър I“ на 3 октомври обаче посрещачите бяха значително по-малко от 25-те хиляди, дошли заради DARA. Въпреки осигуреното от БДЖ безплатно пътуване до София церемонията не предизвика очакваното масово въодушевление. Държавата беше вложила повече усилия в организирането на патриотичния спектакъл, но сякаш гражданите не показаха реципрочно желание да участват в него.

Няколко дни след тържественото посрещане на останките на Самуил България се оказа изправена пред съвсем различен тест за държавност. Сирия поиска обяснение защо е прекратено издирването на моряците, девет от които са сирийски граждани, от потъналия за три минути ALFA WATAN. България вече обяви, че то няма да бъде подновено, нито ще бъде извършен подводен оглед на останките. Последното означава, че ще се разчита на ΕΜSA да търси следи от дронове. Но Дамаск настоява за независимо разследване и изясняване на обстоятелствата около прекратената спасителна операция.

Турският президент Реджеп Тайип Ердоган постави въпроса за сигурността на гражданското корабоплаване в Черно море директно пред Владимир Путин. Анкара поддържа отношения и с Москва, и с Киев, но това не ѝ пречи да разговаря с руския президент за рисковете от войната.

Атаките срещу търговски кораби застрашават износа на Украйна, оскъпяват транспорта и застраховките и създават рискове за пристанищата и търговията на черноморските държави, особено на Турция, която контролира достъпа до Черно море през Босфора и Дарданелите. 

Суверенитетът обаче не е само правото да вземаш самостоятелни решения, а и способността да ги отстояваш пред по-силните от теб. Той не се измерва с непрекъснатите уверения на Радев и подчинените му, че България води „независима външна политика“, когато в действителност следва линията на Москва, прикривайки я зад апели за мир и дипломатическо уреждане на конфликта. 

Всъщност дори не я прикрива особено.

През 2022 г. България изгони 70 руски дипломатически служители, след като службите ги идентифицираха като работили срещу националните ѝ интереси. Решението предизвика остра реакция от Москва, но показа, че София разполага с дипломатически инструменти, когато реши да ги ползва. 

В представите на Радев независимата външна политика се проявява най-вече като право да не се съгласяваш с Брюксел. Спрямо Русия обаче тази независимост омеква. 

Получава се особен вид суверенитет. България държи да не ѝ диктуват от Брюксел, но си налага ограничения, когато трябва да възрази на Москва. И колкото по-често властта говори за независимост, толкова по-видима става границата, отвъд която не смее да я упражни.

The collective thoughts of the interwebz