Why CVSS is No Longer Enough for Exposure Management

Post Syndicated from Joel Alcon original https://www.rapid7.com/blog/post/em-cvss-and-exposure-management

For years, cybersecurity professionals have relied on a familiar metric to dictate their day-to-day priorities: the Common Vulnerability Scoring System (CVSS). In today’s hyper-connected, sprawling IT environments, utilizing a static severity score as the ultimate arbiter of risk creates opportunities for threat actors. While defenders chase down theoretical, high-scoring alerts, adversaries are quietly targeting the truly exploitable, business-critical exposures that slip through the cracks.

In a recent report, Gartner® highlighted a projection: 

“By 2028, organizations that prioritize exposures using threat intelligence, asset context, exploitability modeling and security control validation will reduce breach likelihood by at least 70% compared to peers relying primarily on CVSS-based vulnerability prioritization.” [1]

This affirms what many seasoned practitioners have suspected for years: there’s an abundance of vulnerability findings, but a lack of actionable context.

Static scores. Reactive security.

Most vulnerability management programs evolved during a time when the attack surface was relatively static, adversary tooling was rudimentary, and remediation capacity generally exceeded the volume of new disclosures. Today, enterprises are confronted with vulnerabilities scattered across complex cloud architectures, SaaS applications, and intricate supply chains.

In this modern threat landscape, CVSS alone is insufficient because it measures theoretical severity, does not factor in whether an attacker is actually using the vulnerability in the wild, or consider the business value of any affected assets. According to Gartner®, fewer than 10% of vulnerabilities are exploited, yet most are treated as urgent [1]. This all leads to prioritization paralysis, where security teams spend countless hours patching vulnerabilities that pose low material risk to the business. The legacy approach rewards what is auditable rather than what is genuinely impactful.

The path toward smarter prioritization

To break free from endless patching and ineffective risk reduction practices, security professionals are shifting toward a context-driven model. As Gartner notes, strong exposure prioritization requires integrating four critical elements: threat intelligence, asset context, data science, and security control validation. Organizations are approaching these elements in a few practical ways:

Threat intelligence to establish relevance

Instead of just asking how severe a vulnerability is, modern exposure management asks whether an exposure is relevant to a threat actor who is capable of exploiting it right now. By embedding threat intelligence into each vulnerability finding, teams shift the focus from theoretical to risk active exploitation. It introduces the adversary’s perspective by identifying known exploited vulnerabilities, public or private exploit availability, and targeted campaigns. By filtering out exposures with no evidence of attacker interest, organizations can instantly collapse large vulnerability backlogs and focus only on relevant threats.

Rapid7-threat-intelligence-remediation-hub.png

Asset context and business criticality to define impact

Not all assets are created equal. A critical vulnerability on an isolated, internal test server is vastly different from the same vulnerability on a public-facing cloud workload processing customer sensitive data. Asset context enriches exposure data with crucial business information: what the asset is, its external accessibility, and its relationship to core business functions. Without this context, security teams waste disproportionate effort on low-impact systems, treating every critical alert as an equal emergency.

Endpoint-protection-Rapid7-remediation-hub.png

Exploitability modeling for predicting breach likelihood

Security analysts often struggle to assess exploitability given the overwhelming volume of vulnerabilities. By using predictive models like the Exploit Prediction Scoring System (EPSS), organizations can analyze large datasets of historical exploitation to identify latent risks. Exposure assessment platforms should display this data alongside each exposure finding to make it easier to predict the vulnerabilities most likely to become attacks.

Rapid7-vulnerability-risk-score-exposure.png

Security control validation

An exposure that appears highly exploitable in theory might be neutralized by existing defenses. By integrating security and policy controls, you can evaluate exposures in the context of endpoint protection and identity management. This passive validation confirms whether an attacker can realistically exploit the exposure in your specific environment.

Rapid7-remediation-details.png

Unified exposure management

Individually, each element highlighted above provides incremental value, but when integrated, they fundamentally transform how prioritization decisions are made. This integrated model ensures that remediation efforts are mobilized only after priorities have been validated in the context of the business and the current threat landscape. It transitions vulnerability management from a purely technical, tool-centric exercise into a strategic, process-driven risk decision.

Security leaders must measure success not by the sheer number of vulnerabilities closed, but by the demonstrable reduction of exploitable exposures and the alignment of remediation efforts with actual attacker behavior. Operationalizing these four elements requires a unified platform that eliminates the silos between vulnerability management, cloud security, and threat intelligence. You cannot manually stitch together disconnected spreadsheets and hope to outpace modern adversaries. This is where forward-thinking organizations are leaning on comprehensive, end-to-end solutions like Rapid7 Exposure Command that seamlessly aggregate visibility across on-premises and dynamic cloud environments. With deep, native integration of Rapid7 Cloud Security capabilities, teams can instantly map asset criticality and external accessibility within complex, ephemeral cloud architectures. Furthermore, by infusing world-class threat intelligence and active exploit data directly into exposure findings, Rapid7 enables security teams to cut through the noise, validate security controls, and pinpoint the exact exposures that matter most—all with minimal friction.

[1] Gartner, Prioritize What Attackers Will Exploit: 4 Elements of Strong Exposure Prioritization, Jonathan Nunez, 5 March 2026.

Security updates for Friday

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

Security updates have been issued by AlmaLinux (389-ds:1.4, gnutls, mysql:8.0, mysql:8.4, nginx, nginx:1.24, opencryptoki, python3, vim, and virt:rhel and virt-devel:rhel), Debian (firefox-esr, ruby-rack, and thunderbird), Fedora (fontforge, headscale, kryoptic, libopenmpt, pyOpenSSL, python-cryptography, rubygem-json, rust-asn1, rust-asn1_derive, rust-cryptoki, rust-cryptoki-sys, rust-wycheproof, vim, and vtk), Oracle (freerdp, golang, mysql:8.0, and ncurses), Red Hat (osbuild-composer), Slackware (libpng and tigervnc), SUSE (chromium, frr, kea, kernel, nghttp2, pgvector, python-deepdiff, python-pyasn1, python-tornado6, python-urllib3, python3, python310, ruby2.5, salt, sqlite3, systemd, tomcat, vim, and xen), and Ubuntu (libcryptx-perl).

How we use Abstract Syntax Trees (ASTs) to turn Workflows code into visual diagrams

Post Syndicated from André Venceslau original https://blog.cloudflare.com/workflow-diagrams/

Cloudflare Workflows is a durable execution engine that lets you chain steps, retry on failure, and persist state across long-running processes. Developers use Workflows to power background agents, manage data pipelines, build human-in-the-loop approval systems, and more.

Last month, we announced that every workflow deployed to Cloudflare now has a complete visual diagram in the dashboard.

We built this because being able to visualize your applications is more important now than ever before. Coding agents are writing code that you may or may not be reading. However, the shape of what gets built still matters: how the steps connect, where they branch, and what’s actually happening.

If you’ve seen diagrams from visual workflow builders before, those are usually working from something declarative: JSON configs, YAML, drag-and-drop. However, Cloudflare Workflows are just code. They can include Promises, Promise.all, loops, conditionals, and/or be nested in functions or classes. This dynamic execution model makes rendering a diagram a bit more complicated.

We use Abstract Syntax Trees (ASTs) to statically derive the graph, tracking Promise and await relationships to understand what runs in parallel, what blocks, and how the pieces connect. 

Keep reading to learn how we built these diagrams, or deploy your first workflow and see the diagram for yourself.

Here’s an example of a diagram generated from Cloudflare Workflows code:


Dynamic workflow execution

Generally, workflow engines can execute according to either dynamic or sequential (static) execution order. Sequential execution might seem like the more intuitive solution: trigger workflow → step A → step B → step C, where step B starts executing immediately after the engine completes Step A, and so forth.

Cloudflare Workflows follow the dynamic execution model. Since workflows are just code, the steps execute as the runtime encounters them. When the runtime discovers a step, that step gets passed over to the workflow engine, which manages its execution. The steps are not inherently sequential unless awaited — the engine executes all unawaited steps in parallel. This way, you can write your workflow code as flow control without additional wrappers or directives. Here’s how the handoff works:

  1. An engine, which is a “supervisor” Durable Object for that instance, spins up. The engine is responsible for the logic of the actual workflow execution. 

  2. The engine triggers a user worker via dynamic dispatch, passing control over to Workers runtime.

  3. When Runtime encounters a step.do, it passes the execution back to the engine.

  4. The engine executes the step, persists the result (or throws an error, if applicable) and triggers the user Worker again.  

With this architecture, the engine does not inherently “know” the order of the steps that it is executing — but for a diagram, the order of steps becomes crucial information. The challenge here lies in getting the vast majority of workflows translated accurately into a diagnostically helpful graph; with the diagrams in beta, we will continue to iterate and improve on these representations.

Parsing the code

Fetching the script at deploy time, instead of run time, allows us to parse the workflow in its entirety to statically generate the diagram. 

Taking a step back, here is the life of a workflow deployment:


To create the diagram, we fetch the script after it has been bundled by the internal configuration service which deploys Workers (step 2 under Workflow deployment). Then, we use a parser to create an abstract syntax tree (AST) representing the workflow, and our internal service generates and traverses an intermediate graph with all WorkflowEntrypoints and calls to workflows steps. We render the diagram based on the final result on our API. 

When a Worker is deployed, the configuration service bundles (using esbuild by default) and minifies the code unless specified otherwise. This presents another challenge — while Workflows in TypeScript follow an intuitive pattern, their minified Javascript (JS) can be dense and indigestible. There are also different ways that code can be minified, depending on the bundler. 

Here’s an example of Workflow code that shows agents executing in parallel:

const summaryPromise = step.do(
         `summary agent (loop ${loop})`,
         async () => {
           return runAgentPrompt(
             this.env,
             SUMMARY_SYSTEM,
             buildReviewPrompt(
               'Summarize this text in 5 bullet points.',
               draft,
               input.context
             )
           );
         }
       );
        const correctnessPromise = step.do(
         `correctness agent (loop ${loop})`,
         async () => {
           return runAgentPrompt(
             this.env,
             CORRECTNESS_SYSTEM,
             buildReviewPrompt(
               'List correctness issues and suggested fixes.',
               draft,
               input.context
             )
           );
         }
       );
        const clarityPromise = step.do(
         `clarity agent (loop ${loop})`,
         async () => {
           return runAgentPrompt(
             this.env,
             CLARITY_SYSTEM,
             buildReviewPrompt(
               'List clarity issues and suggested fixes.',
               draft,
               input.context
             )
           );
         }
       );

Bundling with rspack, a snippet of the minified code looks like this:

class pe extends e{async run(e,t){de("workflow.run.start",{instanceId:e.instanceId});const r=await t.do("validate payload",async()=>{if(!e.payload.r2Key)throw new Error("r2Key is required");if(!e.payload.telegramChatId)throw new Error("telegramChatId is required");return{r2Key:e.payload.r2Key,telegramChatId:e.payload.telegramChatId,context:e.payload.context?.trim()}}),s=await t.do("load source document from r2",async()=>{const e=await this.env.REVIEW_DOCUMENTS.get(r.r2Key);if(!e)throw new Error(`R2 object not found: ${r.r2Key}`);const t=(await e.text()).trim();if(!t)throw new Error("R2 object is empty");return t}),n=Number(this.env.MAX_REVIEW_LOOPS??"5"),o=this.env.RESPONSE_TIMEOUT??"7 days",a=async(s,i,c)=>{if(s>n)return le("workflow.loop.max_reached",{instanceId:e.instanceId,maxLoops:n}),await t.do("notify max loop reached",async()=>{await se(this.env,r.telegramChatId,`Review stopped after ${n} loops for ${e.instanceId}. Start again if you still need revisions.`)}),{approved:!1,loops:n,finalText:i};const h=t.do(`summary agent (loop ${s})`,async()=>te(this.env,"You summarize documents. Keep the output short, concrete, and factual.",ue("Summarize this text in 5 bullet points.",i,r.context)))...

Or, bundling with vite, here is a minified snippet:

class ht extends pe {
  async run(e, r) {
    b("workflow.run.start", { instanceId: e.instanceId });
    const s = await r.do("validate payload", async () => {
      if (!e.payload.r2Key)
        throw new Error("r2Key is required");
      if (!e.payload.telegramChatId)
        throw new Error("telegramChatId is required");
      return {
        r2Key: e.payload.r2Key,
        telegramChatId: e.payload.telegramChatId,
        context: e.payload.context?.trim()
      };
    }), n = await r.do(
      "load source document from r2",
      async () => {
        const i = await this.env.REVIEW_DOCUMENTS.get(s.r2Key);
        if (!i)
          throw new Error(`R2 object not found: ${s.r2Key}`);
        const c = (await i.text()).trim();
        if (!c)
          throw new Error("R2 object is empty");
        return c;
      }
    ), o = Number(this.env.MAX_REVIEW_LOOPS ?? "5"), l = this.env.RESPONSE_TIMEOUT ?? "7 days", a = async (i, c, u) => {
      if (i > o)
        return H("workflow.loop.max_reached", {
          instanceId: e.instanceId,
          maxLoops: o
        }), await r.do("notify max loop reached", async () => {
          await J(
            this.env,
            s.telegramChatId,
            `Review stopped after ${o} loops for ${e.instanceId}. Start again if you still need revisions.`
          );
        }), {
          approved: !1,
          loops: o,
          finalText: c
        };
      const h = r.do(
        `summary agent (loop ${i})`,
        async () => _(
          this.env,
          et,
          K(
            "Summarize this text in 5 bullet points.",
            c,
            s.context
          )
        )
      )...

Minified code can get pretty gnarly — and depending on the bundler, it can get gnarly in a bunch of different directions.

We needed a way to parse the various forms of minified code quickly and precisely. We decided oxc-parser from the JavaScript Oxidation Compiler (OXC) was perfect for the job. We first tested this idea by having a container running Rust. Every script ID was sent to a Cloudflare Queue, after which messages were popped and sent to the container to process. Once we confirmed this approach worked, we moved to a Worker written in Rust. Workers supports running Rust via WebAssembly, and the package was small enough to make this straightforward.

The Rust Worker is responsible for first converting the minified JS into AST node types, then converting the AST node types into the graphical version of the workflow that is rendered on the dashboard. To do this, we generate a graph of pre-defined node types for each workflow and translate into our graph representation through a series of node mappings. 

Rendering the diagram

There were two challenges to rendering a diagram version of the workflow: how to track step and function relationships correctly, and how to define the workflow node types as simply as possible while covering all the surface area.

To guarantee that step and function relationships are tracked correctly, we needed to collect both the function and step names. As we discussed earlier, the engine only has information about the steps, but a step may be dependent on a function, or vice versa. For example, developers might wrap steps in functions or define functions as steps. They could also call steps within a function that come from different modules or rename steps. 

Although the library passes the initial hurdle by giving us the AST, we still have to decide how to parse it.  Some code patterns require additional creativity. For example, functions — within a WorkflowEntrypoint, there can be functions that call steps directly, indirectly, or not at all. Consider functionA, which contains console.log(await functionB(), await functionC()) where functionB calls a step.do(). In that case, both functionA and functionB should be included on the workflow diagram; however, functionC should not. To catch all functions which include direct and indirect step calls, we create a subgraph for each function and check whether it contains a step call itself or whether it calls another function which might. Those subgraphs are represented by a function node, which contains all of its relevant nodes. If a function node is a leaf of the graph, meaning it has no direct or indirect workflow steps within it, it is trimmed from the final output. 

We check for other patterns as well, including a list of static steps from which we can infer the workflow diagram or variables, defined in up to ten different ways. If your script contains multiple workflows, we follow a similar pattern to the subgraphs created for functions, abstracted one level higher. 

For every AST node type, we had to consider every way they could be used inside of a workflow: loops, branches, promises, parallels, awaits, arrow functions… the list goes on. Even within these paths, there are dozens of possibilities. Consider just a few of the possible ways to loop:

// for...of
for (const item of items) {
	await step.do(`process ${item}`, async () => item);
}
// while
while (shouldContinue) {
	await step.do('poll', async () => getStatus());
}
// map
await Promise.all(
	items.map((item) => step.do(`map ${item}`, async () => item)),
);
// forEach
await items.forEach(async (item) => {
	await step.do(`each ${item}`, async () => item);
});

And beyond looping, how to handle branching:

// switch / case
switch (action.type) {
	case 'create':
		await step.do('handle create', async () => {});
		break;
	default:
		await step.do('handle unknown', async () => {});
		break;
}

// if / else if / else
if (status === 'pending') {
	await step.do('pending path', async () => {});
} else if (status === 'active') {
	await step.do('active path', async () => {});
} else {
	await step.do('fallback path', async () => {});
}

// ternary operator
await (cond
	? step.do('ternary true branch', async () => {})
	: step.do('ternary false branch', async () => {}));

// nullish coalescing with step on RHS
const myStepResult =
	variableThatCanBeNullUndefined ??
	(await step.do('nullish fallback step', async () => 'default'));

// try/catch with finally
try {
	await step.do('try step', async () => {});
} catch (_e) {
	await step.do('catch step', async () => {});
} finally {
	await step.do('finally step', async () => {});
}

Our goal was to create a concise API that communicated what developers need to know without overcomplicating it. But converting a workflow into a diagram meant accounting for every pattern (whether it follows best practices, or not) and edge case possible. As we discussed earlier, each step is not explicitly sequential, by default, to any other step. If a workflow does not utilize await and Promise.all(), we assume that the steps will execute in the order in which they are encountered. But if a workflow included await, Promise or Promise.all(), we needed a way to track those relationships.

We decided on tracking execution order, where each node has a starts: and resolves: field. The starts and resolves indices tell us when a promise started executing and when it ends relative to the first promise that started without an immediate, subsequent conclusion. This correlates to vertical positioning in the diagram UI (i.e., all steps with starts:1 will be inline). If steps are awaited when they are declared, then starts and resolves will be undefined, and the workflow will execute in the order of the steps’ appearance to the runtime.

While parsing, when we encounter an unawaited Promise or Promise.all(), that node (or nodes) are marked with an entry number, surfaced in the starts field. If we encounter an await on that promise, the entry number is incremented by one and saved as the exit number (which is the value in resolves). This allows us to know which promises run at the same time and when they’ll complete in relation to each other.

export class ImplicitParallelWorkflow extends WorkflowEntrypoint<Env, Params> {
 async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
   const branchA = async () => {
     const a = step.do("task a", async () => "a"); //starts 1
     const b = step.do("task b", async () => "b"); //starts 1
     const c = await step.waitForEvent("task c", { type: "my-event", timeout: "1 hour" }); //starts 1 resolves 2
     await step.do("task d", async () => JSON.stringify(c)); //starts 2 resolves 3
     return Promise.all([a, b]); //resolves 3
   };

   const branchB = async () => {
     const e = step.do("task e", async () => "e"); //starts 1
     const f = step.do("task f", async () => "f"); //starts 1
     return Promise.all([e, f]); //resolves 2
   };

   await Promise.all([branchA(), branchB()]);

   await step.sleep("final sleep", 1000);
 }
}

You can see the steps’ alignment in the diagram:


After accounting for all of those patterns, we settled on the following list of node types: 

| StepSleep
| StepDo
| StepWaitForEvent
| StepSleepUntil
| LoopNode
| ParallelNode
| TryNode
| BlockNode
| IfNode
| SwitchNode
| StartNode
| FunctionCall
| FunctionDef
| BreakNode;

Here are a few samples of API output for different behaviors: 

function call:

{
  "functions": {
    "runLoop": {
      "name": "runLoop",
      "nodes": []
    }
  }
}

if condition branching to step.do:

{
  "type": "if",
  "branches": [
    {
      "condition": "loop > maxLoops",
      "nodes": [
        {
          "type": "step_do",
          "name": "notify max loop reached",
          "config": {
            "retries": {
              "limit": 5,
              "delay": 1000,
              "backoff": "exponential"
            },
            "timeout": 10000
          },
          "nodes": []
        }
      ]
    }
  ]
}

parallel with step.do and waitForEvent:

{
  "type": "parallel",
  "kind": "all",
  "nodes": [
    {
      "type": "step_do",
      "name": "correctness agent (loop ${...})",
      "config": {
        "retries": {
          "limit": 5,
          "delay": 1000,
          "backoff": "exponential"
        },
        "timeout": 10000
      },
      "nodes": [],
      "starts": 1
    },
...
    {
      "type": "step_wait_for_event",
      "name": "wait for user response (loop ${...})",
      "options": {
        "event_type": "user-response",
        "timeout": "unknown"
      },
      "starts": 3,
      "resolves": 4
    }
  ]
}

What’s next

Ultimately, the goal of these Workflow diagrams is to serve as a full-service debugging tool. That means you’ll be able to:

  • Trace an execution through the graph in real time

  • Discover errors, wait for human-in-the-loop approvals, and skip steps for testing

  • Access visualizations in local development

Check out the diagrams on your Workflow overview pages. If you have any feature requests or notice any bugs, share your feedback directly with the Cloudflare team by joining the Cloudflare Developers community on Discord.

На Пеевски ще му е трудно с гласовете

Post Syndicated from Емилия Милчева original https://www.toest.bg/na-peevski-shte-mu-e-trudno-s-glasovete/

На Пеевски ще му е трудно с гласовете

Колко гласа ще получи ДПС – Ново начало на изборите на 19 април, ако акциите на МВР срещу купения и контролирания вот продължат със същата интензивност? Отговорът е: по-малко от тези на предишния вот на 27 октомври 2024 г., а следователно и по-малко депутати.

През есента на 2024-та ДПС – Ново начало получи 281 356 гласа (11,548%), срещу които спечели 30 депутати, а по-късно, след частичното касиране на вота от Конституционния съд (КС), те станаха 29. За Алианса за права и свободи (АПС), обединил привържениците на Ахмед Доган, гласуваха 182 253 души. А само няколко месеца по-рано, на 9 юни 2024 г., за все още цялото ДПС бюлетини пуснаха 366 310 души. 

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

Митът за могъществото на Пеевски не се крепи на електоралните завоевания. Те намаляват въпреки десетките кметове, изредили се да се снимат с него. В един момент обаче снимките секнаха, макар броят на местните властници да приближи петдесет. 

Показателни са резултатите в Кърджали от октомври 2024 г., традиционно силен район за Движението за права и свободи, който осигурява пет мандата. Но разцеплението в партията се отрази и там. Тогава ДПС – Ново начало получи 30 874 гласа от 9 МИР, а АПС – 28 851 гласа. В крайна сметка и двете формации взеха по два мандата, а безпрецедентно мандат спечели и друга партия – най-напред това беше МЕЧ, а след решението на КС депутатското кресло отиде при „Величие“.

Властта се люлее, „Величие“ зрее
Имаме нов състав на 51-вия парламент и това създава известни неудобства на партиите. Колко точно неудобно ще им е, предстои да се разбере. Иначе, не изглежда да изпитват неудобство от цялостната свинщина с фалшифицирането и унищожаването на стотици бюлетини. Коментар на Емилия Милчева.
На Пеевски ще му е трудно с гласоветеТоестЕмилия Милчева
На Пеевски ще му е трудно с гласовете

Ще има ли пробив в Кърджали?

Три седмици преди вота социологическите проучвания оставят и МЕЧ, и „Величие“ извън 52-рия парламент. А Пеевски е разпоредил да бъдат осигурени 50 000 гласа от Кърджали – колкото искаше и Доган навремето, когато още можеше да изисква. 

Едва ли ще му бъдат осигурени. 

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

Тази седмица беше арестуван ръководителят на Областната пощенска станция в Кърджали – Самет Хасан, който заплашвал и убеждавал служители на БЧК да обясняват, че раздаваните от тях хранителни помощи са от определена партия, за която хората трябва да гласуват. По подразбиране е ясно коя е партията. Случаят е от село Бенковски, община Кирково, където социално слаби хора трябвало да получат пакети. Те са осигурени от държавата и Европейския социален фонд, а Агенцията за социално подпомагане определя кой да ги получи.

След като Хасан бил задържан, кметът на Кърджали Ерол Мюмюн и сподвижници пробвали да нахлуят в Районното управление на МВР.

Кметът и привърженици на тази партия [ДПС – Ново начало, б.а.] са се опитали да влязат в районното в Кърджали. Проявили са енергичност, наложило се е да има отпор от страна на полицията.

Емил Дечев, служебен министър на вътрешните работи

Освен Самет Хасан, при други акции в Кърджалийско са задържани още двама души. При проверка в магазин в махала Дар дере на село Перперек са открити тетрадка с имена и числа срещу тях, както и пари и е била арестувана 58-годишна жена. В Крумовград е задържан мъж, за когото е установено, че е предлагал пари срещу гласуване. А в метална каса са били открити 11 000 евро, 605 000 турски лири, 8505 паунда, 7900 долара и 6700 швейцарски франка. 

В петъчния ден отново на територията на Кърджалийския избирателен район започна нова 24-часова акция, в рамките на която ще продължат проверките по хранителни магазини, заложни къщи и валутни бюра, както и в домове на граждани.

Преди дни бяха проверени и заложни къщи и фирми за бързи кредити в столичния квартал „Факултета“. Арестувани са и наркодилъри, които освен с дрога се занимават и с търговия с вот. Купувачите на гласове разширяват кръга на услугите – вече се предлага не само кеш или отписване на дългове, но и фризьорски и козметични услуги и покупки в магазини за дрехи за 50–100 евро.

Във Враца, при поредната акция, вътрешният министър съобщи, че са получени между 500 и 600% повече сигнали на граждани във връзка с изборни нарушения преди настоящия вот в сравнение със същия период преди изборите през 2024 г. 

В Столипиново бяха арестувани бивш общински съветник и ходжа за търговия с гласове. Мащабна акция имаше и във Великотърновско, в селата Кесарево, Бряговица, Асеново и Камен. В Северозападна България, където редовно е засичана търговия с вот, също имаше арести. При полицейска операция в Монтана и Лом са били открити над 37 000 евро, част от тях в купюри от по 50 евро, и тетрадки с имена и суми.

Никой не е по-силен от държавата

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

Гневни ли сте?
Положението в страната е „недоволството ми е много по-добро от недоволството ти“. Всички са недоволни посвоему, но това не е достатъчно за обединение на недоволствата и за взрив на обществото, макар социолозите да казват, че сме на една крачка от „много лошо“. Анализ на Емилия Милчева.
На Пеевски ще му е трудно с гласоветеТоестЕмилия Милчева
На Пеевски ще му е трудно с гласовете

Както и през 2021 г., когато друг служебен вътрешен министър – Бойко Рашков, проведе множество акции срещу купения вот, прокуратурата и сега не е особено активна. МВР среща по-скоро противодействие, отколкото съдействие от страна на прокуратурата, каза по онова време Рашков, влязъл в сблъсък с тогавашния главен прокурор Иван Гешев. Държавното обвинение и сега не показва отзивчивост към битката за честни избори, а Дечев, член на Съюза на съдиите, публично е заявявал позицията си относно легитимността на и.ф. главен прокурор Борислав Сарафов:

Слeд 21 юли 2025 г. ниe нямaмe и.ф. глaвeн пpoĸypop cпopeд Зaĸoнa зa cъдeбнaтa влacт. Teĸcтът нa зaĸoнa (чл. 173, aл. 15) e бeзĸpaйнo яceн и тoй ĸaзвa, чe лицaтa, ĸoитo изпълнявaт фyнĸциитe нa глaвeн пpoĸypop или нa пpeдceдaтeл нa BAC и BKC, нe мoгaт дa изпълнявaт тeзи фyнĸции пoвeчe oт 6 мeceцa.

А в ефира на Нова телевизия вътрешният министър обеща след вота да съобщи „кои са шампионите от политическите партии, които са купували най-много гласове, кой е на второ, кой е на трето място…“.

„Шампионите“ не са тайна, но така и не понасят отговорност за поръчките. За 20 години ефективните присъди за купуване на гласове са 100–120, каза преди време в ефира на Bgonair конституционалистът Стоил Моллов. В затвора попадат дребни риби, връзката партия–купувачи не е разкрита, въпреки че е известно за кои политически сили са предназначени бюлетините.

МВР може да профилактира купувачите на гласове, но не носи цялата отговорност за честността на вота – разделя я с Централната избирателна комисия, кметовете и областните управители. Няма как да повлияе и на преброителите в секционните избирателни комисии, чиито безобразия разкри видеонаблюдението на предишния вот.

Защо Пеевски ще се препъне в електората на ДПС
Краят на Пеевски започва там, където като стена се изправя травмата на българските турци и помаци от т.нар. Възродителен процес. Това е „незаобиколимият фактор“. От Светла Енчева.
На Пеевски ще му е трудно с гласоветеТоестСветла Енчева
На Пеевски ще му е трудно с гласовете

Коя ще е политическата сила, която има шанс за мандат от 9 МИР – Кърджали: „Прогресивна България“, ГЕРБ–СДС или ПП–ДБ? Председателят на гражданско движение „Единни заедно можем“ Себахтин Исмаил подкрепи „Да, България“ за изборите:

Въпреки че имаме резерви към някои партии в коалицията ПП–ДБ, „Да България“ са единствените, които се отвориха към нашия етнос и в които виждаме воля за промяна.

Контролът на държавата ще промени изборния резултат – по-малко зависимости, повече реална подкрепа. Вдигне ли се и избирателната активност, ще удави изтъргуваните гласове. Тогава за Пеевски и партията му ще има ново начало. 

Научни новини: Лунни мисии, комети и климатични промени

Post Syndicated from Михаил Ангелов original https://www.toest.bg/nauchni-novini-lunni-misii-kometi-i-klimatichni-promeni/

Artemis II все още е на Земята

Научни новини: Лунни мисии, комети и климатични промени

За съжаление на всички, които се вълнуват от първата мисия с екипаж до Луната от 50 години насам, тя няма да отпътува към спътника ни през март.

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

За да се засили напрежението, връщането ѝ също беше отложено с ден поради лошото време, което ограничи достъпа до нея. Самото преместване е деликатен процес, отнемащ около 12 часа. В хангара причината за проблема беше установена сравнително бързо – разместване на уплътнение на бързата връзка, през която се подава хелият, е блокирало потока на газа. Все още не е ясно как е станало това, но техниците продължават да се опитват да разберат, за да се предотвратят подобни случаи в бъдеще. Връщането на ракетата в хангара се използва и за работа по други елементи. Бяха подменени батериите на повечето модули, както и уплътнение на линията, захранваща основната степен на ракетата с течен кислород.

След приключването на ремонтните дейности и рутинната поддръжка ракетата премина редица тестове и вече е на стартовата площадка, а карантината на екипажа започна. Надеждата е полетът да хване следващия прозорец за изстрелване между 1 и 6 април, в противен случай ще остане за 30 април или по-късно. 

Научни новини: Лунни мисии, комети и климатични промени
„Земен изгрев“, заснет от астронавта Уилям Андерс на Apollo 8 – мисия, която е много сходна с Artemis II

Междувременно бяха съобщени промени и в следващите мисии. В началото на 2023 г. идеята беше, след като Artemis II прелети успешно покрай Луната, екипажът на Artemis III да кацне на нея с модула на SpaceX – Starship HLS (Human Landing System). С течение на времето обаче се натрупаха забавяния в графика и те доведоха до сегашната ситуация: нито SpaceX, нито Blue Origin имат функциониращ апарат, който може да извърши кацането.

Поради това целта на мисията се промени и през идната година екипажът ще остане в ниска земна орбита, където ще изпита най-различни системи, от които ще зависи бъдещото кацане. Едни от най-важните тестове ще са за скачването на Orion и модулите на двете частни компании (или поне един от тях), както при мисията Apollo 9. Това изглежда и като аналог на приликата между очаквания Artemis II и Apollo 8.

С промяната на целта на Artemis III кацането на Луната остава за екипажа на Artemis IV и се отлага за поне 2028 г.

Заради по-амбициозните цели на програмата Artemis има по-сложна организация от тази на Apollo. Вместо всички нужни модули да се изстрелят заедно от една ракета, е необходима координация между няколко организации. Космическият апарат Orion заедно с екипажа се изстрелва към Луната с ракетата SLS (Space Launch System), а след като влезе в лунна орбита, се скачва с модула за приземяване (HLS, произведен от SpaceX или Blue Origin), който е изведен дотам с ракета на съответната компания. Това дава възможност за преизползване на част от модулите и за създаване на инфраструктура за редовни мисии до бъдещи лунни бази.

Да кажем чао на 3I/ATLAS

В средата на месеца едва третата засечена комета, посетила ни от Дълбокия космос, премина покрай Юпитер. Това най-вероятно ще бъде последното по-интересно събитие с нея по пътя ѝ през нашата Слънчева система. То беше предвидено още при първоначалното определяне на курса на кометата и предизвиква интересни хипотези поради по-особената ѝ траектория.

3I/ATLAS прелита почти по ръба на Сферата на Хил на Юпитер, определяща разстоянието, в което гравитацията на планетата има по-силно влияние от тази на Слънцето и може да се използва за промени в орбитата на прелитащ обект. Такива гравитационни маньоври се правят рутинно при изстрелването на апарати в Космоса, защото спестяват част от горивото, което трябва да носят. В края на миналата година Ави Лоуб изказа мнение, че това може би не е случайно и мястото е много подходящо за отделяне на малки апарати (сонди) около Юпитер, ако приемем, че кометата е корабът майка. Хипотезата не звучи много правдоподобно поради изключително високата скорост на 3I/ATLAS – ако изключим научната фантастика, към момента не е познат начин кометата да се забави достатъчно, така че тези евентуални сонди да бъдат вмъкнати в орбита около планетата.

По-интригуващо би било, ако тези сонди не влязат в орбита, а „засеят“ обекти в Слънчевата система (например луните на Юпитер) с извънземни форми на живот. За това е нужно те да бъдат позиционирани по орбитата на избраните тела, след което да се приземят чрез lithobraking (спиране чрез удар). Възможността за това се подкрепя от скорошен експеримент, който показва, че някои бактерии могат да издържат на симулиран удар от метеорит.

В крайна сметка, колкото и да е вълнуваща идеята обектът да е продукт на извънземен разум, към момента нищо не го предполага. Дори самият Лоуб свали вероятността на 3 от 10 по своята скала.

Кометата ще остане в Слънчевата система още около 150 години, но скоро ще е прекалено далеч, за да може да бъде наблюдавана дори с най-мощните ни телескопи. Ето защо е време да се сбогуваме с този далечен пътник, който плени въображението ни, макар и за кратко.

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

Единият набор данни е събран от ALMA – международна обсерватория, която се намира в Чилийските Анди, на височина 5000 метра. Мястото е избрано поради своята височина и ниска влажност. Интересното е, че за разлика от класическите радиотелескопи с една голяма антена, ALMA представлява масив от 66 антени, които приемат вълни с дължина между радиовълните и инфрачервената светлина. Това дава възможност за наблюдаване на студен газ, прах и органични молекули. Другите данни са получени с помощта на космическата обсерватория „Джеймс Уеб“ (JWST).

От ALMA разбираме, че кометата има особено високо съдържание на метанол – повече от почти всички познати комети, които обикалят около Слънцето. Нехарактерно високо е и съотношението между съдържанието на въглероден диоксид и вода. Според една от хипотезите на авторите това може да се обясни с възрастта на кометата и дългия ѝ път през междузвездното пространство.

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

Друга възможност е кометата да се е образувала в регион с особено висока концентрация на въглероден диоксид. Една от хипотезите е, че такъв регион е дебелият диск на Млечния път – място, което е останало като своеобразен отпечатък от формирането на галактиката и съдържа предимно стари звезди.

Анализът на JWST разглежда съдържанието на по-тежките изотопи на водород и въглерод. Сходно с метанола, те са неочаквано високи в сравнение с тези при обичайно срещаните комети и близките междузвездни облаци и протопланетарни дискове. Авторите отбелязват, че това е характерно за образуване на кометата при изключително ниска температура – под 30 келвина (-243 градуса по Целзий), което предполага, че е станало в ранната история на Млечния път, преди около 10–12 млрд. години.

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

Климатът се променя по-бързо

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

Някои последни данни показват, че Ла Ниня (студената фаза на Южното колебание) отслабва и през следващите един-два месеца се очакват неутрални условия. След това вероятността за развитие на топла фаза – Ел Ниньо, се повишава значително – до 70–80%. Това са високи проценти, но трябва да се отбележи, че поради по-слабия интензитет на колебанието през пролетта точността на климатичните модели намалява. По тази причина към момента не е ясно дали Ел Ниньо ще бъде изключително силен, или не, поради което някои заглавия от последните дни изглеждат по-скоро сензационно.

Но дори и без „супер“ Ел Ниньо затоплянето на планетата се ускорява. В зависимост от източника данните варират от 0,27 до 0,35°C за десетилетие на фона на 0,20℃ през 70-те години на миналия век. Авторите на прогнозата с по-високата стойност отбелязват, че в техния анализ има компенсация на естествени явления, като изригвания на вулкани и силното затопляне през 2023 и 2024 г. вследствие на Ел Ниньо. Най-вероятно истината е някъде по средата, което не променя факта, че между учените има консенсус – температурата се покачва по-бързо.

Разбира се, това не става равномерно и промените не са еднозначни. Пример е времето в САЩ през последните няколко месеца. В западните щати в момента се поставят температурни рекорди, като в някои райони около границата с Мексико (Лос Анджелис, Лас Вегас, Финикс) жителите бяха предупредени по възможност да останат по домовете си, а ако им се налага да излизат, да пият повече вода.

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

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

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

Състоянието на глобалния лед също е динамично и картината на двата полюса не е еднаква

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

Научни новини: Лунни мисии, комети и климатични промени

Площ на ледената покривка (над 15% лед) на Южния полюс към 22 март 2026 г. Данни: NSIDC Sea Ice Index v4

Уви, северната ледена шапка не е в толкова добро състояние.

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

Научни новини: Лунни мисии, комети и климатични промени

Площ на ледената покривка (над 15% лед) на Северния полюс към 22 март 2026. Данни: NSIDC Sea Ice Index v4

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

Ново изследване показва, че всъщност отделеното количество желязо е няколко пъти по-малко, отколкото се предполагаше до момента. Оказва се, че повечето желязо всъщност идва от дълбоките океански води и от отмиване на седименти, а едва 10% се освобождават от леда. Хипотезата на учените е, че благодарение на образуването на течен слой между леда и скалите под него, железните оксиди преминават по-лесно във водата и така могат да бъдат отмити от вода, която навлиза през пукнатини в леда.

Вероятно подхранването на фитопланктона нямаше да компенсира топенето на леда, но все пак идеята за това даваше известна утеха. За съжаление, към момента е почти сигурно, че ще подминем заложената в Парижкото споразумение цел за ограничаване на затоплянето в рамките на века до 1,5°C над температурите преди индустриализацията. Въпросът е с колко градуса ще надвишим тази цел.

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

***

Post Syndicated from Тоест original https://www.toest.bg/69c0f6518481630001498c9d/

***

Впечатлен от предположението че светът веднъж бил безбрежен
криел се в нощта
Спомняйки си че той е човекът а книгата привидение оставил надеждата
да стъпи на брега
Слязъл от прогнилия сал взирал се в мрака без да знае дали някъде там грее
крехък пламък на свещ

 

Никола Маринов

Никола Маринов (р. 1988) завършва философия в СУ „Св. Климент Охридски“. Автор е на стихосбирката „Тигърът поиска, човекът обеща“ (2019) и сборника с разкази „Изход на видовете“ (2021). Публикува стихотворения, разкази и критика в Литературен вестник. Негова музика е издадена в лейбъла mahorka.org 

Според Екатерина Йосифова „четящият стихотворение сутрин… добре понася другите часове“ от деня. Убедени, че поезията държи умовете ни будни, а сърцата – отворени, в края на всеки месец ви предлагаме по едно стихотворение. Защото и в най-смутни времена доброто стихотворение е добра новина.

Рецепта за домашен бульон

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/bulion/

Преди време пробвах рецепти за френска лучена супа и осъзнах колко е важен бульонът. Първата ми не стана добре по няколко причини, но основната беше, че използвах купен бульон включително кубчета. Затова реших да направя свой. Оказа се учудващо лесно и евтино. Споделих с няколко души рецептата си и затова реших да я опиша тук да е по-лесно. Базирах я на тези два клипа от шеф Жан-Пиер за пилешки и телешки с промени от други рецепти.

Продукти

  • Месо и кокали – части или цели пилешки бутчета или пиле, телешко рагу, кокали с костен мозък
  • 3-4 големи глави лук или 5-6 малки
  • Моркови, целина и по желание пащърнак, праз и малко чушки
  • 100 грама масло и 50 гр. зехтин
  • Връзка магданоз, дафинов лист, черен пипер на зърна
  • По желание доматена паста

Процес на приготвяне

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

Когато събера 2-3 килограма, ги използвам за бульон. Само ги оставям да се размразят за около час. За последния път намерих много намалени пилешки бутчета и взех 4-5. Може да използвате и цяло пиле, ако намерите някъде на промоция. За телешки бульон купувам като намеря евтино рагу. По месарниците има и телешки кокали с костен мозък. Аз поръчах от Meat Revolution, но има на много места по-евтини. Независимо от какво месо го правите, слагате го в тава и го печете на грил функцията на 240 градуса докато се запече добре. Внимавайте да не загори, защото ще се отрази на вкуса на бульона.

Междувременно нарязвате лука на едро по дължина (от корена нагоре) и го карамелизирате. За целта загрявате около 100 грама масло (каквото и да е) и още поне 50 гр. зехтин в голям тиган. Като видимо е загряло без да загаря добавяте лука и намалете котлона на средно ниво. През 2-3 мин. бъркайте да не загори и да се разпредели топлината равномерно. Колкото по-дълго го правите, толкова по-карамелиран ще стане.

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

Накрая добавяте всичко в тенджера. Колкото по-голяма имате, толкова по-добре. Аз имам, за съжаление, само две по 6 литра и трябваше да използвам тях. Сложих ги на два котлона, макар единият да беше по-малък от тенджерата и разпределих зеленчуците и месото. Добавих измит магданоза както е на цели стръкове, няколко листа дафинов лист и по 10-тина зърна черен пипер.

Всичко това направих вечерта след вечеря та бях готов тъкмо към 11 часа когато започва нощната тарифа. Напълних вода почти до горе на тенджерите, затворих плътно капака и пуснах да заври. Като даде първи индикации, че завира, намалих котлона на минимум. След 30 мин. проверих дали още бълбука леко и увеличавам. Целта не е да кипи, а съвсем леко да къкри.

Оставам го така цяла нощ. Колкото по-дълго, толкова по-добре, но е хубаво да е поне няколко часа. Моят котлон има навика да спира след 5-6 часа, което е достатъчно. Следете първия път обаче да не изкипи в началото докато свикнете на какво ниво да оставяте котлоните.

На сутринта прецеждам през сито бульона в друг съд и го затварям в стерилизирани буркани (обливам ги с вряла вода няколко пъти и отделно капачките). Аз използвам такива с винт от лютеница и кисело мляко. Тях изварявам за 5 мин. – в моя случай по 4-5 в същите тенджери и ги обръщам да изстинат.

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

Вариации

В много рецепти добавят доматена паста към месото докато го пекат. Това определено добавя вкус, включително към бульона. Забелязах обаче, че при мен вместо да се запича месото добре, изгаря доматената паста. Отделно предпочитам бульона да няма домати в случай, че искам да го използвам за рецепти като ризото.

Ще забележите, че никъде не съм писал за сол и чесън. Причината е, че нямате нужда от сол за консервиране, тъй като затваряте в буркани. По-добре е да оставите безсолно и да добавяте колкото е нужно в крайната манджа. Същото за чесъна – ако го сложите в бульона ще го има във всичко, което готвите. Може да добавяте всякакви подправки, но най-добре е да са зелени на стръкове.

Ако искате чист пилешки или телешки бульон, няма нужда да добавяте каквито и да е зеленчуци. Добра идея е пак да запечете месото и да добавите подправки като дафинов лист и черен пипер. Ще имате просто нужда от доста повече месо и кости. Веднъж пък направих само зеленчуков бульон. Тогава пропуснах месото и добавих повече и различни зеленчуци.

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

Цена и време

8-10 големи буркана с пилешки бульон сметнах, че ми излизат около 10 евро. За телешкия е малко повече. Всичко може да е много по-евтино и вкусно, ако го правите лятно време, когато зеленчуците са по-свежи и намерите месо и кокали на оферта. Основната цена е във времето, тъй като трябва да се занимавате вечер с рязане и бъркане, а сутринта със затваряне на буркани. На мен ми отнема два часа вечерта и два часа сутринта. Ако минавам втора вода – малко повече. Струва си обаче от гледна точка на вкуса.

Бонус

Загрявате препълнена супена лъжица масло в касеролче и добавяте 3 супени лъжици брашно. Бъркате докато загрее 30 секунди и изливате плавно буркан телешки бульон. Бъркате без прекъсване и получавате прекрасен гъст сос за печено место. Само добавете сол и черен пипер на вкус.

С по 3 буркана телешки и пилешки бульон може да направите френска лучена супа. Покрай точно нея започнах да правя бульони и последната ми най-накрая се получи прекрасна. Следвам рецептата от това видео на шеф Жан-Пиер. Само не забравяйте да не слагате зелените части на праза, не пропускайте брашното и добре да карамелизирате лука.

Ще се радвам споделите опит, ако сте пробвали рецептата и допълнителни идеи, ако сте забелязали нещо полезно.

Mastodon Stories for systemd v260

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/mastodon-stories-for-systemd-v260.html

On March 17 we released systemd v260 into the wild.

In the weeks leading up to that release (and since then) I have posted
a series of serieses of posts to Mastodon about key new features in
this release, under the
#systemd260
hash tag. In case you aren’t using Mastodon, but would like to
read up, here’s a list of all 21 posts:

I intend to do a similar series of serieses of posts for the next systemd
release (v261), hence if you haven’t left tech Twitter for Mastodon yet, now is
the opportunity.

My series for v261 will begin in a few weeks most likely, under the
#systemd261
hash tag.

In case you are interested, here is the corresponding blog story for
systemd v259,
here for
v258,
here for
v257,
and here for
v256.

The collective thoughts of the interwebz