Post Syndicated from Ryan Smith original https://www.servethehome.com/zimacube-2-pro-review-intel-marvell-asmedia/
We review the ZimaCube 2 Pro NAS and see how this box combines an unexpected processor with 10GbE and many 3.5″ and M.2 SSD drive bays
The post ZimaCube 2 Pro Review An Unexpected 10GbE NAS with Thunderbolt and PCIe Slots appeared first on ServeTheHome.
Post Syndicated from Ramakrishna Natarajan original https://aws.amazon.com/blogs/big-data/automate-data-discovery-and-centralized-management-with-aws-glue-data-catalog/
Managing sensitive data across sprawling data environments is hard. In this post, we show you how to tackle data discovery, classification, and governance across your databases, data warehouses, and object storage to regain visibility and control over your data landscape. As you build new features, products, and services, your data naturally spreads across multiple systems to meet immediate application and business needs. Different teams spin up their own data stores, and before long, you’re dealing with a complex web of repositories—often with limited visibility into what exists where. This data sprawl becomes most challenging when you must understand and protect your sensitive data. Security teams often struggle to maintain accurate inventories of data categorization and classification. Stakeholders demand comprehensive insights into data classification and processing activities, usually on tight deadlines, and keeping up-to-date data inventories becomes increasingly daunting as your data grows. Without automation, you’re left with manual processes that stretch over weeks, leave room for human error, and create unnecessary business risk.
In a typical manual scenario, creating a new database triggers a chain of time-consuming events. The governance team reviews the new data source, documents its contents, and scans for sensitive data. The security team assesses its configuration and access controls. Days or weeks pass before you fully understand this new asset’s sensitivity.
With automation, creating a new database triggers immediate action. The system detects the new source, catalogs its structure, identifies sensitive data, and updates a central inventory within minutes, supporting proper governance from the moment you create it. Here’s how it works on AWS: When you create an Amazon Simple Storage Service (Amazon S3) bucket for customer orders, you add tags such as Business Function, Data Owner, and Purpose. After the bucket is in use, the system detects it, creates catalog entries, analyzes data patterns, identifies sensitive information, and updates governance records without additional input from you. This gives your organization real-time visibility. Security teams instantly see which repositories contain sensitive information. Governance teams generate up-to-date inventory reports on demand, and data teams immediately understand sensitivity levels, helping them use data responsibly.
The solution uses key AWS services across three layers that work together for comprehensive data visibility and categorization.
Detection Layer: Continuously monitors your AWS environment for new resource creation. When you provision an Amazon S3 bucket, Amazon Relational Database Service (Amazon RDS) database, or Amazon DynamoDB table, Amazon EventBridge rules capture this activity and initiates the governance workflow, so no data source goes unnoticed.
Figure 1 Automated data source discovery (S3 example) workflow using EventBridge Rules and Lambda functions
Processing Layer: After a new source is detected, AWS Glue crawlers analyze its schema while specialized jobs scan for sensitive data patterns. The system also extracts metadata from resource tags, enriching your understanding of each repository’s purpose and ownership.
Figure 2 PII detection and processing workflow using AWS Glue jobs and DynamoDB staging
Management Layer: Maintains a central source of truth about your data assets. AWS Glue Data Catalog provides a unified view across your organization, tracking schema changes and sensitivity levels. This layer also manages the processing workflow state and generates insights for stakeholders.
Figure 3 Tag-based metadata capture and Data Catalog update workflow
This solution uses AWS Cloud Development Kit (AWS CDK) for deployment, organized into four stacks that build upon each other.PrerequisitesBefore deployment, verify that you have:
Step 1: Infrastructure deployment
Deploy four stacks using AWS CDK. Each establishes components for data discovery, cataloging, and PII detection.
To deploy these stacks, you will use the AWS CDK CLI, running the following commands:
Figure 4 CloudFormation console showing successful stack deployment
Step 2: Verify initial setup
In the AWS Management Console, open DynamoDB and find the glueJobTracker table. This table is a critical component of the framework:
By verifying this table, you confirm that the infrastructure is ready to begin tracking new data sources.
Figure 5 Empty DynamoDB glueJobTracker table before execution
This solution runs automatically in production through EventBridge triggers and scheduled AWS Glue crawlers. The following walkthrough executes each step manually so you can observe the workflow.You follow the journey of a newly created S3 bucket containing sensitive data, seeing how the solution discovers, catalog, and processes it through each stage.
Step 3: Create a new S3 bucket
Figure 6 S3 console showing new bucket creation with tags
Step 4: Upload sample data
Figure 7: S3 console showing uploaded CSV file in the orders folder
Step 5: Verify automated detection
Figure 8 DynamoDB console showing detected bucket entry in glueJobTracker table
Step 6: Initiate catalog creation
Figure 9 Lambda console showing successful function execution
Step 7: Run the AWS Glue crawler
Figure 10 Glue console showing crawler in “Running” state
Step 8: Verify schema discovery
Figure 11 Glue console showing detected table schema
Step 9: Execute PII detection
Figure 12 Glue console showing PII detection job in “Running” state
Step 10: Review PII detection results
Figure 13 DynamoDB console showing PII detection results in piiDetectionOutputTable
Step 11: Verify Data Catalog updates
Figure 14 Glue console showing updated table schema with PII classifications
Note: While we focus on S3 data sources in this walkthrough, the framework extends to other data stores, offering a unified approach for PII detection and compliance management, so organizations can automatically discover, catalog, and monitor sensitive data elements across your entire data ecosystem. For more information, see aws-samples/automated-datastore-discovery-with-aws-glue.
As you implement this solution, consider these key practices for effective results:
Figure 15 Centralized Storage of Glue PII Detection Results in AWS Data Catalog
To avoid ongoing charges and remove the resources created by this solution, follow these steps:
Remember, deleting these resources will remove all data and configurations associated with this solution. Make sure that you have saved any important information before proceeding with the clean-up.
In this post, you learned how to build an automated data governance framework using AWS Glue Data Catalog. You set up detection, processing, and management layers that automatically discover, catalog, and classify your data sources.This approach improves how you manage sensitive data assets. Teams spend less time on manual discovery and categorization, freeing them to derive value from data. The system gives you current insights into your data landscape and automatically identifies sensitive data, creating a trusted source of truth that helps teams work efficiently while maintaining controls.You can extend this framework with custom sensitivity patterns for your industry. Its modular design supports continuous improvement and integrates with existing workflows. This turns data governance from a manual burden into an efficient process that scales with your organization.
Post Syndicated from jzb original https://lwn.net/Articles/1074534/
Rodrigo Arias Mallo, maintainer of the Dillo web browser, has written a
blog post
with a proposal on one way to ensure that a contribution is written by
a human and not AI; he suggests asking new contributors to record
their programming session using asciinema.
In the same way that LLMs generate patches, they can also generate
the asciinema recordings themselves. Then, the contributors can lie to
the reviewers pretending to have made the edits. Perhaps surprisingly,
this is not a easy task for LLMs, at least from my observations. The
corpus of recordings of developers making mistakes and thinking the
whole process of editing a file is not as large as the corpus of FOSS
programs and patches in which to train an LLM. During my very simple
tests I haven’t been able to generate an asciinema session that
remotely resembles what I would expect from a human, and even less so
from a human with a nice editor theme and editing an existing Dillo
source file.
The Dillo project is not yet requiring asciinema recordings, but he
said that he would like to test the theory further. LWN covered asciinema in
January 2026.
Post Syndicated from Trevor Schiavone original https://aws.amazon.com/blogs/security/well-architected-best-practices-for-software-supply-chain-security/
There have been multiple notable supply chain attacks using the npm Registry since September: Shai-Hulud, Chalk/Debug, one abusing tea.xyz tokens, and recently axios. Thanks to community efforts involving the Amazon Inspector team, the Open Source Security Foundation, and others, the affected packages were quickly flagged, which reduced the impact of these incidents.
Supply chain attacks like Shai-Hulud exploit vulnerabilities on two fronts: compromised maintainer accounts that publish malicious packages, and consumer environments that download and execute those packages. The Shai-Hulud attack, shown in Figure 1, succeeded because maintainer credentials were compromised through phishing, enabling threat actors to publish malicious versions of popular packages. Incidents like these highlight the need for strong security practices within the software supply chain, and effective defense requires addressing both sides. Package maintainers need protections that prevent account compromise and limit sprawl when credentials are stolen. Package consumers need layered defenses that detect malicious packages, prevent their deployment, and limit damage when compromise occurs.
In this post, we explore best practices for package consumers. These practices are aligned with the AWS Well-Architected Framework – Security Pillar and you can use them to reduce exposure to similar threats and limit their impact if they occur.
Figure 1: Architecture diagram showing Shai-Hulud attack flow
When Shai-Hulud executed in developer environments and continuous integration and delivery (CI/CD) pipelines, it scanned for secrets such as npm tokens, GitHub tokens, and AWS Identity and Access Management (IAM) access keys. Long-term credentials exposed in this way enabled threat actors to propagate the malware further and access cloud resources. Recent incidents have shown organizations discovering multiple leaked IAM credential pairs, with concerns about additional exposed credentials and potential compromise of CI/CD pipelines.
Removing long-lived credentials from your developer environments and CI/CD pipelines reduces the scope of exposure in the event a system is compromised. For developers working locally, the new AWS CLI login command (aws login) simplifies the process of acquiring short-lived CLI credentials and removes the need to store long-lived credentials in configuration files. AWS IAM Identity Center also provides a straightforward way to acquire temporary credentials that expire automatically. For CI/CD pipelines, OpenID Connect (OIDC) federation with GitHub Actions, GitLab CI, or other platforms provide temporary credentials for each job without storing long-lived tokens. IAM can also federate AWS Identities to external services, allowing your AWS workloads to securely access external services without using long-term credentials. Temporary credentials expire automatically, limiting the window of exposure if a pipeline is compromised.
If you’re interacting with a third-party service that doesn’t support temporary credentials, consider storing the credentials to centralized storage using AWS Secrets Manager or AWS Systems Manager Parameter Store. Limit access to these secrets, require the use of temporary credentials, and apply automatic rotation and audit logging to reduce the risk of exposure of these credentials.
To reduce risk from credential exposure:
In the event of a security incident where credentials might be exposed, immediately rotate all long-term credentials to limit the scope of impact. Use Amazon GuardDuty and AWS CloudTrail to detect abnormal IAM activity and identify which credentials might have been compromised.
Even with temporary credentials and least privilege, a single compromised account can enable threat actors to publish malicious packages or access sensitive resources. Defense in depth creates multiple layers of protection that work together to prevent sprawl after initial compromise. While adding approval workflows to every operation would dramatically decrease deployment speed, implementing them strategically for sensitive workloads provides balanced security.
The key principle is to ensure that if one credential or account is compromised, additional controls prevent that compromise from spreading across your organization. This includes multi-factor authentication (MFA) for access combined with different IAM roles for sensitive workloads. For single-developer open source projects, MFA becomes even more critical because there’s no separation of duties through multiple maintainers.
For package maintainers working in team environments, requiring multiple approvers to release packages to production creates separation of duties. However, developers can still trigger merge requests that initiate deployment pipelines, so multi-party approval should be implemented within the pipeline itself for sensitive deployments. This ensures that even if a developer’s credentials are compromised and they trigger a deployment, the pipeline requires additional approval before releasing to production.
For package consumers, multi-approval workflows in deployment pipelines help ensure that if a malicious package passes initial scanning, human review can catch suspicious changes before production deployment. Artifact signing provides a complementary cryptographic layer that works alongside these process controls.
The Shai-Hulud attack succeeded because compromised maintainer credentials allowed threat actors to publish malicious packages directly to the public npm registry. For package consumers, the defense is ensuring that packages pulled from public registries cannot reach production without verification. Artifact signing is one concrete implementation of this layered approach. By cryptographically binding a package or container image to the identity that produced it, signing creates a verification layer that is independent of the credential used to trigger the build—meaning a compromised developer credential alone isn’t sufficient to introduce an unverified artifact into your deployment pipeline.
AWS Signer provides cryptographic signing for packages, creating an additional verification layer within your defense in depth strategy. The signing authorization model separates concerns: developer credentials shouldn’t have signing permissions. Only CI/CD pipeline roles should have signing permissions through the signer:StartSigningJob API. Signer uses FIPS 140-3 Level 3 validated hardware security modules (HSMs) to store signing keys, providing strong cryptographic protection.
The container image signing workflow, shown in Figure 2, demonstrates how signing integrates seamlessly into existing processes:
Figure 2: Diagram showing Signer signing workflow
The benefits of Signer compared to building custom signing infrastructure include:
Audit logging for all signing operations enables detection of unusual patterns such as signing from new IP addresses, unusual times, or rapid succession of signing jobs. For every credential in your system, consider who can access what, how they prove their identity, and what second layer prevents sprawl if that credential is compromised. Artifact signing, combined with centralized storage and Software Bills of Materials (SBOMs), provides layered protection against tampering and malicious packages.
By centralizing package and dependency management, you can validate and approve dependencies before they’re used in applications and quickly audit dependencies in the event of a supply chain security incident. Recent incidents have shown organizations discovering compromised npm packages in their internal artifact repositories, requiring rapid assessment of which applications might be affected.
On AWS, you can use AWS CodeArtifact to host and manage your organization’s software packages. You can use the package group configuration to define an approved list of upstream sources and block access to all others—a direct control against typosquatting attacks, where malicious packages are published under names that closely resemble legitimate ones. Rather than relying on developers to identify suspicious package names at install time, package group configuration enforces the boundary at the repository level. Centralization also helps you pin versions of dependencies to prevent automatic updates from pulling in malicious versions and quickly remove compromised dependencies across your software portfolio when an incident occurs.
For container images, Amazon ECR provides centralized image storage with AWS Key Management Service (AWS KMS) encryption and lifecycle policies. Combine Amazon ECR with Amazon Inspector scanning to continuously validate image integrity.
For additional guidance see SEC11-BP05: Centralize services for packages and dependencies.
For npm packages specifically, provenance attestations provide a complementary control on the consumer side. Available since npm 9.5, npm provenance links a published package to the specific source repository and CI/CD workflow that produced it, using Sigstore as the underlying signing infrastructure. When a package is installed, the npm CLI can verify that the published artifact matches the attested build provenance—providing confidence that the package wasn’t tampered with between build and publication. For organizations consuming open source npm packages, checking for provenance attestations before adding a new dependency is a low-friction signal of supply chain integrity. Package maintainers publishing to npm can enable provenance by running npm publish with the –provenance flag from a supported CI/CD environment such as GitHub Actions.
For additional guidance see SEC11-BP06: Deploy software programatically and, from the DevOps Lens of the AWS Well-Architected Framework, DL.CS.2: Sign code artifacts after each build
AWS provides services to help you scan dependencies continuously, from development through deployment:
Traditional vulnerability scanners focus on known CVEs—publicly disclosed vulnerabilities with assigned identifiers. Supply chain attacks like Shai-Hulud involve malicious packages that function as zero-days: they’re intentionally crafted by threat actors and actively exploited before a CVE is assigned. Traditional vulnerability scanners that rely on CVE databases won’t detect these packages until they’ve been formally identified and catalogued, which can take days or weeks.
Detecting these requires behavioral analysis at scale and community collaboration, not just static signature matching. The operational scale of AWS—with threat intelligence from sources like MadPot and incident response data across millions of customers—enables detection of suspicious package behavior across multiple environments simultaneously. When a newly published package exhibits credential-harvesting behavior in multiple customer accounts within hours of publication, that cross-account signal enables rapid identification. These findings are contributed to community-maintained databases like the OpenSSF Malicious Packages Repository (github.com/ossf/malicious-packages), which assigns a formal identifier (MAL-ID) and shares it across the security community. For the tea.xyz token farming campaign, the average time from submission to formal identification was approximately 30 minutes. AWS services like Amazon Inspector participate in this community loop, contributing findings and ingesting newly assigned MAL-IDs to surface threats in your environment.
A related threat model worth understanding is the sleeper package: a package that appears benign at publication and activates malicious behavior only after a delay or trigger condition. Static analysis alone is insufficient to catch these packages because the malicious payload isn’t present or active at install time. Amazon Inspector behavioral analysis is specifically designed to detect this class of threat, complementing static vulnerability scanning.
Software Bills of Materials (SBOMs) in SPDX or CycloneDX format enable you to quickly assess exposure during incidents. When responding to supply chain incidents, use SBOMs to identify which applications contain compromised packages, prioritize remediation, and assess blast radius. In the Shai-Hulud incident, the compromised packages (MAL-2025-46974 and CVE-2025-59144) were identified early, providing actionable findings that customers could remediate quickly. Organizations that had scanning enabled but experienced alert fatigue may have missed critical alerts, highlighting the importance of proper alert routing and prioritization.
Figure 3: Screenshot of Amazon Inspector console showing malicious package findings
For additional guidance see SEC11-BP02: Automate testing throughout the development and release lifecycle.
Visibility into activity is essential to detect anomalous behavior early. Configure logging and centralize those logs for analysis:
CloudTrail logging provides audit trails for credential access and API activity. When responding to supply chain incidents, review CloudTrail logs for specific events that indicate credential compromise or malicious activity: sts:AssumeRole calls from unexpected IP addresses or regions, secretsmanager:GetSecretValue or ssm:GetParameter calls from unfamiliar sources, ecr:PutImage from developer workstations bypassing CI/CD pipelines, lambda:UpdateFunctionCode outside normal deployment windows, iam:CreateAccessKey followed by immediate API activity, and codecommit:GitPush or codebuild:StartBuild from unusual IP addresses. When combined with Amazon EventBridge rules, you can trigger automated responses when Amazon Inspector detects malicious packages or when these unusual credential access patterns occur.
Organizations affected by recent supply chain attacks have used CloudTrail analysis to determine the scope of credential exposure and identify which resources might have been accessed by compromised credentials. This forensic capability is essential for understanding blast radius and ensuring complete remediation.
For additional guidance see the best practices in SEC04: Detection.
These components of a defense in depth strategy work together to prevent sprawl after initial compromise and help you to detect and respond to the event. Figure 4. shows how these fit together.
Figure 4: Architecture diagram showing defense architecture
The Security pillar of the Well-Architected Framework also provides organizational best practices that are applicable to improving security processes across all dimensions of your organization. Relevant best practices include SEC11-BP01: Train for application security; SEC11-BP08: Build a program that embeds security ownership in workload teams; and SEC10: Incident Response.
Recent incidents including Shai-Hulud, Chalk/Debug, and tea.xyz reflect ongoing efforts by threat actors to target the the package registries, CI/CD pipelines, and developer credentials for increased attack surface and propagation. A single compromised maintainer account or malicious package can propagate across thousands of consumer environments simultaneously. The controls described in this post are designed with that threat model in mind. Temporary credentials limit the value of stolen tokens, centralized dependency management and upstream blocking reduce the attack surface at the registry level, artifact signing ensures that even if a build pipeline is compromised, unsigned artifacts cannot reach production, and dependency scanning throughout your software lifecycle helps you identify compromised packages early, before they can impact you. Each layer narrows the window of opportunity for a threat actor.
See the following blogs and workshops to dive deeper on this topic:
If you have feedback about this post, submit comments in the Comments section below.
Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=6GzX_qKkXnk
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/05/identifying-people-using-wi-fi-routers.html
Not identifying people based on their use of Wi-Fi routers, but identifying people using Wi-Fi signals.
This is accomplished through what is known as WiFi sensing, or the use of WiFi signals to infer information about a physical environment. When radio signals like WiFi travel through a space, they interact with the objects and people around them. Those signals can be reflected, scattered, or absorbed. By analyzing how the signal is expected to behave compared with how it is actually received, researchers can infer details about the surrounding environment.
“By observing the propagation of radio waves, we can create an image of the surroundings and of persons who are present,” said Thorsten Strufe, a KIT professor and study co-author, in a press release. “This works similar to a normal camera, the difference being that in our case, radio waves instead of light waves are used for the recognition.”
Post Syndicated from Crosstalk Solutions original https://www.youtube.com/watch?v=sAh1mgRjx1o
Post Syndicated from corbet original https://lwn.net/Articles/1074449/
Curl maintainer Daniel Stenberg writes about
the stress of keeping up with the current flood of security reports.
This is a never-before seen or experienced pressure on the curl
project and its security team members. An avalanche of high
priority work that trumps all other things in the project that is
primarily mental because we certainly could ignore them all if we
wanted, but we feel a responsibility, we have a conscience and we
are proud about our work. We feel obliged to fix security problems
in the software we have helped shipped to every device on the
globe. This is personal to us.With about half the release cycle left until the pending release
ships, we already have twelve confirmed vulnerabilities
meaning twelve pending CVE announcements. That’s a new project
record and it also means we will reach thirty published CVEs
in 2026 even before half the calendar year has passed. The
projected total amount of curl CVEs published through the whole
year is therefore at least double this number!
Post Syndicated from corbet original https://lwn.net/Articles/1073407/
Huge pages can improve performance by increasing translation lookaside
buffer (TLB) utilization and reducing memory-management overhead.
Transparent huge pages (THPs) are supposed to make huge-page usage,
well, transparent, Nico Pache said at the beginning of his session in the
memory-management track of the 2026 Linux Storage,
Filesystem, Memory Management, and BPF Summit. That transparency has
never worked as well as many would like; he has been working on
improvements to make it easier for applications to use huge pages on Linux
systems. A following session, led by David Hildenbrand, was focused on how
THPs could be taken away from processes that are not using them fully.
Post Syndicated from The Atlantic original https://www.youtube.com/shorts/dsHxiFrhn-U
Post Syndicated from jzb original https://lwn.net/Articles/1074443/
Security updates have been issued by Debian (postorius and spip), Fedora (bind, bind-dyndb-ldap, linux-firmware, tor, and unbound), Mageia (ffmpeg, nginx, perl-Imager, and tigervnc, x11-server, x11-server-xwayland), Oracle (firefox and kernel), Red Hat (buildah, git-lfs, go-toolset:rhel8, golang, golang-github-openprinting-ipp-usb, grafana, grafana-pcp, gvisor-tap-vsock, java-1.8.0-openjdk, java-17-openjdk, java-21-openjdk, opentelemetry-collector, osbuild-composer, podman, rhc, rhc-worker-playbook, skopeo, and yggdrasil), SUSE (amazon-ecs-init, assimp, azure-storage-azcopy, busybox, firefox, gnutls, graphicsmagick, helm, kernel, leancrypto, libpng16, libppsdocument4_0-6, libsndfile, mcphost, nano, nginx, perl-http-tiny, perl-XML-LibXML, python-urllib3, python-urllib3_1, python311-ocrmypdf, python312, rclone, rsync, xen, and xz), and Ubuntu (dotnet8, dotnet9, dotnet10, linux-intel-iot-realtime, linux-lowlatency, linux-nvidia-6.8, linux-nvidia-tegra, linux-nvidia-tegra-igx, nltk, simpleeval, and vim).
Post Syndicated from Emma Burdett original https://www.rapid7.com/blog/post/it-security-leaders-cut-through-complexity-driving-stronger-outcomes-webinar
Security leaders are operating in an environment that is only getting more complex. Expanding attack surfaces, rapid AI adoption, growing toolsets, and increasing pressure to respond faster have made it harder to maintain a clear view of risk and priorities.
At the Rapid7 Global Cybersecurity Summit, the customer panel How Clarity Beats Complexity explores how leaders are navigating that reality in practice. Drawing on perspectives from CISOs and technology leaders across industries, the session focuses on how teams are managing complexity without losing sight of what matters.
Rather than focusing on theory, the discussion is structured around a set of practical questions that reflect what teams are dealing with today. These include where complexity is making security harder to manage, how alerts, data, and handoffs are slowing decisions, and what can look like progress but fails to deliver meaningful outcomes.
As the conversation develops, speakers such as Debby Briggs, VP-CISO at Netscout Systems and Raheem Daya CTO at Target RWE share how their teams are rethinking processes, habits, and assumptions that add noise without improving security. The emphasis shifts toward questioning metrics that measure activity rather than risk, and focusing instead on what drives meaningful outcomes.
From there, the session looks at what is actually making a difference. Topics include how leaders are clarifying priorities, aligning security actions with real business impact, and where visibility and context are proving more valuable than volume. Will Lambert, Information Security Manager at Culligan International adds a practitioner perspective, highlighting how clearer ownership and better coordination across teams help reduce friction in day-to-day operations.
Throughout the session, the focus remains on practical decision-making. This includes managing complexity without oversimplifying, validating investments in areas such as MDR and consolidation, and ensuring security teams are focused on outcomes that improve resilience.
For CISOs, security operations leaders, and teams evaluating their current approach, this panel offers a grounded view of how others are tackling the same challenges.
Watch the full customer panel to hear how security leaders are cutting through complexity and focusing on what actually improves outcomes.
Post Syndicated from jake original https://lwn.net/Articles/1073583/
In a plenary session at
the
2026 Linux Storage,
Filesystem, Memory Management, and BPF Summit, the state of patch
review using large language models (LLMs) was discussed. It is a topic that has been swirling around in the
kernel community for much of the year. The plenary, which was led by Roman
Gushchin, Chris Mason, Josef Bacik, and Sasha Levin, resulted in a quite bit
of discussion, so much that a second filesystem-track-only (though others
surely sat in) slot was used to continue it later in the day.
Post Syndicated from Patrick Kennedy original https://www.servethehome.com/supermicro-sys-112d-36c-fn3p-review-a-36-core-intel-xeon-6-soc-server-with-2x-100gbe/
In our Supermicro SYS-112D-36C-FN3P review, we see how this 36 core Intel Xeon 6 SoC edge server with 2x 100GbE onboard performs
The post Supermicro SYS-112D-36C-FN3P Review A 36 Core Intel Xeon 6 SoC Server with 2x 100GbE appeared first on ServeTheHome.
Post Syndicated from Daniel Abib original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-aws-local-zones-in-istanbul-open-source-extenddb-kiro-web-and-more-may-25-2026/
There’s something genuinely energizing about working with startups — something I’ve been doing intensely for more than two years now. Startups operate at a different frequency: the urgency is real, the constraints are tight, and the stakes are personal. Helping them navigate the challenge of proving their business model requires not just technical depth but a willingness to move fast, challenge assumptions, and make bets on the right architecture before the perfect data exists.
What I love most is that the work is never abstract: every decision I help a startup make has a direct impact on whether they ship on time, stay within budget, and earn the next round of confidence from their investors.
Let’s dive into this week’s AWS news.
Headlines
Now Open — AWS Local Zones in Istanbul, Türkiye — AWS has opened a new Local Zone in Istanbul, Türkiye, bringing AWS compute, storage, and networking services to one of Europe’s largest metropolitan areas. For organizations with data residency requirements in Türkiye, this Local Zone enables you to keep data within the country while still leveraging the full breadth of AWS services. The Local Zone also benefits applications that require single-digit millisecond latency — such as real-time gaming, media production, live video streaming, and financial services — by running closer to where end users actually are.
A Local Zone is a significant infrastructure investment: it requires the same level of commitment as a Region in terms of hardware, power, networking, and operational excellence. It also reflects AWS’s continued expansion into underserved markets.
For builders in Türkiye, this opens up a new set of architectural possibilities. You can now store and back up data within Turkish borders to help meet data residency requirements, and run latency-sensitive workloads in the Istanbul Local Zone while connecting seamlessly to the AWS Region — giving you the flexibility to architect hybrid applications without managing your own data center infrastructure. To learn more about our decade-long commitment, available services, customers and partners in Türkiye, visit the launch blog post.
Last week’s launches
Here are some launches and updates that caught my attention:
For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.
Other AWS news
Here are some additional posts and resources that you might find interesting:
Upcoming AWS events
Check your calendar and sign up for these events:
Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development. Browse here for upcoming AWS-led in-person and virtual events and developer-focused events.
That’s all for this week. Check back next Monday for another Weekly Roundup!
— Daniel Abib
This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS!
Post Syndicated from jake original https://lwn.net/Articles/1074286/
The Software Freedom Conservancy (SFC)
published a news
item on May 18 about its response to violations of the AGPLv3 by Bambu
Lab in its 3D printers. The company has not provided the source code to
its modifications to a 3D “slicer” program that was released under the
AGPLv3 and it has also threatened Paweł Jarczak who created a fork of a
different slicer (Orca Slicer) released under AGPLv3 in order to interoperate with his
Bambu printer. Based on that, the SFC has created the baltobu
project aimed at reverse-engineering and reimplementing the Bambu code
while also hosting the Orca Slicer fork.
Bambu has behaved badly for years and made multiple, provably false public statements regarding the AGPLv3 and its requirements. The recent aggressive behavior toward Paweł Jarczak was a last straw for us: we have decided to launch a multi-pronged effort that will assist consumers and users in the short-term, and also work toward a long-term strategy to improve the software right to repair for all 3D printer consumers.
Post Syndicated from The Atlantic original https://www.youtube.com/shorts/zn92izHuCio
Post Syndicated from Надежда Цекулова original https://www.toest.bg/kak-da-govorim-za-detsa-s-tezhki-zabolyavaniya-pravo-etika-i-chovechnost/
От Аристотел и Конфуций, през Руми и Диоген, до Мишел Фуко и Джудит Бътлър, мислители от различни епохи и култури напомнят, че думите не са просто разменна монета помежду ни, а материята, която изгражда разбирането ни за света. За неподатливата на абстракции съвременна култура на общуване тези постулати са преведени на рационалния език на етичните и правните норми, чиято основна цел е да пазят света ни – особено на тези сред нас, които не могат да се защитят сами – от остротата на словото.
Когато говорим за тежко болни деца, каквито са нуждаещите се от палиативни грижи, вероятно всеки ще се съгласи, че те заслужават – и им дължим – най-висока степен на защита, докато коментираме живота и проблемите им. Как обаче да се справим с това безспорно свое задължение, се оказва спорен въпрос.
Тези деца се представят съжалително… „Ох, айде чукай на дърво, то, горкото“. Но както е „то, горкото“, нищо не се предприема да видим реално живота на това дете… и да гледаме на това без патетичната жалост, ами с някаква конструктивна нагласа.
Тези думи резюмират в две изречения основните проблеми на създаването на съдържание за деца в уязвима ситуация в българското публично пространство. А и не само в българското.
Цитатът е от изследването „Децата в медиите“ на УНИЦЕФ – България и Асоциацията на европейските журналисти (АЕЖ) – България, публикувано през 2021 г. Изследването е мащабно – проверява обективните индикатори за присъствието на децата в българските медии, а след това чрез интервюта с 45 журналисти от най-различни медии търси причините за установените дефицити. Основните изводи сочат, че децата (като цяло) не са любима медийна тема. Когато попадат в медиите, се говори за тях, а не със тях, и то доста повърхностно, сензационалистки или обективизиращо. Според изследователите това затруднява аудиторията да си състави представа за детето.
Изводът важи напълно, а в определени случаи и по-силно за затрудненията, които медии и журналисти срещат при представянето на теми, свързани с тежко болни деца. Това се потвърди и от изследване, посветено на медийното представяне на децата, нуждаещи се от палиативни грижи. Ще го споменавам често в тази поредица, която е донякъде инспирирана от него, тъй като става дума за собствената ми дипломна работа (и с извинение за самоцитирането, което не е добра практика, разбира се). Находките от разглеждане на публикациите в дигиталните медии на български език в периода 2023–2024 г. показват слабо и несистемно представяне на темата за детските палиативни грижи, видим недостиг на познаването ѝ в дълбочина и пълно отсъствие на историите на пряко засегнатите – децата, техните семейства, близки и обгрижващи специалисти.
Надежда Цекулова
Да се разкаже историята на страдащо, а в някои случаи умиращо дете не е лесна работа и плахостта на журналистите, която прозира зад отсъствието на тези истории, може да се разглежда и като добър знак. Избирам да я чета като своеобразно и негласно решение на професионалистите в създаването на публична информация на първо място да не вредят и поради високата сложност на задачата да избират по-скоро да стоят встрани от нея, отколкото да рискуват да нанесат неволно непоправими щети върху някого, чиито страдания и без това са трудни за обговаряне и осмисляне. Това поне открих у себе си, когато установих, че всички дефицити на представянето на детските палиативни грижи в медиите се откриват и в моите собствени текстове по темата.
Писаната рамка идва на помощ и дава насоки и инструментариум, макар да не може да свърши работата вместо журналиста (на него се пада винаги тежкото решение как точно да разкаже историята си).
Правилата за журналистическо отразяване на тежко болни деца са повлияни от редица международноправни документи и конвенции в сферата на правата на човека. Тези рамки подчертават защитата на правата, достойнството и личния живот на децата и служат като основа за етични журналистически практики, а също така ангажират държавите за създаване на правни механизми за закрила на децата.
Когато става дума за деца, основен източник в международното право е Конвенцията за правата на детето на ООН, която ги защитава от произволна или незаконна намеса в техния личен живот, семейство, дом или кореспонденция и от всички форми на злоупотреба и експлоатация. Тези изисквания създават рамка, която гарантира, че медийното отразяване не нарушава правото на децата на достойнство и личен живот.
Същевременно в последните две десетилетия все по-активно се развива концепцията за право на детето на участие, заложена в чл. 12 от Конвенцията. През 2012 г. концепцията за правото на детето на участие е заложена в специална препоръка на Комитета на министрите на Съвета на Европа. В тази препоръка се изтъква значимостта на включването на децата и младите хора в процесите на вземане на решения, които ги засягат, и се предоставят насоки на държавите членки за улесняване на тяхното участие. А отскоро съществува и наръчник на Съвета на Европа за участие на децата в решения, свързани с тяхното здраве.
В наръчника се подчертава, че децата имат право да бъдат активна страна в процеса на вземане на решения, които ги засягат, като се отбелязва, че включването на децата води до по-високо качество на грижата. Макар документът да е фокусиран основно върху клиничния контекст, в него са формулирани основни принципи, които могат да бъдат отнесени и към медийното отразяване на теми като детските палиативни грижи. Основната идея е, че
Това поставя журналистическата задача пред сложен баланс, изискващ, освен висок професионализъм, и стабилна етична подготовка, за да се създаде пространство за детско участие в публичния разказ за детските палиативни грижи, без това участие да почива на сензационализъм, да виктимизира или по друг начин да уронва достойнството на детето.
Светла Енчева
Международните документи, които могат да бъдат отнесени към въпроса как да разказваме за тежко болни деца, включват и популярния с абревиатурата си GDPR – европейски регламент, регулиращ работата с лични данни, които са особено чувствителни, когато става дума за здраве и за деца. Толкова чувствителни, че родителското съгласие може да не е достатъчно, за да направи огласяването им етично и дори законно, става ясно от анализ на Мария Шаркова, доктор по гражданско право.
В българската практика eдин от малкото документи, даващи насоки за правната регулация на медийното отразяване на деца, е наръчникът „Децата и медиите“, разработен в сътрудничество между УНИЦЕФ – България и АЕЖ – България. В наръчника не е разработена тема, свързана с отразяване на тежко болни деца или със създаване на журналистически материали по теми за детското здраве, но има тематично близък раздел, озаглавен „Деца с различни способности“. От него става видно, че съображенията при разработването на такива теми са преди всичко от етичен характер, а насоките са свързани с изграждане на умения и подходящ речник, а не със съобразяване с конкретни законови изисквания.
Разликата между етичните и законовите норми е, че за неетичен подход няма кой да ви глоби или санкционира. Това стоварва на раменете на журналиста цялата отговорност да научи и приложи на практика именно такива подходи в работата си, които да не накърняват достойнството на героите на неговата история. Когато тези герои са страдащи или умиращи деца и техните близки, отговорността може да бъде трудна за носене. Още повече когато националните етични правила са общи и липсват по-конкретни насоки за работата с болни деца.
Насоките на УНИЦЕФ за етично отразяване на деца залагат по-високи стандарти. Според тях журналистите трябва да търсят информирано съгласие както от детето, така и от неговите настойници, трябва да избягват да инсценират събития или да искат от децата да разказват преживявания, които не са част от тяхната собствена история, както и да осигурят прозрачност относно самоличността на репортера и целта на журналистическия материал. Тъй като получаването на информирано съгласие за участие на дете под някаква форма в журналистически материал е задължително, в насоките се подчертава, че даването на съгласие не е осигуряване на подпис, а комуникационен процес. Той започва с оценка на способността на детето да разбере последиците от медийното отразяване и естеството на здравословното му състояние. Съгласието трябва да бъде получено при обстоятелства, които гарантират, че детето и настойникът не са обект на пряка или косвена принуда и разбират че са част от история, която може да бъде разпространена на местно и глобално ниво.
Тук обаче етичните въпроси остават в полето на държавните политики, които не просто толерират система, която не се бори с нуждата от такива кампании, а сама ги организира.
Анонимизирането на историите е един от начините да бъдат защитени децата, участващи в журналистически материал, но в повечето международни насоки този подход не се коментира еднозначно като решение на етичната дилема. В насоките си УНИЦЕФ препоръчва да се избягва публикуването на истории, които могат да поставят дете или семейството му в риск дори когато самоличността им е променена или скрита.
В насоките на Dart Center for Journalism & Trauma за отразяване на деца и младежи се споделя резервиран подход към анонимизирането, но се подчертава, че журналистическата работа с уязвими деца (каквито са и децата с тежко заболяване или състояние, съкращаващо очакваната продължителност на живота) трябва да се отличава с висока чувствителност и отговорност, като наред с това се дава обща представа какви могат да бъдат външните изяви на травмата в различните възрасти. „Защитата на децата жертви от допълнителни травми трябва да има предимство пред това да имате хубав цитат“, пишат авторите, цитирайки журналистката Рут Тайхроуб.
В споменатите по-горе насоки, създадени от УНИЦЕФ – България и АЕЖ – България, се обръща внимание на още един аспект – внимателния подбор на думи, с които се говори както с детето участник в журналистическата история, така и за детето, когато то стане неин герой.
За да насърчим положителни нагласи в аудиторията, насърчаваме журналистите да използват термина „деца с различни способности“ вместо „деца с увреждания“. Децата с увреждания са преди всичко деца и винаги трябва да виждаме детето преди увреждането,
подчертават авторите в главата „Деца с различни способности“.
Разглеждайки медийното съдържание, фокусът върху децата, нуждаещи се от палиативни грижи, е широк като върха на топлийка. Въпреки това британската организация Heard (буквално „чут, изслушан, разбран“), занимаваща се с това да създава насоки за разбираема комуникация по трудни теми, разработва кратък наръчник, озаглавен How to talk about children’s palliative care (Как да говорим за детските палиативни грижи). Наръчникът на Heard предлага темата да не започва от смъртта, страха и „последната възможност“, а от това какво всъщност представляват детските палиативни грижи – дългосрочна и всеобхватна подкрепа за детето и цялото му семейство. Вместо да „развенчава митове“, той препоръчва да се разказва нова история: за грижа, която помага на тежко болните деца да останат преди всичко деца – с приятелства, игра, радост, обикновени дни и важни връзки.
Особен акцент е поставен върху отношенията – между детето, родителите, братята и сестрите, лекарите, медицинските сестри, терапевтите и всички хора, които заедно изграждат добрата грижа.
Всички съществуващи насоки обаче накрая завършват в ума, думите и сърцето на този, който разказва историята. В съвременния свят това може да бъде всеки и не е задължително да си професионален журналист, за да се чувстваш обвързан с професионалната журналистическа етика, когато публично разказваш истории.
Когато става дума за деца с тежки заболявания и очакване да не живеят дълго, между патетичната жалост и плахото мълчание има трети път – внимателен, човечен и професионален разказ. Именно там авторът може да бъде не сигнална лампа, пощенска кутия или огледало, а едновременно закрилник и създател в света на децата, нуждаещи се от палиативни грижи.
Настоящата публикация е създадена по проект „Да говорим с грижа: Палиативните грижи за деца през погледа на медиите“. Проектът се осъществява благодарение на най-голямата социално отговорна инициатива на Лидл България „Ти и Lidl“, в партньорство с Фондация „Работилница за граждански инициативи“, Български дарителски форум и Асоциация на европейските журналисти. Отговорността за съдържанието е на журналистката Надежда Цекулова и по никакъв начин не отразява официалните позиции на финансиращите организации.
Post Syndicated from corbet original https://lwn.net/Articles/1073400/
Joshua Hahn began his session in the memory-management track of the 2026 Linux Storage,
Filesystem, Memory Management, and BPF Summit by saying that the memory
controller for control groups is intended to provide resource allocation,
accounting, and protection from interference by other tasks. But
it was not really designed for tiered-memory systems; he is looking for a
way to improve that situation.
Post Syndicated from jake original https://lwn.net/Articles/1074280/
Security updates have been issued by Debian (atril, evince, gnutls28, haproxy, haveged, jq, kernel, krb5, libgcrypt20, nodejs, and thunderbird), Fedora (aw-server-rust, awatcher, bind, bind-dyndb-ldap, chromium, composer, docker-buildkit, docker-buildx, dotnet10.0, dotnet8.0, dotnet9.0, evince, firefox, httpd, kernel, nodejs-aw-webui, nss, perl-Apache-Session-Browseable, pie, python-pulp-glue, python-requests, and python3.15), Slackware (kernel), SUSE (apptainer, chromium, cockpit, dnsmasq, google-guest-agent, hauler, iproute2, jfrog-cli, kernel, libecpg6, libsolv, libzypp, zypper, mcphost, oci-cli, perl-YAML-Syck, python-lxml, python-urllib3, python311-impacket, rqlite, rsync, util-linux, and xz), and Ubuntu (evince, linux-azure, linux-azure-5.4, linux-azure-fips, linux-azure-4.15, linux-azure-fips, linux-fips, linux-gcp-5.15, linux-lowlatency-hwe-5.15, linux-oracle-6.17, node-path-to-regexp, and rclone).