Post Syndicated from Patrick Kennedy original https://www.servethehome.com/gigabyte-g383-r80-aap1-amd-instinct-mi300a-server-review/
We check out the GIGABYTE G383-R80-AAP1 an AMD Instinct MI300A supercomputer server with a unique APU architecture
The post GIGABYTE G383-R80-AAP1 AMD Instinct MI300A Server Review appeared first on ServeTheHome.
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=N2KUNTsDp0g
Post Syndicated from Explosm.net original https://explosm.net/comics/everything
New Cyanide and Happiness Comic
Post Syndicated from Curious Droid original https://www.youtube.com/watch?v=iK8abB0efW4
Post Syndicated from Explosm.net original https://explosm.net/comics/be-my-dad
New Cyanide and Happiness Comic
Post Syndicated from Надежда Радулова original https://www.toest.bg/sedmitsata-25-31-mai/
С балончета, с пръчици леки –
като перца
изписваме с букви големи
за всички деца:
Лека нощ, лека нощ,
лееекааа ноооощ!
Тези приспивни думи са от една древна (по-древна и от мен) песничка от предаването „Лека нощ, деца“, известно още като „Сънчо“ (ама Сънчо още отпреди станалото „вайръл“ – ако използваме езика на днешните деца – „Аз съм Сънчо, ида от горица“). Та напоследък тези балончета, пръчици и перца ненадейно изплуваха в паметта ми благодарение на извънредно забавната обществена поръчка за прескъпо струващи икони, балони, бонбони, топки, мешки, смешки и прочее поучително-увеселителни артикули, с които МВР да образова децата така, щото да се пазят от юнаците зад волана.
Разбира се, този умопомрачителен списък с артикули заслужено се предвожда от иконите и това е напълно разбираемо. Та нали се радваме на образование, модерно, толерантно и изтъкано от междупредметни връзки. Сега новият предмет добродетели и религии ще черпи с пълни шепи от материалната база на часовете по безопасност на движението. И обратното. Изобщо, въпросните 420 000 лева, срещу които всички писнаха, ще се избият още преди края на първия срок… Докато пътни знаци и икони заедно навигират децата ни по пътищата на родината, а ние, спокойни за тях, тънем в сън и без участието на къдравото момченце от горицата – така и така вече са ни хвърлили достатъчно прах в очите.
На фона на това изобщо не се оплаквайте, ако вцърковеното честване на 24 май пред Паметника на Кирил и Методий в София в края на миналата седмица ви е се е сторило въздълго и тегаво предвид доминиращия програмата молебно-водосветен елемент. Това нищо не е. Най-хубавото предстои – държавата се е погрижила, ей го къде е 15 септември.
От тази любима моя тема за образованието скачам на нещо наистина умно и приятно за четене в настоящия брой – новата рубрика „Вкусната страна“, в която Чило Попов ще ни разхожда из България и Балканите, за да ни среща с интересни хора, произвеждащи храни и продукти, а за капак ще повдига капака на личната си тенджера, за да споделя с нас по някоя и друга рецепта. Рубриката започва с материал за аспержите – „Завръщането на буржоазния зеленчук“ (шшшт, да не чуе Костадинов, че ще размаха чукундура).
Още един интригуващ разговор предлага и рубриката ни „Игромислие“, която този път се фокусира върху моралната двусмисленост на видеоигрите. Или по-конкретно, в „Киберпънк 2077“. Удоволствие и лудонаративен дисонанс“ Миглена Николчина, Северина Станкева, Еньо Стоянов и Николай Генов разискват противоречията между наратив и игрова механика. И ще продължат тази тема и в следващите няколко издания на рубриката – затова следете внимателно.
Пореден разговор в броя – „Даниела Михайлова и Дора Петкова – за служебните адреси, личните документи и порочните кръгове“. Светла Енчева задава въпросите, а всички отговори водят до заключението, че без адресна регистрация автоматично преставаш да си част от обществото.
И докато с православни икони се опитваме да регулираме движението по пътищата, Анастасия Орманджиева ни разказва за едно революционно събитие в медицината – „Трънливият път до успешната трансплантация на трахея“.
Трънлив и изпълнен с опасности е и дългият път, вървян от ДПС, особено откакто прие в редиците си момчето Пеевски – „новото начало“ на „доброто“ старо автентично „движение“. За най-новите развития в лагерите на почетния председател и на еманципиралия се олигарх – четете седмичния политически анализ на Емилия Милчева „Сериалът не е турски“.
За да ни е по-лесно да преглътнем седмицата, винаги е добре да отворим книга. А и в момента тече Пролетният панаир на книгата в парка пред НДК, така че, ако имате път из столицата (и чадър подръка), разходете се дотам. Освен всичко друго, ще можете да откриете и трите заглавия, които Зорница Христова ни препоръчва този месец в рубриката си „По буквите“ – „Да ти бъда тяло“ от Албена Тодорова, „Маслен нос“ от Владислав Христов и „Дървеният костюм“ от Йордан Д. Радичков. С повечко късмет дори може да си тръгнете с автографи от авторите.
Стихотворението, с което напускаме месец май, е на Виолета Кунева и носи ултимативното заглавие „Или истината, или“.
за мъртвите цялата истина
иначе се събуждат,
се казва в стихотворението. А настоящият момент, който – въпреки различията – обитаваме заедно, го доказва.
И докато чакаме Христо Грозев да публикува поредното разследване, с което да разкрие името на български журналист на руска хранилка, вижте (ако все още не сте го направили) този кратък филм на Мая Димитрова за пропагандните машини и машинисти днес, който БНТ сметна за редно да излъчи в 23:25 ч. Няма да ви казвам повече – сами ще се убедите в размера на бедствието, пряко следствие от некачествено образование и осакатени, превзети медии.
Ако и на вас ви е писнало да ви хвърлят прах в очите и да сте част от общество, управлявано от „архитектите на хаоса“, подкрепете ни, за да сме заедно. Иначе горим.
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=lzBPfL1oDu4
Post Syndicated from Oglaf! -- Comics. Often dirty. original https://www.oglaf.com/penumbra/
Post Syndicated from Боян Юруков original https://yurukov.net/blog/2025/cherna-pista/
Поздравления на Мартин Атанасов за картата, но също така, че е пуснал свободно справката, която са му предоставили от МВР. Наистина се е постарал с визуализацията и е направил нещо, което взима сурови данни и ги показва по разбираем начин.
Забелязах нещо сред коментарите, включително многобройните статии в медиите, което има нужда да се уточни. На много места се говорят неща в посока, че „държавата разчита на ученик да ѝ върши работата“ и „едно момче направи това, което цяла държава не направи“. Не съм съгласен. Това, което Мартин е направил е похвално, включително защото е успял да получи по ЗДОИ данните от МВР, за които много хора търсим и питаме и съдим от години. Многократно през последните 15 години съм повтарял, че не е работа на обществените институции да правят такива визуализации, а да предоставят свободно данните в разбираем и структуриран вид. Картата на Мартин е демонстрация на една от причините защо това е важно.
Последният съм, който ще хвали МВР за предоставяне на данни – все пак именно заради липсата им сложих на пауза проекта Lipsva. В случая обаче са направили именно това, което се очаква от тях като институция. Когато ги исках преди 10 години ми се изсмяха. Преди пет години исках пак и се пробвах да съдя. Миналата година ги искахме с Жоро Пенчев и Божидар Божанов и казаха, че ще помислят как да ги изготвят. Божанов писа днес, че преди два месеца е питал отново да ги предоставят публично и са казали, че „било много сложно“.
Та наистина браво на Мартин, че е успял да ги получи най-накрая и ги пуска свободно. Свалих ги да ги разгледам, защото именно картата му ми показа няколко странни неща, които може би показват повече за работата на КАТ, отколкото за катастрофите. Ако някак не сте видели още, ще я намерите на chernapista.com.
Впрочем, сетих се, че преди 13 години бях направил проект за crowdsourcing на данни за катастрофите. Вадеше данните от бюлетина на КАТ София, но тъй като не бяха геокодирани, а имаха странни адреси, бях направил инструмент и с помощта на хора в Twitter ги поставяхме на карта всеки ден. Продължи доста дълго време и беше интересен експеримент, в който научих доста за модерацията на такива проекти. После се опитах да направя и подобна карта за престъпността, но и тя спря недълго по-късно заради невъзможността да се модерират и изчистват данните. Знам, че МВР има данни за престъпността с точност до части от квартал още през 2015-та, но не ги публикуват никъде.
The post Черна писта или защо точно така следва да работят отворените данни first appeared on Блогът на Юруков.
Post Syndicated from Brendan Jenkins original https://aws.amazon.com/blogs/devops/new-and-improved-amazon-q-developer-experience-in-the-aws-management-console/
Amazon Q Developer just launched a new agentic experience within the AWS Management Console, that enables builders to get deeper insights about their AWS resources and improve their operational troubleshooting efficiency. This expands the agentic capabilities of Amazon Q Developer from both the integrated development environment (IDE) and command line interface (CLI) to the AWS console. Amazon Q Developer now functions as a resource analysis and operational troubleshooting assistant, able to consult multiple information sources and resolve complex queries, to get deeper insight into AWS environments faster and more easily than before. These capabilities are also available in chat applications such as Microsoft Teams and Slack. Now users can ask any question about AWS services and their resources, leaving Amazon Q Developer to automatically identify appropriate tools for the task, selecting from any AWS API across all services. It breaks queries into executable steps, asks for clarification when needed and combines information from multiple services to solve the task at hand. It can help analyze relationships between resources across multiple AWS services, examine configurations spanning different parts of infrastructure, synthesize information from various data sources to provide comprehensive insights, and respond to complex queries with detailed, actionable information.
For example, while troubleshooting an AWS Lambda function, a builder can simply ask, “How is this Lambda function getting invoked?” or “What are the IAM roles and permissions of my Lambda function?” and Amazon Q Developer will provide insights about the dependencies and interdependencies, evaluating their integration with other AWS services – all from a single natural language prompt. This enhancement allows builders to quickly obtain nuanced, contextual information about their AWS environment, significantly reducing the time and effort required for complex infrastructure analysis.
In this blog post, I’ll showcase several examples of complex prompts to demonstrate how Amazon Q Developer now delivers relevant and insightful responses based on the builder’s specific resources. Specifically, we’ll deep-dive into two main use cases: deeper resource introspection analysis and increased operational troubleshooting efficiency.
Amazon Q Developer now offers enhanced capabilities that make it even easier for builders to understand their AWS resources. With a single prompt, builders can now get comprehensive insights about their AWS services that previously required multiple steps. For example, when analyzing Amazon Simple Notification Service (SNS) topics and their subscribers, builders can simply ask “Show me all my SNS topics and their subscribers” to get a complete view of their configurations. This streamlined approach saves valuable time and effort, allowing developers to focus on building rather than navigating through multiple queries.
These new enhanced capabilities enable builders to simply ask for the insight needed, and Amazon Q Developer will perform the necessary multi-step reasoning based on a builder’s prompt. When the request is made, Amazon Q Developer determines the analytical steps required, retrieves information about the resources from multiple data sources, analyzes the relationships and configurations, and provides a comprehensive answer that addresses the need. Rather than builders having to think about which APIs to call or which services to check, Amazon Q Developer handles the complexity of the analysis, allowing builders to focus on understanding infrastructure rather than querying it.
To illustrate Amazon Q Developer’s capability in handling complex queries, let’s consider an example. Suppose a builder has a three-tier web application in an AWS account and they need to identify which Amazon Elastic Compute Cloud (Amazon EC2) instances, based on their Amazon Machine Images (AMIs) in the application layer, are actively communicating with Amazon Relational Database (RDS) in the backend. With this new update, a builder could open a new Amazon Q Developer chat in the AWS Management Console, and enter a prompt such as “List the AMIs used by my running EC2 instances in us-west-2 that can communicate with my RDS cluster”.
Figure 1: Prompt to Amazon Q Developer and Amazon RDS database
Based on Amazon Q Developer’s response shown in figure 1 above, Amazon Q Developer was able to list the steps it took to gather the information, pulled applicable information from each service API, and gave one comprehensive and detailed insight about which AMIs were being used to communicate with the Amazon RDS cluster. This shows how Amazon Q Developer can take a single prompt, pull in information from multiple resources and give a comprehensive insight.
Let’s move to another example around AWS Lambda. Suppose a builder wants to know which AWS CloudFormation stacks are managing Lambda function resources. To do this, a builder could enter a prompt such as “List my AWS Lambda functions and the CloudFormation stacks that manage those resources”.
Figure 2: Prompt to Amazon Q Developer about Lambda and AWS CloudFormation
As shown above in figure 2, Amazon Q Developer was able to pull AWS CloudFormation information related to the AWS Lambda resources, and list each stack that was associated with the Lambda functions in the account. This, for example, can help many development and IT professionals better understand and manage their account resources by leveraging the complex reasoning of Amazon Q Developer.
Proceeding with one more example around AWS Lambda, let’s now suppose a builder wants to use Amazon Q Developer to see if there are any Amazon Simple Storage Service (Amazon S3) buckets invoking an AWS Lambda function in their AWS account. To identify this, a builder could enter a prompt such as “What AWS Lambda functions do I have in us-east-1 and are any of them invoked by an Amazon S3 bucket in the same region?”.
Figure 3: Prompt and response from Amazon Q Developer about Amazon S3 and AWS Lambda
As shown in figure 3 above, Amazon Q Developer again called applicable service APIs to analyze Amazon S3 and AWS Lambda resources and was able to find that there was one AWS Lambda function with S3 as an event trigger.
Furthermore, building on our previous example, builders can try prompts around costs as well. For example, a builder can now prompt Amazon Q Developer “How much did I spend on Lambda functions that are invoked by my S3 bucket?” and Amazon Q will use its deeper resource introspection to tie costs to the resources that are connected.
These examples demonstrate Amazon Q Developer’s enhanced capability to process complex prompts involving multiple resource relationships. This improvement allows builders to obtain comprehensive answers with fewer steps, streamlining the overall process of asking questions about resources in accounts and making it easier to understand and manage AWS resources.
Amazon Q Developer can not only discover resources, their configurations, and their relationships, but also correlate that information with logs, metrics, and events to identify, analyze, and determine the root cause while troubleshooting operational issues in the AWS console. This helps streamline the process of resolving issues to enable quick troubleshooting.
To illustrate Amazon Q Developer’s capability in improved operational troubleshooting, let’s consider an example. Suppose a builder has a simple payment processing application consisting of Amazon API Gateway, AWS Lambda, and Amazon RDS in the backend. Furthermore, the application is returning 500 internal server errors causing downstream issues. Now, a builder can prompt Amazon Q Developer “Why is my user-profile-service-prod Lambda function throwing a 500 Internal server error?”.
Figure 4: Prompt to Amazon Q Developer about internal server error
As shown above in figure 4, Amazon Q Developer automatically begins to gather relevant Amazon CloudWatch metrics, examines the function’s configuration and permissions, checks connected services like API Gateway and Amazon RDS, and analyzes recent changes
Figure 5: Response from Q Developer for database timeouts
As shown above in figure 5, after querying applicable resources, Amazon Q Developer identified the root cause of the 500 internal server error. It shared information it pulled from the database and Lambda function logs and referenced a custom CloudWatch metric dashboard for evidence that the issue is due to database connection timeouts. Lastly, Amazon Q Developer also provided a list of ways to resolve the issue it identified. This example showcases how this new capability streamlines the process of analyzing operational issues, enabling quick troubleshooting.
The examples we’ve shown demonstrate how Amazon Q Developer handles the heavy lifting for users even better than before – from breaking down requests into analytical steps, to gathering data from multiple sources, to delivering meaningful insights about infrastructure, costs, and providing troubleshooting assistance.
As we continue to enhance Amazon Q Developer’s multi-step reasoning capabilities, builders will see it tackle even more complex analysis scenarios, helping them better understand and optimize AWS environments. Whether analyzing security configurations, examining resource relationships, or troubleshooting infrastructure issues, Amazon Q Developer can help save time and provide deeper insights into AWS resources.
To learn more and get started, visit Amazon Q Developer and Chatting with Amazon Q Developer in AWS Console Documentation.
Post Syndicated from Patrick Kennedy original https://www.servethehome.com/minisforum-ms-a2-review-an-almost-perfect-amd-ryzen-intel-10gbe-homelab-system/
In our Minisforum MS-A2 review, we take a look at the 10GbE, AMD Ryzen system with 16 cores that will be a hit with the homelab community
The post Minisforum MS-A2 Review An Almost Perfect Homelab System appeared first on ServeTheHome.
Post Syndicated from Anton Aleksandrov original https://aws.amazon.com/blogs/architecture/how-launchpad-from-pega-enables-secure-saas-extensibility-with-aws-lambda/
Large organizations increasingly adopt software as a service (SaaS) solutions to focus on business priorities, reduce infrastructure management overhead, and optimize costs. These organizations expect SaaS vendors to provide customizability facilities for tailoring the solution behavior according to their needs. Although traditional approaches like feature flags and webhooks offer some flexibility, they often fall short of providing a high degree of customizability. A new emerging pattern in this space is tenant-supplied custom code execution, which allows tenants to inject their own code into specific workflow points, enabling deep customization while preserving the core SaaS solutions’ integrity and security.
In this post, we share how Pegasystems (Pega) built Launchpad, its new SaaS development platform, to solve a core challenge in multi-tenant environments: enabling secure customer customization. By running tenant code in isolated environments with AWS Lambda, Launchpad offers its customers a secure, scalable foundation, eliminating the need for bespoke code customizations.
Launchpad, which is built on AWS, is an end-to-end platform on which software providers can build, launch, and operate workflow-centric B2B SaaS applications and AI solutions. It provides a managed, secure, scalable cloud environment for hosting multi-tenant applications and data. It accelerates the build experience with generative AI-powered low code tools, prebuilt capabilities, and subscriber-level configuration. Being a multi-tenant platform at its core, Launchpad had to maintain stringent isolation across tenants in its architecture.
One of the requirements Launchpad had was to allow their tenants to augment the workflows natively by providing custom code. Some common scenarios included communicating with external systems with proprietary non-industry-standard protocols, reuse of existing business logic, and SDK-based custom code development.
The solution necessitated the ability for tenants to provide custom code that would implement the required business logic, which Launchpad would be executing. This required architecting a secure runtime environment for custom code execution that maintains the highest degree of cross-tenant isolation within the multi-tenant architecture, at the same time allowing sufficient access to platform APIs and services. It was essential to build an architecture that would decouple the environment running tenant code from the core SaaS platform, as illustrated in the following diagram.
To achieve the required high level of compute isolation for running code provided by different tenants, Launchpad has adopted Lambda functions in its architecture as the secure ephemeral compute environment. Each untrusted code snippet provided by tenants is bootstrapped as a stand-alone Lambda function, with strong Firecracker-based isolation across different functions and execution environments addressing Launchpad’s requirements. This isolation provides dedicated resources, customizable access permissions, independent monitoring and operations, and automatic scaling for each function, while maintaining complete separation from other functions and their execution environments, as illustrated in the following diagram.
With Lambda being a serverless compute service, adopting it for the Launchpad architecture yielded several significant benefits. The major business benefit was that tenants could implement thousands of custom workflow augmentations on their own simply by providing code snippets, instead of the Launchpad engineering team being responsible for implementing them in the core platform code. Other benefits included:
To further reduce risks, Launchpad runs these Lambda functions with untrusted code in a dedicated AWS account. This account is separated from the core SaaS platform account. When end-users create a new function in the Launchpad authoring portal, they upload their code and specify the code handler to be executed during the invocation. Users can also map function input and output to Launchpad fields for further processing to enable an even higher degree of customizability and integration. The multi-tenant authoring service is a Control Plane component that runs as a microservice on the Amazon Elastic Kubernetes Service (Amazon EKS) cluster and uses the Lambda API for function lifecycle management, as illustrated in the following diagram. After a function resource is created, it can be used for further invocations.
At runtime, when Launchpad needs to invoke a function, it calls the Lambda Invoke API. Before the function is invoked, the multi-tenant runtime service performs a tenancy check to make sure the request is coming from an authorized tenant by doing the token validation. After a successful validation, the service invokes the required Lambda function. To invoke functions hosted in a different AWS account, the multi-tenant runtime service uses an AWS Identity and Access Management (IAM) role to assume the required permissions and invokes the Lambda service using the AWS SDK. The sequence of interactions is shown in the following architecture diagram.
The workflow consists of the following steps:
Invoking the platform API from custom code is as straightforward as connecting to any external API. The custom code can authenticate with the platform using OAuth2. To facilitate the authentication, the developer can pass along the credentials as input parameters to the function from the core platform. Then the developer can create a corresponding record (isolated by tenant) in the platform that stores the credentials per function, and pass credentials as input parameters during invocation.
Operating a distributed architecture that runs untrusted code across multiple AWS accounts requires a comprehensive observability strategy. Launchpad’s approach combines centralized logging and monitoring with cross-account aggregation to provide a unified operational view of the platform.
The monitoring architecture uses CloudWatch Metrics to observe the Lambda functions, aggregating them through a centralized observability layer. This setup empowers platform operators to correlate Lambda function metrics with the core platform services running on Amazon EKS. Launchpad also collects per-function telemetry like function invocations, error rates, and execution time, which allows them to observe per-tenant metrics. These telemetry dimensions enable both a platform-wide and tenant-specific monitoring perspective.
For logging and troubleshooting, Launchpad implements a unified logging pipeline that aggregates Lambda function logs with application gateway and runtime service logs. Each request flowing through the system carries a correlation ID, so operators can trace execution paths across the core SaaS services and into the tenant functions running in the AWS account running tenant Lambda functions.
With this multi-layer observability architecture, Launchpad can maintain operational excellence while running tenant code securely at scale. Regular operational reviews drive continuous improvements in monitoring coverage and incident response procedures. Having per-tenant Lambda functions make it possible for Launchpad to use tenant-specific cost allocation tags, further empowering them to understand the cost footprint of running tenant custom code.
When building a SaaS solution, maintaining a unified core code base is essential for scalability and manageability. Implementing per-tenant variations within the core platform code can lead to maintenance complexity and technical debt. Instead, architect your SaaS solution to have extension points, which allow your tenants to inject their custom code at specific points in the workflow, enabling customization without compromising the platform’s maintainability. This pattern makes sure the core SaaS platform remains clean and standardized while offering the flexibility that customers demand.
Additional best practices include:
The implementation of a secure untrusted code execution environment within SaaS platforms addresses a critical need for tenant customization while maintaining architectural integrity. Lambda offers a built-in isolation model, fine-grained security controls, and serverless scalability, so SaaS providers such as Launchpad can address the requirements of executing tenant-provided code in a multi-tenant environment and offer robust customization capabilities while maintaining strict security boundaries and operational efficiency. This architectural pattern enables providers to focus on core platform development while confidently supporting tenant-specific workflows through the secure and scalable Lambda execution environment.
To learn more, refer to the Security Overview of AWS Lambda white paper. For additional serverless architectural patterns, see Serverlessland.com.
Post Syndicated from corbet original https://lwn.net/Articles/1022054/
The seventh edition of the Power Management and Scheduling
in the Linux Kernel Summit (known as “OSPM”) took place on March 18-20,
2025. Topics discussed on the third (and final) day include proxy
execution, energy-aware scheduling, the deadline scheduler, and an
evaluation of the kernel’s EEVDF scheduler.
Post Syndicated from Spencer McIntyre original https://blog.rapid7.com/2025/05/30/metasploit-wrap-up-05-30-2025/
Metasploit has supported SOCKS proxies for years now, being able to both act as both a client (by setting the Proxies datastore option) and a server (by running the auxiliary/server/socks_proxy module). While Metasploit has supported both SOCKS versions 4a and 5, there became some ambiguity in regards to how Domain Name System (DNS) requests are made by Metasploit through these versions. Both versions 4a and 5 notably enable clients to make connections to hosts identified by hostnames leading to the DNS resolution to take place on the SOCKS server. Whether or not the SOCKS client chooses to resolve the hostname to an address itself or to use the server is an implementation detail that is inconsistent among many pieces of software.
In the case of Metasploit, the framework opted to handle the DNS resolution itself. This was to ensure consistent behavior of running a module with and without a proxy when the target hostname resolved to multiple IP addresses. Many years ago, when Metasploit shifted focus to assessing targets in bulk, we decided that if a hostname was specified as a target by a user that mapped to multiple IP addresses, the module should be run for each IP address. This behavior is mostly intended for modules targeting web servers and can be seen by running the auxiliary/scanner/http/http_version module with a target behind a CDN such as cloudfront (it’s pretty easy to guess a suitable example here).
This did however introduce a problem for users that intended to use Metasploit as a SOCKS proxy client by setting the Proxies datastore option because Metasploit was performing the DNS resolution instead of passing the hostname to the proxy server as the user might expect. To explicitly facilitate what is probably the expected behavior of using the proxy server for name resolution, Metasploit added the unofficial SOCKS5H scheme used by cURL and other clients. The convention here being that if SOCKS5H is used, that the proxy server should be used for name resolution. Now in this case, Metasploit users can leverage the resolution capabilities of the SOCKS5 server, however that may be implemented, to initiate their connection.
To use this new capability, simply specify the server in the Proxies option as socks5h://192.0.2.0:1080 where 192.0.2.0 is the target SOCKS5 server.
At this time, Metasploit does not currently have client support for the older SOCKS4a version. If this is something that would interest you, please let us know in our ticket.
Authors: Muhamad Visat and Valentin Lobstein
Type: Auxiliary
Pull request: #20185 contributed by Chocapikk
Path: gather/wp_depicter_sqli_cve_2025_2011
AttackerKB reference: CVE-2025-2011
Description: This adds a module for exploiting CVE-2025-2011 which is an unauthenticated SQL injection vulnerability in the "Slider & Popup Builder" plugin versions <= 3.6.1.
Authors: H00die Gr3y and Huntress Team
Type: Exploit
Pull request: #20096 contributed by h00die-gr3y
Path: windows/http/gladinet_viewstate_deserialization_cve_2025_30406
AttackerKB reference: CVE-2025-30406
Description: This adds an exploit module for Gladinet CentreStack/Triofox, the vulnerability, an unsafe deserialization allows execution of arbitrary commands.
method incorrectly.vmware_vcenter_vmdir_auth_bypass module and accompanying documentation to refer to the new datastore option name.You can always find more documentation on our docsite at docs.metasploit.com.
As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:
If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
commercial edition Metasploit Pro
Post Syndicated from Geographics original https://www.youtube.com/watch?v=GU7c_c4lnNM
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=8n9-4fn42AU
Post Syndicated from David Johnson original https://www.backblaze.com/blog/the-hidden-costs-of-ai-why-your-cloud-bill-is-exploding/
AI workloads don’t play by the same rules as your average enterprise app, and if you’ve looked at your cloud bill lately, you probably know that already. They have unique demands that make them especially vulnerable to hidden AI storage costs. Think: massive parallel GPU training, nonstop data shuffling, and frequent checkpointing.
The problem? Most cloud pricing models weren’t built for this kind of action. They were designed when workloads were a lot more predictable. So, when you run AI workloads on storage models built by hyperscalers, the costs add up quickly, and often invisibly.
Struggling to keep AI storage costs under control? Download our free ebook to discover how to optimize cloud storage for AI workloads—without compromising performance.
Here are five reasons your cloud bill for AI workloads could spiral out of control:
AI workloads are packed with transactions. Every ingest of raw data, training round, inference batch, or logging step triggers API calls—PUTs, GETs, LISTs, and COPYs. If you’re training a foundational model like Deepseek v3 or Llama 2, you could be making millions of small transactions a day just by uploading all the raw data you require for training.
Each transaction might cost a fraction of a cent—but they add up.
Example: Let’s assume a model needs 1 trillion pretraining tokens. Different data sources contribute varying numbers of tokens per file. For this exercise, let’s assume the following token counts:
A typical large language model (LLM) training mix might look like this:
| Source | % of tokens | Tokens contribution | Files required (approx.) |
|---|---|---|---|
| Web pages | 40% | 400B tokens | 400M files |
| Books | 20% | 200B tokens | 2M files |
| Code | 15% | 150B tokens | 300M files |
| News articles | 15% | 150B tokens | 187.5M files |
| Academic papers | 10% | 100B tokens | 20M files |
| Total | 100% | 1T tokens | ~909.5M files |
If you’re ingesting 909.5 million files to AWS S3 at $0.005 per 1,000 PUTs (pricing as of April 2025), then you’d be charged:
That’s $4,547.50 in just PUT transaction fees—for just collecting all the data you need for training. And that’s not counting GETs, LISTs, or any other operations that are necessary to support the full AI data pipeline.
Models trained on image slices, text tokens, or time-series data can create millions of small files. These not only trigger excessive API calls, but also suffer from the following:
This mismatch means your dataset of 100 million 10KB files could behave (and cost) like a much larger, high-churn workload.
Deep archive tiers may be cheap upfront, but they’re a poor fit for iterative AI workflows. Need to rehydrate training data to rerun a model? Get ready to wait hours and pay per retrieval. Need to delete? You could get hit with minimum retention penalties, and pay for that data as if you held onto it for 60, 90, or even 180 days.
AI workflows are iterative. You’re not archiving log files; you’re experimenting, fine-tuning, and reprocessing constantly. Cold storage is rarely compatible with that.
Egress is a silent killer. It’s the fee you pay every time you move data out of cloud storage. In AI workflows, that’s often necessary for:
These fees scale linearly with data volume, which is a problem when your AI pipeline is pulling terabytes or petabytes per day.
You might set up lifecycle rules to move infrequently accessed data to cheaper tiers—sounds smart, right?
Except:
And all of this assumes you even know your data’s “temperature” in advance—which, in AI workflows, changes day to day.
Your AI pipeline isn’t just a compute problem: It’s a data movement and storage orchestration engine. And that’s exactly where traditional cloud pricing models fall short.
If your cloud bill is blowing up, it’s probably not just because you kicked off another training run. It’s the millions of GET requests, the silent egress charges, and those archive tier retrievals you didn’t plan for.
The good news? Once you know where the hidden costs are, you can start building smarter.
The post The Hidden Costs of AI: Why Your Cloud Bill is Exploding appeared first on Backblaze Blog | Cloud Storage & Cloud Backup
Post Syndicated from Sairam Vangapally original https://aws.amazon.com/blogs/big-data/packscan-building-real-time-sort-center-analytics-with-aws-services/
Amazon manages a complex logistics network with multiple touch points, from fulfillment centers to sort centers to final customer delivery. Among these, sort centers play a crucial role in the middle mile, providing faster and more efficient package movement. Within Amazon’s Middle Mile operations, high-volume sort centers process millions of packages daily, making immediate access to operational data essential for optimizing efficiency and decision-making. Real-time visibility into key metrics—such as package movements, container statuses, and associate productivity—is critical for smooth logistics operations. To address the need for real-time operational planning, the Amazon Middle Mile team developed PackScan, a cloud-based platform designed to provide instant insights across the network. By significantly reducing data latency, PackScan enables proactive decision-making, so teams can monitor inbound package flows, optimize outbound shipments based on live data, track associate productivity, identify bottlenecks, and enhance overall operational efficiency—all in real time.
In this post, we explore how PackScan uses Amazon cloud-based services to drive real-time visibility, improve logistics efficiency, and support the seamless movement of packages across Amazon’s Middle Mile network.
This post assumes a foundational understanding of the following services and concepts:
Although hands-on experience is not required, a conceptual understanding of these services will help in understanding the architecture, design patterns, and components discussed throughout the article.
Amazon’s sort centers handle over 15 million packages daily across more than 120 facilities in North America. Given this scale, even minor delays in operational insights can lead to inefficiencies, increased costs, and escalations. Traditionally, data latencies of up to an hour have restricted the ability to make proactive decisions, directly affecting productivity, resource allocation, and responsiveness—especially during peak periods like holiday seasons and big deal days.
Without immediate visibility into package movements, container statuses, and associate performance, operational teams face challenges in identifying and resolving bottlenecks in real time. The lack of timely insights can disrupt the flow of packages, leading to shipment delays, reduced throughput, and suboptimal facility performance. Addressing these inefficiencies required a solution capable of delivering real-time, high-fidelity data to support rapid decision-making.
To bridge this gap, Amazon’s Middle Mile organization needed a scalable platform that could enhance visibility, minimize latency, and provide up-to-the-minute insights into logistics operations. PackScan was designed to meet these demands, giving teams access to the real-time data necessary to optimize workflows, mitigate bottlenecks, and improve overall efficiency.
In 2024, PackScan was deployed across 80 sort centers in the USA, enabling real-time package analytics. The solution powers Grafana dashboards, which refresh every 10 seconds by fetching live package data from OpenSearch Service. With this near real-time visibility, operations teams can monitor package movement and sorting efficiency across sort centers. The following diagram outlines how package scan data is ingested, processed, and made actionable.
Each sort center is equipped with hardware at inbound stations where packages arrive from trailers. Integrated barcode scanners automatically scan each package as it enters the sorting process. Every scan generates an SNS event, capturing key attributes such as the package ID, dimensions, the associate who performed the scan, and the timestamp and location of the scan.
After they’re generated, these SNS events are ingested into Data Firehose through a Lambda function, where the data undergoes real-time enrichment. During this process, additional attributes are appended, including the business logic rules. The enriched data is then streamed into OpenSearch Service, where events are indexed to enable fast and efficient querying. With the indexed package scan events available in OpenSearch Service, real-time analytics and monitoring become possible. The Grafana dashboards query this data every 10 seconds, providing operational insights into package inflow metrics and associate performance.
PackScan was implemented using a structured and scalable approach, using AWS cloud-based services to enable high-frequency data ingestion, real-time processing, and actionable insights. The architecture is designed to minimize latency while providing reliability, scalability, and operational efficiency. The solution is built around a serverless, event-driven architecture that dynamically scales based on data ingestion volumes. The architecture—illustrated in the following figure—enabled us to build a real-time data solution, utilizing the advantages of various AWS services to provide low-latency analytics, high scalability, and real-time operational insights across Amazon’s sort centers.
The following are the key components and features of the solution:
The entire PackScan architecture is designed for automatic scaling, adjusting dynamically based on data ingestion volume to maintain efficiency during peak and off-peak operations. This approach provides cost-effective resource utilization while maintaining high availability and performance.
The implementation of PackScan has led to measurable improvements in operational efficiency, workforce productivity, and real-time decision-making across Amazon’s sort centers. By reducing data latency and enabling real-time insights, PackScan has transformed logistics operations in meaningful ways:
Overall, PackScan has redefined real-time logistics visibility within Amazon’s Middle Mile operations, empowering operational teams with actionable insights, enhanced workforce efficiency, and a data-driven approach to package movement and sort center performance.
The deployment and scaling of PackScan provided valuable insights into optimizing real-time logistics visibility. Several key lessons and best practices emerged from this implementation:
| AWS Service | Description | Estimated Monthly Cost |
| Amazon EC2 | Three EC2 instances of type m5.12xlarge hosting Grafana | $1,700 |
| AWS Lambda | Streams SNS events to Data Firehose | $4,000 |
| Amazon Data Firehose | Real-time data delivery with 12,000 records streaming to OpenSearch Service | $1,500 |
| Amazon OpenSearch Service | Indexing and querying package scan events | $28,000 |
By applying these best practices, PackScan has set a foundation for scalable, real-time logistics management, making sure that Amazon’s Middle Mile operations remain proactive, efficient, and highly responsive to changing business demands.
PackScan has successfully transformed real-time operational visibility within Amazon’s sort centers, addressing critical challenges in data latency, workforce productivity, and logistics efficiency. By using AWS services, particularly Data Firehose for real-time data delivery and OpenSearch Service for analytics, PackScan has enabled proactive decision-making, streamlined operations, and enhanced throughput in high-volume sort environments. Looking ahead, future enhancements will focus on further elevating operational intelligence and scalability, including:
With these advancements, PackScan will continue to drive operational excellence, cost-efficiency, and real-time decision-making capabilities, reinforcing Amazon’s commitment to innovation in logistics and supply chain management.
For those interested in implementing similar solutions, we recommend exploring AWS Serverless Architecture Patterns and the AWS Architecture Blog for additional insights and best practices in building scalable, real-time analytics solutions.
Sairam Vangapally is a Data Engineer at Amazon with extensive experience architecting real-time, large-scale data platforms that power critical logistics operations across North America. He has led the design and deployment of end-to-end data pipelines, enabling high-throughput ingestion, transformation, and analytics at scale. He is passionate about building resilient data infrastructure and driving cross-functional collaboration to deliver solutions that accelerate operational insights and business impact.
Nitin Goyal serves as a Data Engineering Manager in Amazon’s Sort Center organization, where he leads initiatives to optimize operational efficiency across North American facilities. With over nine years of tenure at Amazon spanning multiple teams, he specializes in architecting high-performance data systems, with particular emphasis on real-time streaming pipelines, artificial intelligence, and low-latency solutions. His expertise drives the development of sophisticated operational workflows that enhance sort center productivity and effectiveness.
Post Syndicated from BeardedTinker original https://www.youtube.com/watch?v=CZ9g44mIuFA
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=Rk95IlkLhjk