Post Syndicated from Explosm.net original https://explosm.net/comics/fifth-doctor
New Cyanide and Happiness Comic
A Day in the Life of an MDR Analyst: Inside the Modern SOC
Post Syndicated from Emma Burdett original https://www.rapid7.com/blog/post/it-day-in-the-life-mdr-analyst-inside-the-modern-soc
What actually happens inside a SOC when an incident unfolds? Most teams see the alerts and the outcomes, but the decision-making in between is often less visible.
At the Rapid7 2026 Global Cybersecurity Summit, the signature session Inside the Modern SOC: Who Carries You Through an Incident takes a different approach. Rather than focusing on tools or dashboards, it follows a real-world incident from the perspective of the people responsible for investigating and containing it.
The session walks through how modern MDR teams operate under pressure, drawing on real experience across cloud, identity, and on-prem environments. Led by Karl Lankford, Senior Director, Sales Engineering, Rapid7, the discussion brings in perspectives from across the SOC, including incident response and detection, to show how teams work together when it matters most.
Structured around a full incident lifecycle, the walkthrough begins with the initial signal and moves through triage and investigation, following the decisions that shape the outcome. The focus is not on theory but on how incidents are handled in practice, from background and context through to the final result.
What stands out is how much of the process depends on judgment. Alerts are only the starting point. From there, analysts are working to understand context, assess risk, and decide what matters most in the moment. This includes identifying compromised identities, understanding how attackers move across environments, and coordinating response across multiple systems.
The session also highlights how quickly these decisions need to be made. As shown in the high-level timeline, attackers can move from initial access to broader compromise across cloud and on-prem systems in a matter of minutes, which leaves little room for hesitation or uncertainty.
Throughout the walkthrough, the focus stays on what carries organizations through an incident. Detection plays a role, but outcomes are shaped by coordination, tradeoffs, and the ability to act with clarity under pressure. The session also explores how visibility across environments, combined with human-led response, helps teams connect signals and act before impact occurs.
For practitioners, SOC leaders, and teams evaluating MDR, this session offers a grounded view of how modern incident response works under real conditions. It shows what happens between the alert and the outcome, and why that gap is where the real value lies. Watch the full session to follow the investigation step by step and see how MDR teams carry organizations through real incidents.
Building highly available Oracle databases with Amazon FSx for NetApp ONTAP
Post Syndicated from Vignyanand Penumatcha original https://aws.amazon.com/blogs/architecture/building-highly-available-oracle-databases-with-amazon-fsx-for-netapp-ontap/
Oracle databases power mission-critical enterprise applications, making their continuous availability essential for business operations. Traditional Oracle high availability (HA) solutions require complex clustering software, expensive shared storage arrays, and specialized database administration teams. These conventional approaches often introduce single points of failure while demanding significant operational overhead.
Modern cloud architectures offer a transformative approach that combines Amazon FSx for NetApp ONTAP (FSxN) with Amazon EC2 Auto Scaling groups, automated AMI creation, AWS Lambda-driven orchestration, and AWS Systems Manager Parameter Store (SSM Parameter). This solution removes traditional Oracle HA complexities while delivering enterprise-grade availability, automated recovery, and makes sure new instances launch with the latest Oracle configuration.
This post shows how to build a highly available Oracle database architecture using FSxN shared storage, Auto Scaling groups with dynamic AMI updates, and serverless orchestration to help reduce recovery times with current configurations.
Solution overview
The solution uses multiple AWS services working together to create a comprehensive high availability architecture. FSxN Multi-AZ provides persistent shared storage spanning availability zones for Oracle database files, software, and configurations, so that data remains accessible when EC2 instances are replaced. Auto Scaling groups deliver automated instance lifecycle management with the latest AMI configurations, so failed instances are quickly replaced with identical configurations that can immediately access the existing Oracle database files on FSxN. AWS Backup creates AMIs that capture the latest Oracle host configurations including patches and settings, preserving the complete server state for consistent deployments. AWS Lambda extracts the AMI ID from backup recovery points and updates the SSM Parameter, orchestrating the entire configuration management workflow. Systems Manager Parameter Store stores the current AMI ID for Auto Scaling group launch templates, so new instances always launch with the most recent configuration and can immediately connect to the Oracle database on shared storage.
The following diagram shows the complete architecture with all AWS services and their interactions:
Key benefits include:
- Recovery Time Objective (RTO): Can help achieve 2–5 minutes with latest Oracle configuration
- Recovery Point Objective (RPO): Near-zero through synchronous Multi-AZ replication
- Configuration consistency: New instances launch with identical Oracle host setup
- Automated AMI management: Scheduled AMI creation with Parameter Store updates
Walkthrough
This walkthrough demonstrates implementing Oracle HA using Amazon FSx for NetApp ONTAP shared storage, AWS Backup-driven AMI creation, Lambda orchestration, and Auto Scaling groups with Parameter Store integration for configuration consistency and automated failover.
Prerequisites
For this walkthrough, you should have the following prerequisites:
- An AWS account with appropriate permissions for Amazon FSx, Auto Scaling, EC2, Lambda, and Systems Manager
- A VPC with subnets in at least two Availability Zones
- Oracle database software
Keep in mind that customers are responsible for their own Oracle licensing compliance.
- An EC2 instance with Oracle database installed and configured
- AWS Identity and Access Management (IAM) roles for AMI creation and cross-service communication
- Basic knowledge of Oracle database administration and AWS automation
Assumptions
This post is a conceptual illustration of the architecture. Your specific implementation will vary based on your VPC layout, Oracle version, storage requirements, and organizational security policies.
We assume the reader is familiar with:
- Creating and configuring Amazon FSx for NetApp ONTAP file systems through the AWS console
- iSCSI concepts including initiators, targets, and multipath I/O
- Oracle database startup and shutdown procedures
- AWS Backup, Lambda, and Auto Scaling group fundamentals
For detailed step-by-step instructions on specific AWS services, refer to the additional resources section.
Step 1: Create an Amazon FSx for NetApp ONTAP file system
FSxN Multi-AZ provides the persistent shared storage foundation for this architecture. Unlike Amazon Elastic Block Store (Amazon EBS) volumes, which are bound to a single AZ, FSxN Multi-AZ replicates data synchronously across two AZs with automatic failover. This means that when an EC2 instance is replaced (whether in the same AZ or a different one), the new instance can immediately access the existing Oracle database files without restoring from backup.
To create the file system, navigate to the Amazon FSx console and select Amazon FSx for NetApp ONTAP as the file system type.
The critical configuration choice is selecting Multi-AZ deployment, which places an active file server in one AZ and a standby in another.
FSxN console showing Multi-AZ deployment type selection with preferred and standby subnets in separate availability zones.
After the file system is created, you need to set up a Storage Virtual Machine (SVM), which acts as a logical storage container providing data access to your Oracle instances. The SVM creation is done from the FSx console under your file system’s details.With the SVM in place, the next step is configuring iSCSI access. FSxN exposes iSCSI endpoints—these are IP addresses (one per AZ) that your EC2 instances use to connect to the storage over the iSCSI protocol. You can find these endpoint addresses in the FSx console under your SVM’s Endpoints tab.
SVM Endpoints tab showing iSCSI endpoint IP addresses for each availability zone. These addresses are used in the EC2 instance’s iSCSI discovery configuration.
The iSCSI setup involves creating iGroups (which define which EC2 instances can access the storage) and LUNs (logical storage units mapped to those groups) through the NetApp ONTAP CLI. On the EC2 side, you configure the iSCSI initiator to discover and connect to the FSxN endpoints, then mount the resulting block devices. Using multipath I/O with both endpoints makes sure that Oracle data remains accessible even during an AZ failover. For detailed iSCSI configuration steps, see mounting iSCSI LUNs on Linux clients.
A dedicated security group is required for FSxN access. At minimum, the security group must allow inbound traffic on ports 111 (NFS portmapper), 635 (NFS mountd), 2049 (NFS), 3260 (iSCSI), 4045–4046 (NFS lock), 443 (HTTPS for management), and 22 (SSH for ONTAP CLI). Restrict the source to only your Oracle EC2 instances’ security group.
Step 2: Set up AWS Backup for EC2 instance protection
AWS Backup captures the complete state of your Oracle EC2 instance. The key design choice here is using tag-based resource selection rather than specifying instance IDs directly. Because Auto Scaling groups replace instances (and generate new instance IDs), tag-based selection makes sure that any new instance with the correct tags are automatically included in the backup plan.Configure a backup plan with a frequency appropriate for your environment and set the resource assignment to select EC2 instances matching your application tag (for example, ‘Application: Oracle’).
AWS Backup resource assignment configured with tag-based selection. Any EC2 instances tagged with the application tag are automatically included in the backup plan.
Step 3: Configure Lambda for AMI management
When AWS Backup completes an EC2 backup, it creates an AMI as the recovery point. An Amazon EventBridge rule detects this completion event and triggers a Lambda function. The function extracts the AMI ID from the backup recovery point, updates the SSM Parameter Store parameter with the new AMI ID, and cleans up older AMIs to control storage costs.
Lambda function overview showing the EventBridge trigger, Python 3.11 runtime, and function description indicating its role in processing backup completions and updating AMI references in SSM.
This event-driven approach means the latest AMI is available without manual intervention. The Lambda function needs IAM permissions for EC2 (to manage AMIs), SSM (to update the parameter), and Backup (to read recovery point metadata).
EventBridge rule configured to match AWS Backup job completion events for EC2 resources, with the Lambda function as the target.
Step 4: Configure the Systems Manager Parameter Store
The SSM Parameter Store holds the current AMI ID that the Auto Scaling group’s launch template references. The parameter is created with the aws:ec2:image data type, which enables the launch template’s resolve:ssm: functionality, a feature that allows the launch template to dynamically resolve the AMI ID at instance launch time without requiring a template version update.
SSM Parameter Store showing the /oracle/ec2/ami-id parameter with aws:ec2:image data type. The “Last modified user” confirms the Lambda function is automatically updating this parameter after each backup cycle.
When Lambda updates this parameter after each backup cycle, the next instance launched by the Auto Scaling group will automatically use the latest AMI. This removes the operational burden of manually updating launch template versions.
Step 5: Set up an Auto Scaling Group with dynamic AMI
The launch template references the SSM parameter using the resolve:ssm: prefix for the AMI ID field. This is the mechanism that ties the entire automation pipeline together. The mechanism backups trigger AMI creation, AMI IDs flow into Parameter Store, and the launch template resolves the latest AMI at launch time.
Launch template AMI configuration showing the ‘resolve:ssm:’ prefix, which dynamically retrieves the latest AMI ID from Parameter Store at instance launch time.
The Auto Scaling group is configured with minimum, maximum, and desired capacity all set to 1. This is not traditional auto-scaling, it’s a self-healing pattern. The sole purpose is to detect when the Oracle instance becomes unhealthy and automatically launch a replacement. The health check grace period should be set to at least 300 seconds (5 minutes) to allow Oracle sufficient time to start before health checks begin evaluating the new instance.
The launch template also includes a User Data script that runs on each new instance. This script configures the iSCSI initiator, discovers and connects to the FSxN endpoints, mounts the Oracle data volumes, and starts the Oracle database through a systemd service. This automation makes sure that a replacement instance is fully operational without manual intervention.
Auto Scaling group configured with min=max=desired=1 across two availability zones, providing self-healing capability.
Test the complete workflow
To validate the architecture, simulate an instance failure by terminating the current Oracle EC2 instance.
The expected sequence is:
- The Auto Scaling group detects the instance is unhealthy (within approximately 30 seconds)
- A new instance launches from the latest AMI resolved from Parameter Store (approximately 2 minutes)
- The User Data script connects to FSxN using iSCSI and starts Oracle (approximately 2–3 minutes)
- The Oracle database is available and accepting connections (total elapsed: approximately 5 minutes)
Auto Scaling group Activity History showing the self-healing sequence — the unhealthy instance is terminated, and a replacement is launched automatically within seconds.
The new instance automatically inherits the application tags from the Auto Scaling group, which means AWS Backup includes it in the next backup cycle without manual configuration.
Cleaning up
To avoid incurring future charges, delete the resources:
- Delete Lambda functions and EventBridge rules
- Remove Parameters from Systems Manager Parameter Store
- Delete AWS Backup plans and backup vault
- Deregister created AMIs
- Terminate Auto Scaling group instances
- Delete the Amazon FSx for NetApp ONTAP file system
Conclusion
This architecture facilitates Oracle high availability with configuration consistency by combining FSxN persistent shared storage with automated AMI management and AWS Backup protection. The Lambda-driven AMI management from backup recovery points and Parameter Store integration helps make sure that replacement instances launched by Auto Scaling groups always use the latest Oracle host configuration and can immediately connect to the existing Oracle database files stored on FSxN. Replacements occur only when health checks fail. Organizations can target high availability while maintaining configuration consistency across instance replacements. The automated AMI management alleviates configuration drift and makes sure that disaster recovery scenarios restore Oracle instances with identical host-level configurations that can immediately access the persistent Oracle database on shared storage. Healthy instances continue running unchanged, with replacements occurring only, when necessary, because of health check failures.Next steps include implementing cross-Region AMI replication, adding AMI validation testing, and developing custom health checks that verify both Oracle database and host configuration consistency.
Additional resources
Amazon OpenSearch Service: Mechanisms to secure your domain
Post Syndicated from Imtiaz Sayed original https://aws.amazon.com/blogs/big-data/amazon-opensearch-service-mechanisms-to-secure-your-domain/
Imagine you’re building a product search feature for your website or storing customer records in Amazon OpenSearch Service to power full-text search. The moment that real user data enters your domain, security becomes essential.
Whether your workload is a public-facing website search, an internal application querying sensitive data, or a pipeline handling personally identifiable information (PII), the questions you face are the same:
- Who should be allowed to connect to my domain?
- How do I authenticate users and services?
- How do I make sure that even authenticated users only see data they are entitled to see?
- How do I satisfy regulatory requirements such as HIPAA, PCI DSS, or SOC 2?
This post offers an overview of the security mechanisms available for Amazon OpenSearch Service, spanning authentication and authorization, encryption, and network access controls. You learn how to implement fine-grained access control, manage AWS Identity and Access Management (IAM) roles, and secure data both in transit and at rest for both public and virtual private cloud (VPC) access domains.
Scope: This post covers security for Amazon OpenSearch Service managed clusters only. It doesn’t cover Amazon OpenSearch Serverless, which uses a different security model. For serverless security, see Amazon OpenSearch Serverless security in the AWS documentation.
To begin, let’s look at the security layers in Amazon OpenSearch Service.
Amazon OpenSearch Service security layers
Amazon OpenSearch Service has multi-layer security. The following diagram illustrates the multi-layer security in Amazon OpenSearch Service.
Figure 1: Multi-layer security.
The three main layers of security are network, domain access policy, and fine-grained access control.
Network – The first security layer is the network, which determines whether requests reach an OpenSearch Service domain. If you choose Public access when you create a domain, requests from any internet-connected client can reach the domain endpoint. If you choose VPC access, clients must connect to the Amazon Virtual Private Cloud (Amazon VPC) (and the associated security groups must permit it) for a request to reach the endpoint.
Domain access policy – The second security layer is the domain access policy. After a request reaches a domain endpoint, the resource-based access policy allows or denies the request access to a given URI. The access policy accepts or rejects requests at the edge of the domain, before they reach data or indexes in OpenSearch itself.
Fine-grained access control – The third and final security layer is fine-grained access control. After a resource-based access policy allows a request to reach a domain endpoint, fine-grained access control evaluates the user credentials and either authenticates the user or denies the request. If fine-grained access control authenticates the user, it fetches all OpenSearch internal roles mapped to that user and uses the full set of permissions to determine how to handle the request.
With fine-grained access control, you can control access to your data in Amazon OpenSearch Service. For example, depending on who makes the request, you might want to hide certain fields in your documents or exclude certain documents altogether. With fine-grained access control, you can:
- Define role-based access control to determine who can perform which actions on which indexes, documents, and fields.
- Define security at the index, document, and field level to allow access to only required data.
Fine-grained access control requires OpenSearch or Elasticsearch 6.7 or later. It also requires HTTPS for all traffic to the domain, encryption of data at rest, and node-to-node encryption. Depending on how you configure the advanced features of fine-grained access control, more processing of your requests might require compute and memory resources on individual data nodes. After you turn on fine-grained access control, you can’t turn it off. For more details, see Fine-grained access control in Amazon OpenSearch Service in the AWS documentation.
To learn more about security features in an OpenSearch Service domain, let’s start by configuring a new public access domain. We discuss a VPC access domain later in the post.
Public access domain
With a public access domain, you can configure an OpenSearch Service domain so that the domain endpoint is accessible from the internet.
The AWS console for Amazon OpenSearch Service provides a guided wizard that you can use to configure and reconfigure your provisioned Amazon OpenSearch Service domains. Follow the Tutorial: Configure a domain with the internal user database and HTTP basic authentication in the AWS documentation to configure a domain with basic authentication and validate fine-grained access control.
Let’s review some important configuration attributes for a public access domain.
Network:
Public access. To simplify the network access configurations, you can use Public access, but for production workloads, we recommend VPC access.
With the domain in public access, you have several options to secure access. While you can use a resource-based access policy to restrict access to specific IAM principals or IP addresses, the recommended approach is to turn on fine-grained access control (FGAC) and use it as the primary mechanism for securing your domain. With FGAC turned on, you can set an open access policy (allowing all traffic to reach the domain) and let FGAC handle authentication and authorization at the index, document, and field level.
When using IAM-based authentication with FGAC, you should map IAM roles to backend roles in OpenSearch. You can use backend roles to assign permissions to groups of users based on their IAM role, rather than managing individual user mappings. This is especially important because if your IAM federation or authentication mechanism changes, the backend role mappings make sure of consistent access control within OpenSearch.
Figure 2: Use public access domain.
Fine-grained access control: Fine-grained access control provides numerous features to help you keep your data secure, such as document-level security, field-level security, read-only users, and OpenSearch Dashboards/Kibana tenants. Fine-grained access control requires a primary user, which is the administrator identity we discuss through the rest of this post.
The primary user is the administrator identity for your OpenSearch domain. This user can set up additional users in Amazon OpenSearch Service, assign roles to them, and assign permissions for those roles. You can choose username and password authentication for the primary user or use an IAM identity. You use these credentials to log in to OpenSearch Dashboards. Following the best practices on choosing your primary user, you should move to an IAM primary user for production workloads.
Fine-grained access control can be applied regardless of how you log in. You can follow your organization’s suggested authentication mechanism and apply fine-grained access control on top of it.
FGAC provides security at multiple levels to meet your security needs:
- Index-level security – Controls who can create, search, read, write, update, or delete within specific indexes.
- Document-level security – Restricts which documents within an index a user can see, using OpenSearch query filters (for example, only show documents where department: “sales”).
- Field-level security – Controls which fields within documents are visible (include or exclude specific fields).
- Field masking – Anonymizes sensitive field data (for example, hash a release_date or SSN field) rather than hiding it entirely.
Fine-grained access control supports several authentication mechanisms, including HTTP basic authentication using an internal user database, Amazon Cognito for web-based Dashboards access, SAML for enterprise identity provider integration, JSON Web Tokens (JWT) for token-based authentication, and AWS Identity and Access Management with SigV4 signing for IAM users and roles.
Encryption:
Amazon OpenSearch Service encrypts data both in transit and at rest. When you turn on fine-grained access control, encryption is required—the corresponding settings are automatically turned on and can’t be changed. These include Transport Layer Security (TLS 1.2 or later) for requests to the domain and for traffic between nodes in the domain, and encryption of data at rest through AWS Key Management Service (AWS KMS).
For encryption at rest, OpenSearch Service supports three key types: AWS owned keys, AWS managed keys, and customer managed keys. While AWS owned keys provide a quick-start option with no additional configuration, customer managed keys are the recommended best practice. Customer managed keys give you full control over the encryption key lifecycle, including key rotation policies, granular access control through key policies, and the ability to audit key usage through AWS CloudTrail. To use a customer managed key, create a symmetric encryption key in AWS KMS and select it when configuring your domain’s encryption settings.
For a basic public access domain with FGAC, all traffic reaches the domain freely (no VPC restriction), and an open access policy is used so no SigV4 signing is needed. FGAC then takes over, authenticating users through the internal user database (username/password) and enforcing role-based permissions at the index, document, and field level.
The public access configuration we discussed is useful for development and testing, but for production workloads, a best practices deployment combines VPC access, IAM-based authentication, and fine-grained access control. This approach layers all three security mechanisms—network isolation, identity verification, and granular permissions—to protect your domain end to end.
VPC access domain
Placing your OpenSearch Service domain inside a VPC restricts network-level access to resources within the VPC or connected networks. Traffic between your applications and the OpenSearch endpoint doesn’t traverse the public internet, and you can use security groups to further limit which entities can communicate with the domain. OpenSearch Service places a VPC endpoint (VPCe) using AWS PrivateLink into one, two, or three subnets of your VPC depending on your Availability Zone configuration. For high availability (HA), turn on multiple Availability Zones with each subnet in a different zone within the same AWS Region. For more details, see Launching your Amazon OpenSearch Service domains within a VPC.
For this best practices deployment, we use an IAM primary user with Amazon Cognito authentication for OpenSearch Dashboards and for fine-grained access control. We configure a primary IAM role and a limited IAM role, associate them with users in Amazon Cognito through a user pool and identity pool, and then use fine-grained access control to manage permissions. The primary user can then sign in to OpenSearch Dashboards, create backend roles, map the limited user to a restricted role, and enforce granular access at the index, document, and field level. For more details, see Tutorial: Configure a domain with an IAM master user and Amazon Cognito authentication in the AWS documentation.
The following high-level steps detail what’s needed to configure a VPC access domain with Amazon Cognito users. These steps use the Amazon Cognito user pool for authentication. The same basic process works for any Cognito authentication provider that lets you assign different IAM roles to different users.
- Create an Amazon Cognito user pool.
- Add users in the user pool for the primary user and a limited-access user.
- Create an Amazon Cognito identity pool.
- Update the IAM role for the primary user to allow access to OpenSearch Dashboards.
- Create an IAM role for the limited user.
- Create the domain.
You can follow Creating and managing Amazon OpenSearch Service domains in the AWS documentation to provision a domain. The following sections describe some important attributes for the domain.
Network:
VPC access. Public access isn’t recommended for production workloads. We recommend that you use VPC access for all production workloads. Pick the VPC, subnets, and security group that you have created for the OpenSearch domain.
Figure 4: Use VPC access.
Fine-grained access control:
Turn on fine-grained access control with OS[MasterUserRole] as the primary user. You can follow steps in Tutorial: Configure a domain with an IAM master user and Amazon Cognito authentication to create OS[MasterUserRole].
Figure 5: Turn on fine-grained access control with an IAM role.
Fine-grained access control provides numerous features to help you keep your data secure, such as document-level security, field-level security, read-only users, and OpenSearch Dashboards/Kibana tenants. Fine-grained access control requires a primary user.
The primary user is the administrator identity for your OpenSearch domain. This user can set up additional users in Amazon OpenSearch Service, assign roles to them, and assign permissions for those roles. You can choose username and password authentication for the primary user or use an IAM identity. You use these credentials to log in to OpenSearch Dashboards. Following the best practices on choosing your primary user, you should choose an IAM primary user for production workloads.
Fine-grained access control can be applied regardless of how you log in. You can follow your organization’s suggested authentication mechanism and apply fine-grained access control on top of it.
Amazon Cognito authentication:
To turn on Amazon Cognito authentication, select Enable Amazon Cognito authentication and choose the Amazon Cognito user pool and Amazon Cognito identity pool for your OpenSearch Dashboards.
Figure 6: Turn on Amazon Cognito authentication.
Access policy:
The access policy controls whether a request is accepted or rejected when it reaches the Amazon OpenSearch Service domain. You can configure a domain-level access policy to allow access to your Amazon OpenSearch Service domain.
Figure 7: Configure domain-level access to the domain.
Encryption:
Amazon OpenSearch Service encrypts data both in transit and at rest. When you turn on fine-grained access control, encryption is required—the corresponding settings are automatically turned on and can’t be changed. These include Transport Layer Security (TLS 1.2 or later) for requests to the domain and for traffic between nodes in the domain, and encryption of data at rest through AWS KMS.
For encryption at rest, OpenSearch Service supports three key types: AWS owned keys, AWS managed keys, and customer managed keys. While AWS owned keys provide a quick-start option with no additional configuration, customer managed keys are the recommended best practice. Customer managed keys give you full control over the encryption key lifecycle, including key rotation policies, granular access control through key policies, and the ability to audit key usage through AWS CloudTrail. To use a customer managed key, create a symmetric encryption key in AWS KMS and select it when configuring your domain’s encryption settings.
With these configurations, you can configure your Amazon OpenSearch domain and OpenSearch Service Dashboards so that they’re accessible only within the chosen VPC. For your production scenario, you can follow your organization’s approved mechanism to access the resources in a VPC. You can access OpenSearch Service Dashboards with a primary user to create a limited-access role and map it to the IAM role with limited access to validate fine-grained access control.
Conclusion
In this post, we looked at the important security configurations for a public and a VPC-based Amazon OpenSearch domain. You can examine more settings for fine-grained access control in the OpenSearch Dashboards Security section.
If you have feedback about this post, submit comments in the Comments section. If you have questions about this post, start a new thread on the Amazon OpenSearch Service forum or contact AWS Support.
About the author
[$] Open-source security is not a solo activity
Post Syndicated from jzb original https://lwn.net/Articles/1075741/
Over time, many open-source maintainers face the same problem: they
lack the time to do all of the work that their project needs, and no
one else is stepping up to provide adequate help. Maintainers, though,
are often reluctant to throw in the towel. The result is suboptimal
all around; the maintainer is stressed out, project quality suffers,
and users face security risks that they may not be fully aware of. At
the 2026 Open
Source Summit North America, Robin Bender Ginn spoke about this
problem, when it might be time for maintainers to pass the torch, and
the responsibilities of users.
We Found the AMD Ryzen AI Halo AI Developer PC
Post Syndicated from Patrick Kennedy original https://www.servethehome.com/we-found-the-amd-ryzen-ai-halo-ai-developer-pc/
We found the AMD Ryzen AI Halo the company’s AI developer PC at Computex 2026 running a live demo at an AMD event
The post We Found the AMD Ryzen AI Halo AI Developer PC appeared first on ServeTheHome.
Home Assistant 2026.6: Small Changes, Big Relief
Post Syndicated from BeardedTinker original https://www.youtube.com/watch?v=pmpMN-eaU20
How to Save the Supreme Court From Itself | The David Frum Show
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=bfAFo7Jfzh4
Support your young people with our AI literacy resources
Post Syndicated from Jenni Hutchings original https://www.raspberrypi.org/blog/ai-education-resources-ai-awareness-day/
At the Raspberry Pi Foundation, we believe that alongside learning to code, a crucial part of computing education is building AI literacy skills. Amidst the rapid pace of development and the growing impact of AI tools, it is increasingly important for educators everywhere to feel equipped to address the topic of AI with their learners, to help young people understand their world, be responsible users of AI technologies, and prepare to become the future creators of these technologies.
We work at the leading edge of AI education, combining research and industry expertise with practical classroom experience to define what AI means for computing education, and how to best support teachers and learners to understand these technologies.
Whether you are a teacher, a Code Club mentor, or a parent, we have a wide range of free resources to help you teach your young people about AI, and learn more about it yourself.
Explore our teaching resources
We offer a variety of teaching materials to help you bring AI into your setting. You do not need to be a professional educator or have a background in computer science to use these resources, and we provide everything you need to guide your learners with confidence.
Experience AI is our free AI literacy programme, developed in collaboration with Google DeepMind. Through ready-to-use classroom resources, including lesson plans, presentations, and hands-on activities, the programme helps educators all over the world teach their learners about how AI works, as well as its wider social and ethical implications. You and your learners will investigate AI tools, explore real-world uses of AI, and engage with critical issues such as bias, fairness, and transparency, helping learners to understand AI and use it responsibly. The lessons currently available are designed for learners aged 11–14, and we are releasing resources for other age groups this year.
To help bring Experience AI to more educators and learners around the world, we work with a global network of partner organisations, who help us provide tailored and translated resources and offer localised, high-quality training and support for educators in their regions. Experience AI resources are currently available in 19 languages, and have already been downloaded in more than 180 countries. In recognition of its impact, in 2025 Experience AI was named a laureate of the UNESCO King Hamad Bin Isa Al-Khalifa Prize for the Use of ICT in Education.
“[Experience AI] has definitely changed my outlook on AI. I went from knowing nothing about it to understanding how it works, why it acts in certain ways, and how to actually create my own AI models and what data I would need for that. I would 100% recommend others who don’t know much about AI to try it out.” – Student, Arthur Mellows Village College, UK
If you are looking to introduce school-aged young people to AI with short, beginner-friendly coding and digital making projects, take a look at our collection of Code Club projects about AI and machine learning. These projects are a great way to spark curiosity and investigate how AI and machine learning works.
In the projects, learners get hands-on with a range of AI tools and platforms, and explore different applications of AI, such as image recognition, voice recognition, and (for learners aged 13 and over) generative AI. For example, in Doodle detector, learners use Machine Learning for Kids with Scratch to create a machine learning application that can identify what they have drawn.
The projects feature clear step-by-step instructions, and many include video tutorials, to help learners work at their own pace and in a style that suits them. We also provide mentor guidance to help you prepare.
For resources to support older learners to build their understanding of AI, head to Ada Computer Science. Ada Computer Science is our free online platform for computer science students and teachers, developed in partnership with the University of Cambridge. It provides comprehensive resources for learners aged 14–19 across the breadth of computer science, including detailed learning materials about AI and machine learning. The materials include helpful definitions, clear explanations, and carefully designed self-marking questions to support young people’s learning.
Explore our learning and training opportunities for educators
To help you build your knowledge around AI technologies and grow your confidence to teach your young people about this important topic, we offer a range of learning resources and professional development opportunities, all for free. They are open to everyone, so we invite you to dive into any that interest you.
For flexible, self-paced learning options, take a look at the following free online courses, which cover a range of topics within AI:
- Introducing AI: Investigate how AI systems work and how to evaluate them, and explore the benefits, risks, and ethical issues related to them. This course is made up of 2 modules, and takes around 2–4 hours to complete.
- AI literacy for teachers and school leaders: Learn how to support your students and staff to understand, use, and critically assess AI technologies. This course takes around 1–2 hours to complete.
- Machine learning and AI: Discover machine learning and how it works, and train your own AI models using free online tools. This course is made up of 4 modules, and takes around 4–8 hours to complete.
You might also be interested in Hello World, our free magazine and podcast for educators teaching computing and AI. Each magazine is packed with resources, discussions, news, and ideas, and you can subscribe to receive each issue as soon as it is released. The next issue, coming in July, will focus on critical thinking in the age of AI. You can download our previous issues to explore articles about a variety of topics within AI too. What’s more, you can continue your learning with the Hello World podcast, which accompanies the magazine and features discussions with educators and researchers from around the world. Visit the podcast page to discover previous episodes exploring vibe coding and programming education, AI education around the world, and more.
To learn about research-informed teaching strategies to help you as you explore AI with your learners, you can read these short Pedagogy Quick Reads:
- Anthropomorphism: Explore how to help learners avoid thinking of AI systems as human-like, to support their understanding.
- Computational Thinking 2.0: Consider how computational thinking is evolving and how to help learners develop the computational thinking skills they need to understand modern digital systems involving AI.
- Feedback literacy: Explore how feedback literacy can help teachers and learners interact effectively with feedback generated by AI tools.
For more insights from computing education research, you can join our monthly online research seminars. Our 2026 research seminar series focuses on teaching about AI across the curriculum, delving into research on teaching and learning about AI from disciplines beyond computer science, including the arts, sciences, and humanities. Our next seminar takes place on 16 June, and you can catch up on previous seminars from our current series here. You can also explore our archive of recordings from previous seminar series, with themes including teaching about AI and data science, teaching programming (with or without AI), and more.
Bring AI into your classroom today
All of these resources and learning opportunities are available to anyone interested in educating young people about AI, anywhere in the world. We hope they help you gain understanding, confidence, and inspiration to guide your young learners to engage with AI safely and responsibly, and to learn valuable skills that will help them navigate their world.
“Let the students explore, advance, and grow. And who knows — maybe one of our students will go on to become a mentor or leader in this field someday.” – Ana Judith Zavaleta, computer science teacher, Mexico, speaking about Experience AI
If you are in the UK, you can also use these resources to get involved with the first-ever AI Awareness Day, a new nationwide campaign designed to build AI literacy across UK schools, which is taking place on 4 June.
The post Support your young people with our AI literacy resources appeared first on Raspberry Pi Foundation.
The Atlantic Summer Reading Guide
Post Syndicated from The Atlantic original https://www.youtube.com/shorts/aLwIigOvog0
[$] BPF in the agentic era
Post Syndicated from daroc original https://lwn.net/Articles/1075067/
Alexei Starovoitov gave “less of a presentation, more of a scream of
” at the BPF track of the 2026
realization
Linux Storage, Filesystem,
Memory-Management, and BPF Summit. He shared a set of ideas for how BPF could
change to avoid being swept away by the sea-change in programming represented by modern
large language models (LLMs) and the coding agents based on them.
In a follow-up session, the discussion covered
more problems with how coding agents use tools like bpftrace, and the current deluge of
patches in need of review in the BPF subsystem.
Tridgell: rsync and outrage
Post Syndicated from jzb original https://lwn.net/Articles/1076040/
Andrew Tridgell has written a blog
post responding to complaints that he has begun using LLM tools in
his work maintaining rsync:
Like many developers of open source packages I’ve been hit by a
flood of security reports lately in my role as the rsync
maintainer. Many of those reports are AI generated (not all though,
there are some notable ones with very careful and high quality manual
analysis).As this flood started to get more intense I realised I needed to
raise the defences on rsync a lot — we needed much more thorough test
suites, code coverage analysis, CI testing on a lot more platforms,
deliberate and thorough scanning for possible security issues (so I
find at least some of them before other people!) and the addition of a
whole lot of defence-in-depth hardening techniques.[…] Now to the future, because we’re not done yet by a long
shot. The security reports keep rolling in. I’m working on a bunch of
CVEs right now. Luckily I’ve been joined by some other very good
developers with great systems development skills and security
knowledge. Some of these people came to my attention partly because of
all the rage happening at the moment, so I get some rage storm clouds
have silver linings. Watch out for some credits for some great new
rsync developers in the next release.
Security updates for Wednesday
Post Syndicated from jzb original https://lwn.net/Articles/1076117/
Security updates have been issued by Debian (php-twig), Fedora (hplip, python-wsgidav, roundcubemail, and xorg-x11-server), Oracle (compat-openssl10, httpd:2.4, and kernel), Red Hat (osbuild-composer), SUSE (busybox, cloudflared, cockpit, cups, ffmpeg-4, gnutls, google-osconfig-agent, helm, hplip, kernel, kubelogin, libjxl, libsoup, libunbound8, LibVNCServer-devel, mapserver, nvidia-open-driver-G06-signed, nvidia-open-driver-G07-signed, openssh, python-idna, qemu, rqlite, shadowsocks-v2ray-plugin, ucode-intel, unbound, vim, vorbis-tools, and xorg-x11-server), and Ubuntu (age, dovecot, editorconfig-core, gobgp, libapache-mod-jk, libcommons-lang-java, libcommons-lang3-java, libeconf, linux, linux-aws, linux-aws-6.8, linux-aws-fips, linux-azure, linux-fips,
linux-gcp, linux-gcp-6.8, linux-gcp-fips, linux-gke, linux-gkeop,
linux-hwe-6.8, linux-ibm, linux-ibm-6.8, linux-nvidia, linux-nvidia-6.8,
linux-nvidia-lowlatency, linux-nvidia-tegra, linux-oracle,
linux-oracle-6.8, linux-raspi, linux-raspi-realtime, linux-realtime,
linux-realtime-6.8, linux, linux-aws, linux-azure, linux-azure-6.17, linux-hwe-6.17,
linux-nvidia-6.17, linux-oem-6.17, linux-oracle, linux-oracle-6.17,
linux-raspi, linux-realtime, linux-realtime-6.17, linux, linux-aws, linux-gcp, linux-ibm, linux-nvidia, linux-oracle,
linux-raspi, linux-realtime, linux-aws-6.17, linux-gcp, linux-gcp-6.17, luanti, mysql-8.0, mysql-8.4, node-tar-fs, and unbound).
Medium Format Magic: Recreating Marilyn’s Boudoir Shoot
Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=ssj-YoAfwHg
Battle of Mairy: 1944
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=bI0GfrZ2VpY
AI Used to Decrypt Medieval Ciphers
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/06/ai-used-to-decrypt-medieval-ciphers.html
Researchers are using machine learning algorithms to decrypt historical pencil-and-paper ciphers.
Ася Демирева: Нашите съвършени тела
Post Syndicated from Ина Иванова original https://www.toest.bg/asya-demireva-nashite-suvursheni-tela/
Вече почти две десетилетия Ася Демирева е сертифицирана и обичана консултантка по кърмене (IBCLC), което неусетно я е превърнало в гуру в една доста нишова сфера.
Това е най-хубавата работа, по-добра дори от дегустатор на сладолед.
Често жените идват при нея с новопокълнало чувство за вина или боязън, че нямат майчински инстинкт: не се справих, не ми се получава да кърмя, а искам.
Телата ни са съвършени, а ние, с нашите мозъци и незрелите си разбирания, им пречим да си свършат работата. Ние сме програмирани да знаем кое е правилно, но на съвременните поколения е вменено, че за да направим нещо добре, трябва да бъдем научени. Не виждаме живота в абсолютния му, природен покой. Моята прабаба, която е била неграмотна, е знаела какво е пермакултурен дизайн, без разбира се, да го нарича така. Но е знаела къде коя култура да посади и че на тази почва след две години ще се чувства добре друго растение, защото вече е обогатена от предишните с конкретни вещества. Ние обаче сме загубили това знание, което се е предавало от поколение на поколение. Загубили сме и вкоренения си инстинкт да отглеждаме други хора. Само преди около 150 години хората са виждали всичко – съвкупяването на животните, раждането. Вместо да се радваме на живота, ние никога не сме посрещали живот. Затова не знаем какво да правим. Хората преди нас са имали имплантирани модели за грижа, биологични модели, които при това са визуализирани стотици пъти. Днес пречим на телата си да действат свободно, спънати от недоверие и противоречива информация.
Ася Демирева е наясно със сблъсъка на младите майки с общия информационен шум, с непомерните изисквания за правилност, които обществото налага. Затова и напоследък в мрежата се появяват групи за споделяне – на майките, които не се справят, които се чувстват уплашени или просто искат да говорят за трудностите и „тегавините“ в този етап от живота си.
Мисията на Ася е не просто да говори за ползите от кърменето – ползи и за майката, и за бебето, но и да подпомогне процеса на засукване, обяснявайки рефлекторната му природа и разчитайки на инстинктите, заложени в телата ни. Тя е и сред създателките на възглавницата „Матеа“, която облекчава позицията на майките и осигурява комфорт при кърмене.
Стотици пъти съм присъствала на момента, в който един човек засуква от майка си и как тази жена емоционално го преживява, как цялото ѝ тяло се разтреперва, много често тя се разплаква. Аз имам късмета да съм свидетел на този първи контакт.
Първата детска мечта на Ася Демирева е да учи медицина; майка ѝ обаче я убеждава, че трудно би се справила емоционално с подобна професия. И така, Ася завършва Френската гимназия в Бургас и след това журналистика в Софийския университет. Това са точно годините на приватизацията и начеваща политическа журналистика и тя осъзнава, че ще завърши, без да иска да работи това. Създава семейство и през 2006 г. се обучава за консултантка по кърмене. Малко по-късно, вече майка на едно дете, започва да работи за сп. „Моето дете“. И понеже житейското колело се върти неумолимо, но и с подобаващ усет за историческа ирония, по времето, по което се развежда, Ася става главен редактор на списанието.
Когато години по-късно заради работата си следва за лекарски асистент и изучава обща медицина, установява, че майка ѝ е била права и трудно би оцеляла в болница.
Ако бях станала лекар, щях да работя предимно с болни бебета. Сега работя със здрави и много щастливи родители, после те си тръгват с нахранени и доволно заспиващи бебета.
Разбира се, истината е, че понякога родителите се изплашени и напрегнати, друг път идват на консултация в комплект с две баби.
Преди години обяснявах на бабите със страхопочитание и желание да насоча начина им на мислене в различна посока, но сега, от „пиедестала“ на двайсетгодишния ми опит, говоря по-авторитетно, а и с повече разбиране. Истината е, че бабите, които вече консултирам, са първите ползвателки на форума „БГ мама“.
Хората, ангажирани с медицински професии, често са изправени пред необходимостта да се сблъскват с различни начини на мислене, методи за справяне със стреса, а и с възприемане на биологичните ни параметри. Когато става въпрос за деца обаче, цялото ни общество сякаш се държи нелогично.
Живеем в кански парадокс – считаме, че на четири месеца бебето ни трябва да заспива самостоятелно, което е смешно, но на осем години вземаме детето за ръка от ръката на учителката. То не знае как да се прибере до вкъщи, откъде се купува хлябът и че той струва пари. А във все още съществуващите племенни култури това е възрастта, в която момчетата получават оръжие – собствено копие например. Те вече имат правото да убият животно и да приготвят храна. Тоест могат да се защитят и да се нахранят.
Ася всъщност помага на младите родители да не страхуват. Но и да си припомнят, че човек заспива в абсолютна безопасност. А за бебетата това е в прегръдката на друг човек.
Ние знаем за зоната за терморегулация при майката – тя се намира около гърдите. Когато бебето е хладно, тази зона се затопля, и обратното – ако кожата на майката фиксира, че има нужда от охлаждане, го прави. Това е велик способ за регулация. Майката е първата инстанция в адаптацията на този нов човек в новия за него свят. Имаме всички механизми да го посрещнем извън тялото си. Затова „кожа в кожа“ е и метафора – точно така започва животът.
За хора като Ася Демирева, които работят с наука, но виждат началата на живия живот, границата между биологично и трансцедентно е проницаема. Тя познава механизмите на телесното, а работата ѝ изисква и да го обясни на майките.
Ние създаваме тела от тялото си, храним ги от себе си, трансформирайки нашата храна в нещо жизненоважно за оцеляването на бебетата – всъщност ние имаме божествени функции.
Дългогодишната ѝ практика с бебета я е убедила, че дори новороденото не е табула раза, не е бяло платно, върху което се пише отначало.
Но за този живот, в това тяло, всяко конкретно бебе започва да се учи сега. И нашата работа като родители е първо да го приведем във физическата норма за конкретното общество – без значение дали ще е високотехнологично, или не, дали ще е бедно дете в богата държава, или обратното.
А това е невъзможно без майката да се събере и да се задейства спрямо собствените си представи за правилно. Иначе,
всяка жена има собствено дъно на тема майчинство, което копае системно,
твърди Ася и се надява все повече жени да избират подкрепата на психолог, за да се справят.
Всяка майка има своите страхове и форми на несигурност, но преди години сякаш беше по-просто. Днес имаме свръхсоциален елемент на социалните мрежи.
В момента количеството на информацията е ужасяващо. А вече съществува и понятието mommy shaming, което отразява съвсем реалния процес не просто на засрамване, а на тотално отричане: ако не правиш нещата по съответния начин, каква майка си изобщо?! Поредната стигма у нас пък е свързана с възрастта, на която кърменето трябва да престане. Само преди десетилетие общуването между майките е било по-скоро обмяна на опит, сочат наблюденията на Ася Демирева. От друга страна, тя смята, че социалните мрежи и миниобществата, които те поддържат, имат голямо и качествено значение за съвременния родител.
Самата тя е възпитана от майка, която е фиксирала модела, че ако едно решение е взето след претегляне на плюсове и минуси, значи то е правилно. Към онзи момент и онези обстоятелства то е било най-доброто. Тоест „не връщаме времето и не се самообвиняваме“. Това се оказва нейната лична работеща стратегия по отношение на майчинството, а Ася има две деца и със сигурност е преминала през обичайните изпитания. С първото си дете излиза ежедневно навън, защото по това време има паник атаки:
Най-големият ми страх беше, че мога да получа инфаркт и да минат часове, преди някой да дойде и да спаси бебето ми. Така че започнах да тренирам екстравертността си. Виждах се непрекъснато с жени с бебета. Винаги съм чела много и обичам да препредавам информация, затова се чувствах изключително добре да разказвам всичко, което съм научила. Всъщност съм тренирала за консултант.
Ася Демирева е различна по рождение – с вродена липса на кост, т.нар. малък пищял, фибулата. Затова десният ѝ крак е по-къс.
Това е източникът на всичките ми детски травми и върху него работя все още с психолога си. Но то е и в основата на избора ми на професия, която е свързана с оказване на помощ.
Ася е израснала по времето на социализма, когато в детските болници децата са оставяни сами. Да, дори и четиригодишните. Но е имала късмета майка ѝ да бъде до нея само защото е била медицинска сестра.
Това не ме спаси от манипулации без упойки и без нива на физическа болка, които не са окей за малко дете. Някъде там у мен се роди убедеността, че нито едно дете повече не бива да преживее това. Аз исках да стана лекар, за да спася децата.
Глобално Ася смята, че разбиранията ѝ са доста стереотипни. Тя уважава йерархията, приема, че обществото ни вменява роли и ролевите модели трябва да бъдат спазвани. И че малкият човек трябва да постигне конкретни нива, за да бъде равен на големите. Но не може да се съгласи да се отнасяме с малките деца като с незначителни.
У нас малките са нищожни. А това не е вярно. Ние имаме нужда от техния подход, от тяхното любопитство и интерес към всичко и ако си позволим да бъдем като тях, ще живеем в по-добро общество. Вместо това ние ги омаловажаваме.
Хората, които тихо и кротко променят средата, формират общности и задават посоки, в които има смисъл да тръгнем заедно. Тук ви срещаме с тях. Това са „Тези хора“.
Тоест разговаряме – епизод 10
Post Syndicated from Владислав Севов original https://www.toest.bg/toest-razgovaryame-epizod-10/
В навечерието на един от най-хубавите български празници – 24 май, Деня на българската просвета и култура – разговорът ни със Зорница Христова естествено тръгна от литературата, но много бързо стигна до паметта, езика, детството, общественото доверие и въпроса какво всъщност остава след думите. Коментирахме, че формалното празнично говорене за езика понякога рискува да се превърне в ритуал без съдържание, а в същото време именно словото някога е било истинско „оръжие“, променяло общества и съдби.
Говорихме за книгите и четенето като възможност за бавно размишление в свят на непрекъснат шум, за липсващата критика, за маркетинга, който често подменя разговора за литература, за нуждата някой все пак да пази пространствата за смисъл…
Зорница разказа и за рубриката си „По буквите“, в която книгите не стоят една до друга като заглавия в каталог, а разговарят помежду си – през паметта, през настоящето, през личния опит на читателя. За Зорница литературата не е самотен предмет, а жива среда, в която различни светове непрекъснато си общуват.
Особено място в разговора ни зае детската литература като едно от най-трудните и най-важни изкуства. Говорихме за свободата през играта, за правото на детето да чува сложни думи, да се страхува, да си въобразява, да мисли различно. И за онези книги, които остават като емоционална памет за цял живот.
Накрая стигнахме и до езика като удоволствие, а не като назидание, и до онова усещане, че думите имат значение не когато ги пазим под стъклен похлупак, а когато успяват да провокират размисли и да създават близост и доверие.
Гледайте целия разговор в нашия YouTube канал:
Може да го чуете и като аудиозапис в SoundCloud:
На живо зададох на Зорница въпроси от публиката, но нямаше как да обхванем всички. Затова я помолих да отговори тук на още един ваш въпрос:
Как намирате баланса между комерсиалния успех на едно издателство и поддържането на безкомпромисен литературен стандарт?
Ха-ха-ха, този въпрос е много мило зададен! Можеше да бъде: „Кое е по-лошо: да правите книги, от които Ви е срам, или да правите книги, които не се продават?“ Така зададен, въпросът е лесен. Но все пак искам и да се продават, разбира се – продажбите ти показват, че книгата е била нужна.
Така и си задавам въпроса: От какви книги има нужда? И защо? Много от нашите научнопопулярни книги – „Витоша“, книгите от поредицата „Философски закуски“, „Книга за смъртта“, „Един ден в музея“, „Бедността. Пътеводител за деца“, „Сладоледена реторика“ – са издадени по тази причина. Смятам, че има нужда от тях. Това са и тиражите, които свършват първи.
Други излизат просто защото страшно много ми харесват, без дълбок пазарен замисъл. Не може всичко да е по схема. Нали литературата трябва да изненадва, да доставя удоволствие, да „отваря приказка“ с разни части от теб, които иначе не са особено разговорливи. Понякога сред тези книги, издадени „защото така“, дадено заглавие се разграбва за миг.
Не е ли по-сладко хубавата книга сама да си пробие път, отколкото да правиш книги според проправените вече пътеки? За мен поне е. „Когато искам да мълча“ е бестселър не само у нас, но и в Италия. А смятах, че я правим за двайсетина наши приятели…
Преди срещата ви помолихме да отговорите на кратката ни анкета. Ето и резултатите от нея:
Книгата е най-добрият офлайн режим за ума.
Зорница Христова е писателка, преводачка, редакторка и издателка. Тя е съоснователка на „Точица“ – издателство, специализирано в съвременни детски книги с висок литературен и визуален стандарт. Авторка е на книги за деца и възрастни. Работи активно и като преводачка от английски език. Сред преведените от нея автори са Джулиан Барнс, Джон Ървинг, Тони Джуд, Джумпа Лахири, Джеръм К. Джеръм, Том Улф, Йосиф Бродски и много други. В текстовете и публичните си изяви често защитава ролята на преводача като съавтор и литературен посредник.
Зорница Христова е и дългогодишна литературна журналистка и есеистка. В „Тоест“ води рубриката „По буквите“ – пренесената от Марин Бодаков легендарна колонка „Ходене по буквите“ във вестник „Култура“, която по-късно Зорница продължи в негова памет. В своите текстове тя съчетава литературна критика, културен анализ и личен есеистичен подход, като особено внимание отделя на паметта, превода, детската литература и връзката между книгите и обществената среда.
Така протече десетият епизод на „Тоест разговаряме“, който беше и последният в рамките на инициативата, подкрепена от Институт „Отворено общество – София“ и проекта Media Resilience на Европейския съюз. Искрено се надяваме, че тези разговори са ви били интересни и полезни. Ако искате да ги продължим, подкрепете ни!
В десетте епизода на „Тоест разговаряме“ всеки месец ви срещахме с автори, които познавате добре от анализите или от рубриките им в „Тоест“, но този път ги видяхте и чухте в по-личен и непосредствен формат. Във видеоразговорите, предавани на живо, активно участие имахте и вие, нашата публика – със своите въпроси, коментари и включване в тематичната анкета. Водещ на поредицата беше Владислав Севов, дългогодишен телевизионен журналист и съосновател на „Тоест“.
„Тоест разговаряме“ е поредица от 10 епизода, подкрепена от Институт „Отворено общество – София“ и съфинансирана от Европейския съюз в рамките на проекта Media Resilience. Изразените възгледи и мнения са само и изцяло на техните автори и не отразяват непременно възгледите и мненията на Европейския съюз, на Европейската изпълнителна агенция за образование и култура (EACEA) или на Институт „Отворено общество – София“ (ИООС). Нито Европейският съюз, нито EACEA, нито ИООС могат да бъдат държани отговорни за тях.
Може би държавата не е виновна на подвелите се купувачи на незаконни имоти
Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/babaalino/
Тия дни изчетох доста от написаното за Баба Алино. Твърденията на кмета на Варна, на предишния кмет, на Радевките, на ДНСК, на инвеститора и купилите имоти. Хареса ми как Красен Николов и Димитър Николов са подредили хронологията в Медиапул, но знам, че повечето няма да си направят труда да прочетат извън лозунгите на купувачи и политици.
В понеделник говорих по Дарик за темата за незаконното строителство, нарушенията, прозрачността на документите и контрола. Също за риска за пореден път единният регистър по устройството на територията да не се случи и да не позволи прозрачността, която служебния кабинет заложи в проекта. Най-вече, че липсата на отворени данни и прозрачност пречи на комуникацията между институциите, което всъщност стои в голяма степен в корена на проблема с ония 100 декара Баба Алино. Че злоупотреби и чадър е имало – имало е, че полицията не е съдействала също е вярно, но е вярно и че измамата е успяла, защото отговорните институции не си говорят.
Говорих също, че е грешно да се смята, че банките правят някакви реални проверки и щом са дали ипотека значи, че всичко било наред. Отдавна говоря как имотния (не)пазар поставя под огромен риск банковата ни система и управлението на този риск е под всяка критика гледайки данните за заемите на БНБ. Тук липсата на прозрачност – особено за сградите без акт 16 и фалиралите фирми-бушони на инвеститори – пречи да се осъзнае колко рискови всъщност са инвестициите в имот.
Тук обаче се чудя за съвсем друго
Купувачите на тези жилища в комбина с инвеститора изглежда искат да съдят общината и държавата, че ще им бутат сградите. Учудва ме, защото вместо това следва да съдят точно инвеститора за измама, на каквото всъщност сме свидетели в момента. Мисленето обаче е, че „то незаконно, ама нали минаваше номер до сега, защо изведнъж стана проблем“ по същия начин както някой си хвърля боклука през прозореца години наред и става агресивен като му направят забележка. Щом са си платили на някого там, значи имат право независимо, че всичко е незаконно и са засегнали защитена местност.
При това доста други хора ги защитават, а в същото време крещят за скоростно събаряне на единственото жилище – макар и незаконно – на семейства в ромски махали. Единствената разлика, която виждам е, че в случая в Баба Алино става въпрос за милиони и чадъри много години назад във всякакви институции, а във втория – за социален, образователен и в немалка степен плод на ефективната сегрегация в обществото ни.
Та затова говоря, че трябва да внимаваме за червените флагове и хората със схема. На теб може да не ти пука, че някой заобикаля закон и наредби и укрива данъци за няколко процента печалба отгоре. Могъл – откраднал, нали? Какво обаче те кара да мислиш, че по същия начин няма прецака и теб? Дори толкова повече следва да си сигурен. Затова е добре да прилагаме здрав разум.
А за случая във Варна тепърва следва да разбираме фактите. По паниката на предходния кмет ми става ясно накъде ще излязат нещата, ако не се заметат под килима в премиерския кабинет. С тази прокуратура в този вид обаче не очаквам шанс за реални мерки дори да се подмени главния прокурор.
Полезно стълпновение
За само няколко дни по темата за незаконните имоти се изказа половината администрация. Хареса ми интервюто на бившия служебен министър Найденов. През час излизат отрязани снимки на разрешения и решения – дали са за строеж, дали за търпимост, дали за ПУП или изготвянето на такъв. Неизменно са придружени не само от твърдения на собственици, но и сносни обяснения на архитекти, юристи и чиновници какво значат.
Замислих се, че този поток на документи може да е искрено полезен. Липсва основно разбиране как протича процесът и какво значат отделните документи. След толкова години дълбане в темата аз също едва виждам повърхността. Според архитекти много в самата гилдия не разбират дори половината. Затова ми хрумна, че този скандал е възможност не само да се осветлят механизмите за подобни измами, пропуските в регулацията и оперативната работа на администрацията, но и да служи като средство за повишаване на общата култура поне на онези, които следят случая. И отново – разбирането не значи да приемаме проблемите, сложността и ограниченията на самата администрация, а да задаваме по-добри въпроси и да искаме промени с конкретика.
Dynamically Splitting Wide Partitions in Cassandra for Time Series Workloads
Post Syndicated from Netflix Technology Blog original https://netflixtechblog.com/dynamically-splitting-wide-partitions-in-cassandra-for-time-series-workloads-0eded064f456
By Rajiv Shringi, Kaidan Fullerton, Oleksii Tkachuk and Kartik Sathyanarayanan
Introduction
Netflix’s TimeSeries Abstraction is a scalable system for ingesting and querying petabytes of temporal event data with millisecond latency. We use Apache Cassandra 4.x as the underlying storage for these main reasons:
- Throughput, latency, and cost: Cassandra can handle millions of low‑latency reads and writes in a cost-effective manner.
- Operational maturity: Our data platform team has deep operational expertise running large Cassandra clusters in production.
However, using Cassandra at this scale introduces trade‑offs for TimeSeries workloads. A key challenge is wide partitions, as TimeSeries dataset partitions can grow quite large with events accumulating over time.
This problem is further compounded by the fact that TimeSeries servers routinely deal with a very high read throughput:
This post walks through our journey to reduce the impact of wide partitions in our TimeSeries datasets, the solutions we built, and the lessons we learned.
Impact of Wide Partitions
For most of our datasets, we observe an average read latency in the order of single-digit milliseconds:
However, in some datasets, as partitions grow too wide, we observe high read latencies in the order of seconds, especially towards the tail end:
This can result in timeouts:
In extreme cases, if most of the reads target wide partitions, we can see Garbage Collection pauses, high CPU utilization and thread queueing.
Scaling up the underlying Cassandra cluster is always an option, but we need smarter alternatives than just throwing more money at the problem.
TimeSeries Partitioning Strategy
The TimeSeries Abstraction was designed to solve the problem of wide partitions by dividing the data into discrete time chunks. For more in-depth information, refer to our previous blog.
To summarize, here is an illustration of how TimeSeries partitioning strategy helps us break up wide partitions into manageable chunks.
This strategy further allows us to efficiently query and drop data based on time, without having to deal with tombstones.
Picking the Partitioning Strategy
When a namespace (a.k.a. dataset) is created, users must specify their anticipated workload characteristics. This specification is then fed into our provisioning pipeline. The pipeline processes these inputs, runs Monte Carlo simulations, and produces an optimal infrastructure and partition configuration.
You can learn more about our methodology of capacity planning in this insightful AWS re:Invent talk given by one of our stunning colleagues.
The Problem with the Current Approach
Although this method of provisioning is effective in many situations, it proves insufficient for TimeSeries workloads under these conditions:
- Workload is unknown or inaccurately estimated: Early on in a project, users can lack a reliable picture of production traffic or simply misestimate key parameters.
- Workload evolves over time: Traffic patterns, client behavior, and product requirements change. A “good” partitioning strategy on day one can become inefficient months later.
- Data outliers exist: Not all TimeSeries IDs behave the same. A small percentage of IDs can receive a vastly higher volume of events than the rest.
Fortunately, our design with discrete Time Slices gives us a natural escape hatch for the first two scenarios; each new Time Slice can use a different partitioning strategy.
However, manually adjusting these configurations in a fleet that has thousands of TimeSeries datasets is not sustainable. We need automation.
Solution 1: Time Slice Re-Partitioning
Cassandra exposes useful introspection APIs for understanding data usage and access patterns. For example, nodetool tablehistograms provide percentile distributions for partition sizes in a table. Using these tools, we can detect cases of both over and under partitioning.
Below is an example of over‑partitioning, where the TimeSeries provisioning pipeline selected very small time_bucket intervals based on user provided inputs:
causing partitions to have less than 10 KB of data, leading to high read amplification and thread queueing:
In order to tune partition strategies efficiently, we added a background worker, which monitors partition histograms of Time Slices attached to a given application, and exposes it via a Cassandra virtual table:
It then computes an adjustment factor when it detects partition sizes not meeting a configured density. This configured density is often set between 2 MiB to 10 MiB depending on the workload.
DynamicTimeSliceConfigWorker:
namespace: my_dataset_1
Observed: TimeSlices have p99 partitions below configured target of 10MB.
Proposed: time_bucket interval: 60s -> 604800s
The worker can then update future Time Slices with the new partition strategy:
This strategy has yielded real results in reducing our read latencies, as well as reducing the number of timeouts caused by thread queueing.
However, this strategy only works if most of the data exhibits such behavior that warrants re-partitioning of the entire table. It does not work in cases where only a percentage of IDs within the table are wide.
We have a couple of options here:
- Do Nothing: This is sometimes the right approach if there is no observed impact to the application’s top-level metrics.
- Partial Returns: We implemented a ‘Partial Return’ feature, which aborts an inflight request if it has breached a configured latency SLO, while returning whatever data it has collected up until that point. This is a great option for clients who care more about latency than fetching all the data.
- Block IDs: This is an extreme step but worth mentioning, because we do deal with bad data that occasionally seeps into the system e.g. test or spam IDs that can make the system unstable.
dgwts.config.<dataset>.block.Ids: "<tsid-1>, <tsid-2>, <tsid-3>"
Ultimately, we encounter scenarios where valid and important TimeSeries IDs accumulate a high enough volume of events, with callers needing to process all the related data. Simply tolerating elevated latencies or timeouts when querying these IDs is not a desirable outcome.
This is where dynamic partitioning comes into play.
Solution 2: Dynamic Partitioning per ID
Dynamic partitioning is an asynchronous pipeline that auto-detects and splits wide partitions on a TimeSeries ID level rather than at the table level.
It has three main stages:
- Detection: Detects wide partitions for a given TimeSeries ID during the read path.
- Planning & Splitting: Plans and executes splits of those partitions into optimal sizes asynchronously.
- Serving Reads: Re-routes the read queries transparently to read data from the split partitions when ready.
This is how it works at a high level; we will dive into details after:
Here are the different stages of the pipeline:
Detection
Every TimeSeries read operation tracks how many bytes are read for a given partition. If the bytes read exceed a configured threshold, the server emits a detection event to Kafka:
{
"time_slice": "data_20260328", // the Cassandra table this event was detected in
"time_series_id": "profileId:123", // the ID detected as wide
"time_bucket": 7, // the existing time_bucket partition
"event_bucket": 2, // the existing event_bucket partition
"immutable": true, // TimeSeries servers can compute if this partition is no longer receiving writes
"version": "0" // reserved for future use e.g. invalidate if partition is no longer immutable
}
Our decision to detect wide partitions on reads, as opposed to writes, is based on our observation that the majority of the data in the wild doesn’t need this treatment. The slight downside is that some reads on these large partitions may suffer sub-optimal performance for a very short duration (typically seconds) until this process catches up.
Immutability
Although splitting mutable partitions is possible, it is inherently more complex. As a first step towards solving this problem, we chose to reduce the surface area of this change by focusing on immutable partitions, while still meaningfully reducing caller timeouts.
Planning
Detection may occur based on a partial read, so the planner must still read the entire partition once to compute an accurate split plan. The checkpointing becomes crucial here. For planning reads that fail to process the entire partition, the process can always continue from the last saved checkpoint.
Checkpointing
The wide_row metadata table serves as the backbone for state transitions and checkpointing of partition splits. It also stores information that is used later by TimeSeries servers to properly route Read queries.
Splitting
The Planner delegates the splitting of data to an appropriate split-strategy. For example, if EventBucketPartitionSplitStrategy is selected, we split the partition by assigning more event buckets to the same time bucket. If the partition is ultra-wide, we cap the number of event buckets we split into, in order to control the resultant read amplification. Spreading into multiple partitions in such cases is still beneficial in order to spread the read workload to multiple Cassandra replicas.
Validating Splits
The Planner stores a pre-split checksum of a given partition during the planning phase, while the Splitter computes and stores the post-split checksum. The split status is marked as completed only if the two checksums match.
Tracking Splits
The pre- and post-split partition sizes across different datasets are tracked to see how effectively the partition splits are being planned and executed:
Serving Reads
The TimeSeries servers load the partition-keys of completed splits periodically into in-memory Bloom filters. Every read operation checks the Bloom filter to see whether a query can be diverted to the split partitions.
Here is what the Read path looks like:
The size of the Bloom filters is monitored to ensure we have enough memory per server. Due to the compactness of partition keys, and ratio of wide partitions in a given dataset, the filters fit comfortably in each server instance.
The Bloom filter latency to check whether a given partition key is wide for every read request is typically in single-digit microseconds or better, making this diversion practically invisible to the callers.
For the cases that do end up with a Bloom filter hit, the TimeSeries servers lookup the wide_row metadata to see how to read a specific wide partition:
{
"pre_split_data": {
"time_slice": "data_20260328",
"time_series_id": "6313825", → What to read
"time_bucket": 0,
"event_bucket": 2
…
},
"post_split_data": {
"time_slice": "wide_data_20260328_0", → Where to read it from
"event_bucket_partition_strategy": { → Strategy to delegate to for reading
"target_event_buckets": 2,
"start_event_bucket": 32 → How should the strategy read it
}
…
}
This metadata read is backed by a read-through cache, making it quite performant:
Finally, the reads for the split partitions are delegated to our existing PartitionReader. Having the same schema for the split table allows us to reuse code and minimize changes.
Fallbacks
The existing wide partition from the original time slice is never deleted. This helps us in creating safe fallbacks in many different scenarios of partial failures and eventual consistency. The slightly larger storage space we use as a result is worth the operational safety we gain.
Building Additional Confidence
Serving incorrect reads would be disastrous. To establish trust beyond checksums, we leveraged additional mechanisms such as:
- Using our existing Data Bridge pipelines to verify splits offline:
- Implementing a phased rollout strategy to safely advance through stages as our confidence in the system grew:
A critical part of this phased rollout was the Comparison phase, which compared bytes served by old read path and the new read path while in shadow mode:
Results
As a result of these dynamic splits, we see a huge improvement in the average read latency of most wide partitions, bringing it down from seconds:
to low double-digit milliseconds!
Tail latencies of reading wide partitions dropped from several seconds:
to around 200 ms or better:
resulting in a drop in read timeouts:
Further, for extreme wide rows, where a dataset would face constant timeouts and unavailability blips, the service was able to paginate and query 500MB+ partitions while remaining available:
grpc … com.netflix.dgw.ts.TimeSeriesService/SearchEventRecords -d
'{"namespace": "...",
"search_query": {...},
"time_interval": {
"start": "2026–05–11T23:42:51.484398Z",
"end": "2026–05–12T00:13:50.694205Z"
},
"pageSize" : 1000,
}'
# Response:
{
"next_page_token" : ….,
"records": [
{
…
}
],
"response_context": [{
"namespace": "...",
…
# Trades elevated latency for being available
"time_taken": "41.072410142s"
}
]
}
Conclusion
There is more work planned around this feature, like splitting mutable wide partitions, or re-processing previously failed splits, but this has been a successful start in improving service performance and reducing our support burden.
Further, we would like to highlight some key lessons that we learned at different points in this journey.
- Reducing Surface Area: As a first step, explore simpler solutions that can still deliver meaningful impact. Also, reducing the surface area of a complex change and deploying incrementally pays off operationally.
- Building Confidence: Invest time and resources to build confidence in new features, especially when justified by the feature complexity, deployment blast radius, and/or potential impact.
Acknowledgements: Special thanks to our stunning colleagues who further contributed to this feature’s success: Tom DeVoe, Chris Lohfink, Sumanth Pasupuleti and Joey Lynch.
Dynamically Splitting Wide Partitions in Cassandra for Time Series Workloads was originally published in Netflix TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.