The PostgreSQL project has been
chugging along for decades; in that time, it has become a thriving open-source
project, and its participants have learned a thing or two about what works in
attracting new contributors. At FOSDEM 2026, PostgreSQL contributor Claire
Giordano shared some of the lessons learned and where the project is still
struggling. The lessons might be of interest to others who are thinking about
how their own projects can evolve.
Security teams have been talking about alert fatigue for years. And yet, for many SOCs, the problem isn’t getting better. It’s getting worse.
As environments expand across cloud, SaaS, identity, and legacy systems, analysts are flooded with signals that all demand attention but rarely arrive with enough context to act quickly. Staffing shortages only amplify the issue. The result is a SOC stuck reacting to noise instead of responding to real risk.
Recent industry research reinforces what analysts already know. False positives remain one of the top challenges in detection and response, and many analysts encounter low-value alerts so frequently that it slows investigations and contributes directly to burnout. Alert fatigue isn’t just an efficiency problem. It’s an operational risk.
Why alert fatigue persists, and why it’s not your fault
Alert fatigue isn’t a reflection of weak analysts or underperforming teams. It’s the outcome of security models that haven’t kept pace with modern complexity.
Traditional SIEM approaches were built for a different era. Rule-heavy detections, manual enrichment, siloed tools, and flat log views force analysts to spend valuable time stitching together context before they can even begin investigating. Even experienced analysts end up waiting for answers instead of acting on them.
Modern SOCs need a different approach. One that prioritizes analyst efficiency, reduces friction, and brings clarity to investigations from the start.
Four moves that change how SOCs operate
In the eBook, we break down four practical shifts that high-performing SOCs are making to move beyond alert fatigue:
Automate the noise with AI-assisted classification and enrichment so analysts can focus on what truly matters
Investigate smarter with unified context, eliminating unnecessary pivots between tools
Shrink the response cycle using guided workflows that make investigations faster and more consistent
Gain confidence in coverage by understanding risk across the entire attack surface, not just known assets
These aren’t theoretical ideas. They’re grounded in real-world SOC workflows and designed to help analysts move faster without sacrificing control or trust.
A look inside a real SOC investigation
One of the most impactful sections of the eBook walks through a familiar scenario: a phishing or business email compromise investigation.
Instead of listing tools or features, it shows what the investigation actually feels like for an analyst. From the frustration of waiting on data in a traditional workflow to the clarity that comes when context is surfaced early and answers arrive faster. It’s a reminder that efficiency isn’t about removing analysts from the loop. It’s about removing the friction that slows them down.
From overwhelmed to in command
At its core, the playbook is built on a simple principle. Modern SOC efficiency comes from reducing noise, unifying context, and guiding investigations with AI-assisted workflows, all while keeping analysts firmly in control.
If you’re responsible for detection and response, or if you’re feeling the strain of alert fatigue in your SOC, this eBook is designed for you.
Every neocloud in the market right now is winning or losing on the same battlefield: GPUs. Availability, performance, price per hour. That’s the game, and it’s the right game to play.
But there’s a problem compounding underneath it, one that doesn’t show up in benchmark reports or investor decks, and one that customers will eventually force platforms to confront—neoclouds need highly available, performant storage so that GPUs are never waiting on data.
Neocloud customers need more than compute
Cloud storage isn’t adjacent to what neoclouds sell—for buyers, it’s the difference between a complete platform and a partial one. Neocloud customers need:
Somewhere to put a 10PB training dataset before it touches WEKA, VAST, or DDN boxes
Persistent storage for model checkpoints between training runs
A place for production inference pipelines to pull weights from at scale, fast enough that GPU nodes aren’t sitting idle waiting on data
Most platforms know this. The ones that are honest about it will also tell what happened when they tried to solve it: Engineering sprints planned around storage tooling that competed directly with GPU roadmap work. Ops overhead for infrastructure that customers take for granted when it’s working and blame the platform for when it’s not. Capital allocated to storage hardware and the teams to manage it.
The platforms that figured this out first didn’t hire their way through the problem. They stopped building storage and started shipping it.
Introducing B2 Neo
That’s the insight behind Backblaze B2 Neo. We built it in direct collaboration with the neocloud operators already utilizing Backlaze in production. The result is a white label cloud storage backbone that neoclouds can launch as a native extension of their platform. Here’s what that means in practice:
Up to 1Tbps throughput: Storage that keeps GPU clusters fed and AI workflows moving without becoming the bottleneck.
Launch under your own brand: Branded endpoints, partner-controlled pricing, and a native customer experience that keeps the platform front and center.
API-driven provisioning: Provision accounts, manage permissions, and handle billing through existing platform tools without a separate console or manual setup.
17 years of operational maturity and exabyte scale expertise: Enterprise durability and reliability that customers expect, operated by Backblaze so internal teams don’t have to.
It doesn’t require a storage team. It doesn’t compete with the GPU roadmap. And it doesn’t route customers away from neocloud platforms where their workflows slowly migrate away.
Already in production with leading platforms
Multiple neoclouds are already using B2 Neo. It’s infrastructure that’s already handling AI training workloads, high performance compute (HPC) pipelines, and media delivery at scale and the platforms already running it are direct about why they made the call.
One global edge services platform, after a rigorous technical and business evaluation, put it this way: Their customers were demanding cost-effective yet performant storage as their AI business scaled and Backblaze gave them the ability to deliver cloud object storage as a native extension of their own platform without taking focus away from their roadmap.
Rob Strechay, Principal Analyst at Smuget & theCUBE Research, framed it simply:
With B2 Neo as a first-party service offering to neoclouds, I see the advantage for those organizations of being able to turn on cloud storage without the toil and expense of building it themselves. It is a near-instant value-add offering, helping their customers control costs and achieve the ROI of AI faster.
The question for the rest of the market is how many more quarters of DIY storage ops—or hyperscaler dependency—they can absorb while competitors ship that outcome instead.
B2 Neo is available now. If you’re building a neocloud and storage is either a distraction or a gap, I’d encourage you to talk to us.
Good article on password managers that secretly have a backdoor.
New research shows that these claims aren’t true in all cases, particularly when account recovery is in place or password managers are set to share vaults or organize users into groups. The researchers reverse-engineered or closely analyzed Bitwarden, Dashlane, and LastPass and identified ways that someone with control over the server—either administrative or the result of a compromise—can, in fact, steal data and, in some cases, entire vaults. The researchers also devised other attacks that can weaken the encryption to the point that ciphertext can be converted to plaintext.
This is where I plug my own Password Safe. It isn’t as full-featured as the others and it doesn’t use the cloud at all, but it’s actual encryption with no recovery features.
During Security Week 2025, we launched the industry’s first cloud-nativepost-quantum Secure Web Gateway (SWG) and Zero Trust solution, a major step towards securing enterprise network traffic sent from end user devices to public and private networks.
But this is only part of the equation. To truly secure the future of enterprise networking, you need a complete Secure Access Service Edge (SASE).
Today, we complete the equation: Cloudflare One is the first SASE platform to support modern standards-compliant post-quantum (PQ) encryption in our Secure Web Gateway, and across Zero Trust and Wide Area Network (WAN) use cases. More specifically, Cloudflare One now offers post-quantum hybrid ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) across all major on-ramps and off-ramps.
To complete the equation, we added support for post-quantum encryption to our Cloudflare IPsec (our cloud-native WAN-as-a-Service) and Cloudflare One Appliance (our physical or virtual WAN appliance that establish Cloudflare IPsec connections). Cloudflare IPsec uses the IPsec protocol to establish encrypted tunnels from a customer’s network to Cloudflare’s global network, while IP Anycast is used to automatically route that tunnel to the nearest Cloudflare data center. Cloudflare IPsec simplifies configuration and provides high availability; if a specific data center becomes unavailable, traffic is automatically rerouted to the closest healthy data center. Cloudflare IPsec runs at the scale of our global network, and supports site-to-site across a WAN as well as outbound connections to the Internet.
Quantum threats are not a “next decade” problem. Here is why our customers are prioritizing post-quantum cryptography (PQC) today:
The deadline is approaching. At the end of 2024, the National Institute of Standards and Technology (NIST) sent a clear signal (that has been echoed by other agencies): the era of classical public-key cryptography is coming to an end. NIST set a 2030 deadline for depreciating RSA and Elliptic Curve Cryptography (ECC) and transitioning to PQC that cannot be broken by powerful quantum computers. Organizations that haven’t begun their migration risk being out of compliance and vulnerable as the deadline nears.
Upgrades have historically been tricky. While 2030 might seem far away, upgrading cryptographic algorithms is notoriously difficult. History has shown us that depreciating cryptography can take decades: we found examples of MD5 causing problems 20 years after it was deprecated. This lack of crypto agility — the ability to easily swap out cryptographic algorithms — is a major bottleneck. By integrating PQ encryption directly into Cloudflare One, our SASE platform, we provide built-in crypto agility, simplifying how organizations offer remote access and site-to-site connectivity.
Data may already be at risk. Finally, “Harvest Now, Decrypt Later” is a present and persistent threat, where attackers harvest sensitive network traffic today and then store it until quantum computers become powerful enough to decrypt it. If your data has a shelf life of more than a few years (e.g. financial information, health data, state secrets) it is already at risk unless it is protected by PQ encryption.
The two migrations on the road to quantum safety: key agreement and digital signatures
Transitioning network traffic to post-quantum cryptography (PQC) requires an overhaul of two cryptographic primitives: key agreement and digital signatures.
Migration 1: Key establishment. Key agreement allows two parties to establish a shared secret over an insecure channel; the shared secret is then used to encrypt network traffic, resulting in post-quantum encryption. The industry has largely converged on ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) as the standard PQ key agreement protocol.
ML-KEM has been widely adopted for use in TLS, usually deployed alongside classical Elliptic Curve Diffie Hellman (ECDHE), where the key used to encrypt network traffic is derived by mixing the outputs of the ML-KEM and ECDHE key agreements. (This is also known as “hybrid ML-KEM”). Well over 60% of human-generated TLS traffic to Cloudflare’s network is currently protected with hybrid ML-KEM. The transition to hybrid ML-KEM has been successful because it:
stops “harvest-now, decrypt-later” attacks
does not require specialized hardware or specialized physical connectivity between client and server, unlike approaches like Quantum Key Distribution (QKD)
Because ML-KEM runs in parallel with classical ECDHE, there is no reduction in security and compliance as compared to the classical ECDHE approach.
Migration 2: Digital signatures. Meanwhile, digital signatures and certificates protect authenticity, stopping active adversaries from impersonating the server to the client. Unfortunately, PQ signatures are currently larger in size than classical ECC algorithms, which has slowed their adoption. Fortunately, the migration to PQ signatures is less urgent, because PQ signatures are designed to stop active adversaries armed with powerful quantum computers, which are not known to exist yet. Thus, while Cloudflare is actively contributing to the standardization and rollout of PQ digital signatures, the current Cloudflare IPsec upgrade focuses on upgrading key establishment to hybrid ML-KEM.
The U.S. Cybersecurity & Infrastructure Security Agency (CISA) recognized the nature of these two migrations in its January 2026 publication, “Product Categories for Technologies That Use Post-Quantum Cryptography Standards.”
Breaking new ground with IPsec
To achieve a SASE fully protected with post-quantum encryption, we’ve upgraded our Cloudflare IPsec products to support hybrid ML-KEM in the IPsec protocol.
The IPsec community’s journey toward post-quantum cryptography has been very different from that of TLS. TLS is the de facto standard for encrypting public Internet traffic at Layer 4 — e.g. from a browser to a content delivery network (CDN) — so security and vendor interoperability are at the forefront of its design. Meanwhile, IPsec is a Layer 3 protocol that commonly connects devices built by the same vendor (e.g. two routers), so interoperability has historically been less of a concern. With this in mind, let’s take a look at IPsec’s journey into the quantum future.
Pre-Shared Keys? Quantum key distribution?
RFC 8784, published in May 2020, was intended to be the post-quantum update to IPsec Internet Key Exchange v2 (IKEv2), which is used to establish the symmetric keys used to encrypt IPsec network traffic. RFC 8784 implies the use of either long-lived pre-shared keys (PSK) or quantum key distribution (QKD). Neither of these approaches are very palatable.
RFC 8784 proposes mixing a PSK with a key derived from Diffie Hellman Exchange (DHE), essentially running PSK in hybrid with DHE. This approach protects against harvest-now-decrypt-later attackers, but does not offer forward secrecy against quantum adversaries.
Forward secrecy is a standard desideratum of key agreement protocols. It ensures that a system is secure even if the long-lived key is leaked. The PSK approach in RFC 8784 is vulnerable to an harvest-now-decrypt-later adversary that also obtains a copy of a long-lived PSK, and can then decrypt traffic in the future (by breaking the DHE key agreement) once powerful quantum computers become available.
To solve this forward secrecy issue, RFC 8784 can instead be used to mix the key from the classical DHE with a freshly generated key derived from a QKD protocol.
QKD uses quantum mechanics to establish a shared, secret cryptographic key between two parties. Importantly, for QKD to work, the parties must have specialized hardware or be connected by a dedicated physical connection. This is a significant limitation, rendering QKD useless for common Internet use cases like connecting a laptop to a distant server over Wi-Fi. These limitations are also why we never invested in deploying QKD for Cloudflare IPsec. The U.S. National Security Agency (NSA), Germany’s BSI and the UK National Cyber Security Centre have also warned against relying solely on QKD.
But what about interoperability?
RFC 9370 landed in May 2023, specifying the use of hybrid key agreement rather than PSK or QKD. But unlike TLS, which only supports using post-quantum ML-KEM in parallel with classical DHE, this IPsec standard allows using up to seven different key agreements to run at the same time in parallel with classical Diffie Helman. Moreover, it doesn’t specify details about what these key agreements should be, leaving it up to the vendors to choose their algorithms and implementations. Palo Alto Networks, for example, took this seriously and built support for over seven different PQC ciphersuites into its next generation firewall (NGFW), most of which do not interoperate with other vendors and some of which have not yet been standardized by NIST.
Over the years, TLS has gone in the opposite direction, reducing the number of registered ciphersuites from hundreds in TLS 1.2, down to around five in TLS 1.3. This philosophy of reducing “ciphersuite bloat” is also in line with NIST’s SP 800 52 from 2019. The rationale for reducing “ciphersuite bloat” includes:
Improved interoperability across vendors and regions
Lower risk of attacks that exploit downgrades to weak ciphersuites
Lower risk of security problems due to misconfiguration
Lower risk of implementation flaws by reducing the size of the codebase
This is why we didn’t initially build support for RFC 9370.
Standards that are finally on the right track
It’s also why we were excited when the IPsec community put forth draft-ietf-ipsecme-ikev2-mlkem. This Internet-Draft standardizes PQ exchange for IPsec in the same way PQ key exchange has been widely deployed for TLS: hybrid ML-KEM. The new draft fills in the gaps in RFC 9370, by specifying how to run the ML-KEM as the additional key exchange in parallel with classical Diffie Hellman in IKEv2.
Now that this specification is available, we’ve moved forward with supporting post-quantum IPsec in our Cloudflare IPsec products.
Cloudflare IPsec goes post-quantum
Cloudflare IPsec is a WAN Network-as-a-Service solution that replaces legacy private network architectures by connecting data centers, branch offices, and cloud VPCs to Cloudflare’s global IP Anycast network.
With Cloudflare IPsec, Cloudflare’s network acts as the IKEv2 Responder, awaiting connection requests from an IPsec initiator, which is a branch connector device in the customer’s network. Cloudflare IPsec supports IPsec sessions initiated by branch connectors that include our own Cloudflare One Appliance, along with branch connectors from a diverse set of vendors, including Cisco, Juniper, Palo Alto Networks, Fortinet, Aruba and others.
We’ve implemented production hybrid ML-KEM support in the Cloudflare IPsec IKEv2 Responder, as specified in draft-ietf-ipsecme-ikev2-mlkem. The draft requires a first key exchange to run using a classical Diffie Helman key exchange. The derived key is used to encrypt a second key exchange that is run using ML-KEM. Finally, the keys derived by the two exchanges are mixed and the result is used to secure the data plane traffic in IPsec ESP (Encapsulating Security Payload) mode. ESP mode uses symmetric cryptography and is thus already quantum safe without any additional upgrades. We’ve tested our implementation against the IPsec Initiator in the strongswan reference implementation.
You can see the ciphersuite used in the IKEv2 negotiation by viewing the Cloudflare IPsec logs.
We chose to implement hybrid ML-KEM rather than “pure” ML-KEM, i.e. only ML-KEM without DHE running in parallel, for two reasons. First, we’ve used hybrid ML-KEM across all of our other Cloudflare products, since this is the approach adopted across the TLS community. And second, it provides a “belt-and-suspenders” security: ML-KEM provides protection against quantum harvest-now-decrypt-later attacks, while DHE provides a tried-and-true algorithm against non-quantum adversaries.
An invitation for interoperability
The full value of this implementation can be realized only via interoperability. For this reason, we are inviting other vendors that are building out support for IPsec Initiators in their branch connectors per draft-ietf-ipsecme-ikev2-mlkem to test against our Cloudflare IPsec implementation. Cloudflare customers looking to test out interoperability with third-party branch connectors while we are in closed beta can get in touch with us by reaching out to your account team at [email protected]. We plan to GA and build out interoperability with other vendors as more begin to come online with support for draft-ietf-ipsecme-ikev2-mlkem.
Quantum-safe hardware: the Cloudflare One Appliance
Many of our customers purchase their branch connector (hardware or virtualized) from Cloudflare, rather than a third-party vendor. That’s why the Cloudflare One Appliance — our plug-and-play appliance that connects your local network to Cloudflare One — has also been upgraded with post-quantum encryption.
Cloudflare One Appliance does not use IKEv2 for key agreement or session establishment, opting instead to rely on TLS. The appliance periodically initiates a TLS handshake with the Cloudflare edge, shares a symmetric secret over the resulting TLS connection, then injects that symmetric secret into the ESP layer of IPsec, which then encrypts and authenticates the IPsec data plane traffic. This design allowed us to avoid building out IKEv2 Initiator logic, and makes the Connector easier to maintain using our existing TLS libraries.
Thus, upgrading Cloudflare One Appliance to PQ encryption was just a matter of upgrading TLS 1.2 to TLS 1.3 with hybrid ML-KEM — something we’ve done many times on different products at Cloudflare.
How do I turn this on? And what does it cost?
As always, this upgrade to Cloudflare IPsec comes at no extra cost to our customers. Because we believe that a secure and private Internet should be accessible to all, we’re on a mission to include PQC in all our products, without specialized hardware, at no extra cost to our customers and end users.
Customers using the Cloudflare One Appliance obtained this upgrade to PQC in version 2026.2.0 (released 2026-02-11). The upgrade is pushed automatically (with no customer action required) according to each appliance’s configured interrupt window.
For customers using Cloudflare IPsec with another vendor’s branch connector appliance, we will be interoperating with these once more support for draft-ietf-ipsecme-ikev2-mlkem comes online. You can also contact us directly to get access to closed beta and request that we interoperate with a specific vendor’s branch connector by reaching out to your account team at [email protected].
The full picture: post-quantum SASE
The value proposition for a post-quantum SASE is clear: organizations can obtain immediate end-to-end protection for their private network traffic by sending it over tunnels protected by hybrid ML-KEM. This protects traffic from harvest-now-decrypt-later attacks, even if the individual applications in the corporate network are not yet upgraded to PQC.
The diagram above shows how post-quantum hybrid ML-KEM is offered in various Cloudflare One network configurations. It includes the following on-ramps:
Cloudflare IPsec on-ramp (as described in this blog)
The diagram below highlights a sample network configuration that uses the Cloudflare One Client on-ramp to connect a device to a server behind a Cloudflare One Appliance offramp. The end user’s device connects to the Cloudflare network (link 1) using MASQUE with hybrid ML-KEM. The traffic then travels across Cloudflare’s global network over TLS 1.3 with hybrid ML-KEM (link 2). Traffic then leaves the Cloudflare network over a post-quantum Cloudflare IPsec link (link 3) that is terminated at a Cloudflare One Appliance appliance. Finally it connects to a server inside the customer’s environment. Traffic is protected by post-quantum cryptography as it travels over the public Internet, even if the server itself does not support post-quantum cryptography.
Finally, we note that traffic that on-ramps to Cloudflare One and then egresses to the public Internet can also be protected by our post-quantum Cloudflare Gateway, our Secure Web Gateway (SWG). Here’s a diagram showing how the SWG works:
As discussed in an earlier blog post, our SWG can already support hybrid ML-KEM on traffic from SWG to the origin server (as long as the origin supports hybrid ML-KEM), and on traffic from the client to the SWG (if the client supports hybrid ML-KEM, which is the case for most modern browsers). Importantly, any traffic that onramps to the SWG via a device that has Cloudflare One Client installed is still protected with hybrid ML-KEM — even if the web browser itself does not yet support post-quantum cryptography. This is due to the post-quantum MASQUE tunnel that the Cloudflare One Client establishes to Cloudflare’s global network. The same is true of traffic that onramps to the SWG via a post-quantum Cloudflare IPsec tunnel.
Putting it all together, Cloudflare One now offers post-quantum encryption on our TLS, MASQUE and IPsec on-ramp and off-ramps, and for private network traffic, and to traffic that egresses to the public Internet via our SWG.
The future is quantum-safe
By completing the post-quantum SASE equation with Cloudflare IPsec and the Cloudflare One Appliance, we have extended post-quantum encryption across all our major on-ramps and off-ramps. We have intentionally chosen the path of interoperability and simplicity — the hybrid ML-KEM approach that the IETF and NIST have championed, rather than locking our customers into proprietary implementations, “ciphersuite bloat,” or unnecessary hardware upgrades.
This is the promise of Cloudflare One: a SASE platform that is not only faster and more reliable than the legacy architectures it replaces, but one that provides post-quantum encryption. Whether you are securing a remote worker’s browser or a multi-gigabit data center link, you can now do so with the confidence that your data is protected from harvest-now-decrypt-later attacks and other future-looking threats.
You can sign up here to get a full demo of our post-quantum capabilities across the Cloudflare One SASE platform. We are proud to lead the industry into this new era of cryptography, and we invite you to join us in building a scalable, standards-compliant, and post-quantum Internet.
Linus has released 7.0-rc1 and closed the
merge window for this development cycle. “You all know the drill by
now: two weeks have passed, and the kernel merge window is closed.“
„Скръбта е твар перната“ (по великолепния роман на Макс Портър), точно както „Любовта е немирна птица“ (по „Кармен“ на Бизе). И скръбта, и любовта ни съпътстват през целия ни живот – от мига, в който се отделим от майчиното тяло, до мига, в който телата ни се превърнат в прах. И скръбта, и любовта обаче са дарове крехки, които лесно могат да бъдат пропилени, прокудени наистина като птици, а с тях и възможността, дадена ни да се самолекуваме, да преживяваме раната, през която влизаме в света и в езика.
В прочутото си есе от 1917 г. „Траур и меланхолия“ Зигмунд Фройд описва човешката реакция при загуба на любим човек или идеал. И проследява сложния и нелек път, по който именно траурът ще върне скърбящия субект на страната на живота, ще го разграничи от изгубения обект, ще му даде възможност да продължи напред. Това е процес, осеян с подводни камъни, който невинаги върви по план и би могъл да доведе до отключване на меланхолия, депресия и други психични страдания. Да ни превърне във вечни пленници на загубата. И на скръбта. Траурът всъщност е грижа за душата и възпрепятстването му крие огромни рискове.
През последните две седмици станахме свидетели и участници в една всеобща мрачна демонстрация на това колко е трудно да скърбим. И колко непосилно е за нас да уважаваме начините, по които другите скърбят. В голяма степен го дължим на редица държавни институции, които с безотговорното си (бих допълнила и безпросветно) поведение пред медиите ни нанесоха колективна травма и откриха фронт за идентификации и деидентификации, за поляризиране в обществото. Всичко това – удобно и навреме. Точно преди изборите.
Нормализирането на ситуацията в момента изглежда трудно постижимо и изисква усилия не само от институциите, отговорни за тази ситуация, но и от всички нас. Защото освен публичната, видимата „сцена“, на която се играе тази древногръцка по мащаба си трагедия, всеки от нас има своята вътрешна, смълчана „сцена“, на която се извършват душевните ни кръвопролития. Без да прогледнем за тях, катарзисът е невъзможен.
За да постигнем зрелост в отношението ни като общество към случая „Петрохан“, а и към всеки случай, от който (без)отговорни представители на институции и кликбейт медии извайват сензационни сюжети, е необходимо все по-умно и предпазливо да се ориентираме в морето от трудно проверима информация. Затова колко уязвими сме пред заливащата ни медийна пяна, сред десетките конкуриращи се за място в кошмарите ни конспиративни теории, пише Александър Драганов в есето си „Има ли компас в информационния океан?“.
Текстът на Александър се явява естествено продължение на други два скорошни анализа от предишните ни броеве, които има смисъл да препрочетем и тази седмица:
Въпросът за паралелните вселени (или балони, ако повече ви харесва), в които съществуваме, не опира само до начина, по който възприемаме и обработваме информацията за света около нас. В образователната сфера например също има здрачни, неосветени от държавата зони, които – както напоследък показаха и петроханският случай, и самоубийството на Билгин – стават видими само покрай поредната трагедия, свързана с деца в училищна възраст. Повече за алтернативните форми на начално, основно и средно образование, както и за отсъствието на ангажимент и грижа от страна на държавните образователни политики към тях може да научите от анализа на Светла Енчева „Паралелните образователни реалности в България“.
А според Светла далечните последствия от този престъпен тип незаинтересованост могат да бъдат наистина зловещи:
В каквато и форма да се обучава детето, няма гаранция, че държавата ще се загрижи за най-добрия му интерес. На базата на практиката можем да предположим, че вероятността да не се загрижи е по-голяма. Това е зле не само за децата, а и за самата държава – в нея съществуват алтернативни вселени, за които тя си няма и понятие. Тази държава не разбира откъде се пръкват „локалите“, защо деца се самоубиват и защо наказанията не ги правят по-добри. Тя в един момент може и да се сдобие с фундаменталисти и терористи (все едно дали обучавани в училище, или вкъщи) и да се чуди откъде ѝ е дошло.
Продължаваме с друга важна тема, за която обикновено си даваме сметка отново когато вече е късно – системата на пътната безопасност и колко много елементи от различни редове включва тя, за да е в действителност работеща. За управление на риска, а не на последствията, които твърде често са изгубени човешки животи, настоява в експертната си статия „Пътната безопасност отвъд знаците“ Симеон Иванов от „Екипът на София“.
Подобна сложна система от условия и правила за безопасност обикновено се изгражда и в социалната минивселена на платформите за запознанства. Тази седмица наш водач из онлайн стъргалото на мюсюлманските сайтове е Атанас Шиников, който ни разказва за практическата функционалност, но и за моралните гаранции за съществуването на въпросните форуми, стимулиращи срещи, раздели, но и трайни партньорства. Повече за непознатите у нас Muzz, Muslima, Salams, Baklava и пр. четете в „Тиндър/Миндър, халал, сайтове и приложения за запознанства“.
Съвсем в тон с криминалната лента, която денонощно се прожектира в главите ни през последните седмици, в рубриката „На второ четене“ Антония Апостолова ни представя роман за убийство: „Нощта на професор Андершен“ от норвежкия писател Даг Сулста. Но както се оказва, това не е скандинавска кримка, тъй като не престъплението и неговото разкриване са в основата на сюжета, а вътрешните колебания и сложни умишления на единствения свидетел.
Ако не сте били свидетели на живо на видеопоредицата ни, то сега може да поправите тази грешка, като се върнете към седми епизод на „Тоест разговаряме“ с Владислав Севов, в който водещият на редовната ни рубрика „Научни новини“ Михаил Ангелов коментира границите и възможностите на съвременната наука – от генетичното редактиране с CRISPR, през космическите изследвания и ваксините,до бъдещето на храните и добива им. Освен да гледате целия епизод в нашия YouTube канал, вече може да го чуете и като аудиозапис в SoundCloud.
За феновете на рубриката, които са проследили епизода на живо, има специален бонус – Михаил отговаря на допълнителен зрителски въпрос, свързан с промените в начините, по които ще отглеждаме храната си в следващите десет години.
Много по-кратък времеви хоризонт, само два-три месеца, има новото служебно правителство на България начело с Андрей Гюров, което положи клетва в четвъртък и от което се очаква да осигури гладкото провеждане на честни парламентарни избори. Според Емилия Милчева правителството на Гюров е
скроено по изпитаната сватбена традиция – нещо старо, нещо ново, нещо назаем и нещо синьо; засега е трудно да се прецени кое е в повече – старото, новото или синьото.
При всички положения обаче, твърди Емилия, волята на декемврийските протести срещу Борисов и Пеевски е чута и оттук нататък остава да видим дали това правителство ще се окаже „мост към нови коалиции“. Междувременно експресната оставка на вицепремиера Стоил Цицелков показа, че този кабинет няма да се размине с натиск от определени политически формации, както и от някои медии. А министърът на правосъдието Андрей Янкулов побърза да свика Висшия съдебен съвет на 26 февруари, за да се избере нов временен главен прокурор и да се реши веднъж завинаги проблемът с нелегитимно заемащия поста Сарафов. Повече по динамично развиващата се тема с новия служебен кабинет четете в „Боят настана“.
Над угнетяващите купчини от сериозни и ултрасериозни теми, които ни притискат и задушават от всички страни, и в новия 41-ви епизод Е.Т. прелита като пакостливия Пък, призовава към бойна готовност и за пореден път показва, че има много възможни интонации, с които да изречем гнева, болката и омерзението си.
И за да се върнем там, откъдето тръгнахме, а именно при трудното изкуство да скърбим и да уважаваме чуждата скръб, от сърце ви препоръчвам филма на Клинт Бентли „Сънища с влакове“ (по едноименния роман на Денис Джонсън). Пожелавам ви спокойна и светла събота с едноименната песен от филма на Ник Кейв и Брайс Деснър:
Благодарим ви за подкрепата и грижата! Без тях това, което правим, не би имало смисъл.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.