Кого конкретно обслужва законопроектът на ИТН за повече небостъргачи в София?

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2025/itn-zakonoproekt/

На 7-ми септември в. Сега писа за законопроект на трима депутати от ИТН, с което се вдига ограничението на височина на застрояване на конкретни части в София. Предложението е внесено на 5-ти септември от Венцислав Асенов, Христинка Иванова и Танер Тюркоглу. Първият се бори активно в последно време с „меренето на средната скорост“ видимо като част от лобизма срещу мярката. Втората стана известна със скандали и изтекли записи показващи разцепването на партията. Третият се споменава с това, че има спорни бизнес връзки с други в партията и дъщеря му има задължения към НАП. Тримата искат да се изключат от ограниченията за височина урегулираните поземлени имоти с лице към Цариградско шосе и позволената височина да се вдигне на 125 метра. Законопроектът е едно изречение, но с голям ефект.

Сегашното положение на ЗУЗСО посочва в точка 5.3 на приложението към чл. 3, ал. 2, че в урегулирани поземлени имоти в СМФ зони с лице към голяма улица и които са на 400 м. от метроспирка може да се застрояват до 100 метра. Има обаче изключение изрично за райони Триадица, Лозенец, Младост и Изгрев, където ограничението е както във всички други СМФ зони – 75 метра. Затова кулите на Артекс, тази на 4-ти км. на Булфарма със огромния билборд със спорна законност, както и останалите в Младост, по булевардите Симеоновско, Черни връх и България са до 75 метра. Визуализация на тези зони и колко високо стигат над сегашните сгради може да видите на картата с ПУП-овете на Столична община. Натиснете бутонът с картата вляво, за да смените изгледа.

Какво точно се променя и къде?

Първо, предложението на ИТН е объркано – искат да променят точка 5.1 от приложението, а там не се споменава Младост. Т.е. в този си вид дори да се приеме няма да може да се приложи. Ако се споразумеят с НН ГЕРБ/ДПС да мине в зала, лесно може да го коригират като техническа грешка. Първо ще влиза в комисия с председател от ГЕРБ и където Асенов сам е зам. председател. Не изглежда да е бил обсъждан на заседанието на 10-ти септември.

По-важното обаче е, че освен да вдига от 100 на 125 метра ограничението за тези СМФ зони около метро спирки, маха от изключението конкретни имоти с лице към Цариградско шосе. С други думи, в цяла Младост ще може до 75 метра, но за определени имоти ще може до 125. Стана ми интересно кои са те и кой ги държи. Открих 46 имоти, които са частни, в регулация, с лице към Цариградско, в Младост (в зелено), на 400 метра от метроспирка (в синьо) и в СМФ зона. Отбелязал съм ги в червено. Има един в светло червено, който е собственост на БАН. Не е в списъка с имотите на Желязков за продаване, но от опита с паркове и градини на други места в София може да съдим, че институтът борави с държавната собственост повече като строителна компания, отколкото като средище за науката.

Тук виждате същата карта, но със сателитна снимка. Около метро спирката на арена София от страната на Младост има само държавни и общински имоти.

Кои са облагодетелстваните?

Фокусирайки се върху конкретните имоти виждаме, че повечето са малки или вече имат построени сгради. На спирка ИЕЦ/Цариградско се виждат няколко парцела, които с малко въображение и овладяване на СОС може да се прокарат изключения за разгърната площ и да се стигнат 125 метра. Това обаче е малко вероятно. Единствено първият вляво има по-голям шанс и е подал документи за ОВОС за собствен водоизточник описвайки сграда с подземни гаражи. Разбира се, имотът където се намира Метро има най-голям потенциал за комплекс с множество сгради от 125 метра. Макар да не стигат така височината на Скай Форд, ще уплътнят значително пейзажа с подобни на Капитал Форт. Няма индикации за такова желание към този момент, но промяната ще го направи напълно възможна.

Сред имотите до новата спирка след 4-ти километър попада The Mall и офис сградите около него, Бриколаж и складовете наоколо. Не се забелязват планове за по-сериозни строежи там, с изключение на една кула до паркинга на мола.

Тук попадаме на най-големия печеливш от тази схема – новият жилищен и търговски комплекс на мястото на ИПК Родина. Той беше от първите, които добавих на картата ми със застрояването още когато беше в пилотна фаза преди почти две години. Повече за него и историята му свързана с Пеевски, източването на КТБ и прочие може да прочетете в Капитал, които споделят визуализацията ми. Виждате го отново на втората снимка с височината му до 75 метра – колкото и другия проект на собствениците Булфарма отсреща на булеварда. Доколкото не може да твърдим, че има връзка между тях и законопроектът на ИТН, безспорно от всички имоти, които видях, те се облагодетелстват най-много в краткосрочен план. Достатъчно е само да изчакат да излезе в Държавен вестник и да внесат промени по проекта, които НАГ няма да може да откаже поради волята на законодателя. По принцип по каналния ред не могат да увеличат застроената площ от вече прекомерната заложената още през 2017, но дори само вдигането на височината увеличава печалбата на кв.м. драстично.

В горните снимки се фокусирам върху имотите около Цариградско шосе, защото в едното изречение на законопроекта личи, че там се целят. Тази промяна ще вдигне максималната височина и за строителство в Люлин, Надежда, Левски, Овча купел, Дружба, около летището и дори на отделни места в Слатина. В СМФ зоните там обаче вече е разрешено до 100 метра и промяната не е толкова драстична като обсъжданите горе. Все пак, ще се опитам да разглеждам и другите райони дали ще изскочи нещо.

Защо се прави това и какво да направим?

Законопроектът на тримата от ИТН е без реална аргументация. Според тях не влияе на околните, не предвижда „разходи за държавата и гражданите“ или административна тежест. Разбира се, не споменават тежестта на община София за инфраструктура и драстичното сваляне на цената на околните имоти. Доколкото естетиката е въпрос на лично мнение, в комбинация с останалата част от нормативната уредба ще доведе до влошаване на градската среда.

Всъщност, опитват се да изтъкнат, че бъдещите сгради щели да бъдат естествена преграда за шумовото и праховото замърсяване на Цариградско. Това не е подкрепено с каквито и да е източници. Най-малкото логиката говори за точно обратното – ако иска някой преграда, трябва да има ниски и дълги сгради, които да създават стена по продължението на булеварда. Също както виждаме в момента да се случва по Черни връх, където се позволиха долепена поредица от сгради с надвишени параметри благодарение на решения на Фандъкова, ГЕРБ в СОС и тогавашния главен архитект Здравков сега наместен в софийската РДНСК да контролира собствените си заповеди и да одобрява проектите, които е уредил. Има сведения обаче, че шумово и прахово замърсяване се намалява със зелени площи и особено гъста дървесна растителност. В проекта си обаче ИТН не увеличава тези изисквания за много конкретно подбраните имоти. Така или иначе контролирането на изпълнението и поддържането на задължителното озеленяване страда сериозно.

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

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

The post Кого конкретно обслужва законопроектът на ИТН за повече небостъргачи в София? first appeared on Блогът на Юруков.

How to build resilient SMS delivery with AWS End User Messaging

Post Syndicated from Tyler Holmes original https://aws.amazon.com/blogs/messaging-and-targeting/how-to-build-resilient-sms-delivery-with-aws-end-user-messaging/

Reliable SMS delivery is a critical requirement for many businesses. However, SMS communications can be impacted by factors outside your direct control, such as carrier availability and delivery challenges.

In this post, we explore strategies for building resilient SMS architectures using AWS End User Messaging. We discuss how to architect your SMS communications at the originator, account, and Regional levels to support high availability and seamless failover, even in the face of disruptions. This includes implementing best practices like using phone pools, dedicated originators, and multi-Region redundancy.

By understanding these strategies, you can create a resilient messaging system that keeps your mission-critical SMS flowing reliably to your customers and stakeholders, regardless of external service interruptions or carrier-specific issues.

How SMS delivery works

The process of delivering an SMS message involves a complex chain of interconnected systems. The message needs to be routed to the appropriate mobile network operator (carrier) based on the recipient’s phone number, and there are many paths the message could take. When a user sends an SMS through AWS End User Messaging, the message is routed appropriately based on the country, carrier, and originator type being used.

The inherent complexity of SMS delivery means there are numerous potential service degradation points, such as issues with an aggregator, carrier configurations, and filtering. The general availability of a mobile device can also be a factor, because it’s dependent on the current health of the network the device uses. Things as simple as weather changes or location (such as parking garages) can impact the delivery of messages and illustrates why alternate channels should be provided.

Understanding this underlying architecture is crucial for building resilient SMS systems that can withstand disruptions at different stages of the process. The following diagram shows a simplified version of how an SMS is delivered to a handset.

The need for SMS resiliency

Given the complex dependencies and potential points of degradation in the SMS delivery chain, it’s critical to architect your SMS communications for resilience. This helps make sure your messages can be delivered reliably, even when facing Regional service disruptions, carrier challenges, or other potential communication barriers.

Levels of resiliency for SMS

The following are the three levels of resiliency to consider for SMS and some potential reasons for disruption:

  • Originator-level resiliency – Carriers and other downstream entities can sometimes block or filter specific origination numbers, causing delivery issues. Originators must be configured with these downstream entities, so downstream misconfigurations might occur.
  • Account resiliency – Your primary AWS account might experience a disruption, preventing you from sending messages through that account. Account-level issues, such as reaching an account SMS spending limit or throughput, might limit your ability to send from a specific account.
  • AWS Region resiliency – Regions can experience degradation of service, and originators are tied to an account and Region when they are configured and can’t be moved.

General best practices for SMS resiliency

A phone pool, also known as a pool, is a collection of originators that share the same settings. When you send messages through a phone pool, it selects an appropriate origination identity to use for sending the message based on the country code. In general, pools will select the highest throughput originator in the pool for the country being sent to. This means that the order from first to last will be short codes, long codes, sender ID, toll-free, and finally shared routes. If one of the origination identities in the phone pool is unable to send the message, the phone pool will automatically fail over to another origination identity, which is part of the same phone pool, for that same country if there is one available.

Having a dedicated originator for each country you send to improves deliverability and allows for two-way communication if the originator supports it. Pools have a setting for shared routes in some countries, which is a pool of shared origination identities that AWS maintains. When you activate shared routes on a pool and don’t have a dedicated originator, AWS End User Messaging SMS attempts to deliver your message using one of the shared identities. The origination identity could be a sender ID, long code, or short code, and could vary within each country. These shared routes are not capable of two-way communication so they are not eligible for any use cases that require it. Deliverability on these shared routes also varies; it’s always a best practice to use a shared route as a last resort option. Using at least one dedicated originator for each destination and use case you support will improve your deliverability and the experience of your end-users. Refer to How to Manage Global Sending of SMS with AWS End User Messaging for more details on getting ready to send SMS. The post includes a template for organizing use cases and selecting originators.

AWS End User Messaging provides several options for sending Delivery Receipts (DLRs), as shown in the following diagram, including Amazon Simple Notification Service (Amazon SNS), Amazon CloudWatch Logs, and Amazon Data Firehose. If you are using a multi-Region or multi-account architecture, it’s important to centralize this data. The following GitHub repo provides a solution as a deployable starter project that builds on top of an Amazon S3 storage location and combines channel engagement and conversational data into a centralized data store. You can also optionally deploy an Amazon QuickSight dashboard to visualize the engagement data.

Using the message feedback feature of AWS End User Messaging also allows for more visible and finite message statuses. You can use signals from customers to determine if they have received the message and set the message feedback status record as delivered. Using message feedback means you don’t have to wait for the DLR to be returned and you can set your message as received and update your message metrics. Message feedback can be used for typical user actions, such as completing a workflow, clicking a link, verifying a one-time password.

When choosing a repository for your DLRs, make sure to consider your data requirements related to data consistency, tolerance for latency, performance requirements, and your unique access patterns.

Strategies for resiliency at each level

Each level at which SMS operates provides layered resiliency. You don’t need to implement all the layers; this will depend on your comfort level for complexity and increased cost. In this section, we review the resiliency strategies at each level.

Originator-level resiliency

AWS recommends provisioning a minimum of two origination number types per country in each Region you are using to provide redundancy. Different originator types often use different paths to send, so if one sending is degraded on one path, you can switch to the other. The implementation itself will depend on the countries you are sending to and the level of complexity and cost you are willing to incur, because some originators have costs associated with owning them.If you decide to have multiple originators, we recommend communicating with your end-users about the methods by which you might communicate with them. This reduces the chance of spam complaints if you need to deliver SMS with an unfamiliar originator.

Let’s explore an example of designing originator-level resiliency for the US (the general pattern is the same across different countries).The US options for originators, in order of highest to lowest throughput, are short codes, 10DLC, and toll-free numbers (TFNs). Each requires registration to be completed. Depending on your throughput needs, there are a few things we recommend when implementing resiliency in the US.

If you’re using 10DLC, we recommend getting at least one other 10DLC number that you don’t use. If you encounter a filtering or blocking event by US carriers, you can use this number to swap into your pool to continue to be able to send while you solve the problem on the blocked or filtered number. This might give you more time to fix an issue while still maintaining your ability to send. The other option, and another layer of redundancy, is to register a TFN that you could swap into your pool. Although TFNs have lower throughput, this can help you continue some level of sending while solving for the blocking issue.

If you’re using a short code, you have an added layer of redundancy because carriers don’t generally block those codes without warning. You will receive an audit and be given a chance to fix whatever issue the carriers have found with your sending. Having a second short code or using a lower throughput backup such as a 10DLC or TFN is also an option.

Account-level resiliency

There is always the chance that your primary account could be degraded in some way. Issues such as an inaccessible account or hitting a spending limit can take time to mitigate. For example, Artificially Inflated Traffic (AIT), also known as SMS pumping fraud, can cause your spending limit to be hit, shutting off your ability to send from that account. To learn more, refer to Defending Against SMS Pumping: New AWS Features to Help Combat Artificially Inflated Traffic.

You can mitigate these issues by having a secondary account in the same Region that you share your originators, pools, and opt-out lists with by using AWS Resource Access Manager (AWS RAM) to enable resource sharing. You can use AWS RAM to share some AWS End User Messaging SMS resources with other AWS accounts or through AWS Organizations. The accounts being shared to must be in the same Region as the account that owns the resources. Configuring this sharing makes it possible to send from a secondary account using the same resources in the primary account. Billing on the volume is attributed to the sending account, whereas charges for the originators are billed to the account that owns them.

Region-level resiliency

There is always the possibility of a Regional degradation of services or a downstream misconfiguration for a particular originator or Region. The only way to protect your sending against this is to configure origination numbers in at least one other Region. This way, you can fail over to a secondary Region if the primary Region experiences a degradation of service. When implementing this approach, keep the following considerations in mind:

  • If a country requires registration for SMS sending, you must complete that registration separately in each Region where you plan to use an originator for that country. You can submit the same registration for each Region, or for some originators you can specify multiple Regions at the time of registration, rather than applying twice.
  • Many countries support sender IDs, and as long as they don’t require a registration, the same sender ID can be configured in multiple Regions. This simplifies the multi-Region setup. If you need to configure many sender IDs, refer to Automating Sender ID Configuration for SMS with AWS End User Messaging APIs to learn how to automate the process of configuring sender IDs across Regions.
  • Carrier availability can also be a point of failure, so it’s important to have multiple origination numbers provisioned in each Region to avoid a single point of failure.

Although this post focuses specifically on SMS resiliency, as a general best practice for your messaging system, you should also enable alternative channels as failover or primary channels. Channels such as WhatsApp, push, voice, or email offer increased resiliency in the event of a degradation of SMS service.

Automating failover

AWS End User Messaging provides DLR data for your sent messages, which is a key piece of information you can use to automate retries and handle failures. As a protocol, SMS doesn’t guarantee delivery. Depending on the country being sent to, DLRs might take up to 72 hours to be returned or in some cases might not be returned at all. For this reason, relying on DLRs alone is not enough. You might also want to monitor the health of your Region or the AWS End User Messaging service, which can be done through the AWS Health Dashboard.

For a deep dive on managing SMS deliverability, refer to A Guide to Optimizing SMS Delivery and Best Practices, which goes into more detail on the complexities of SMS delivery and how to effectively monitor your message performance.

When it comes to automating your failover process, the DLR data provided by AWS End User Messaging can be a powerful tool. By analyzing the delivery statuses and error codes, you can build logic to automatically retry messages that fail on the first attempt. The key is to build in this automation proactively, rather than relying on manual intervention. Building your failover logic ahead of time can provide for a seamless recovery when delivery issues occur, minimizing disruption to your users.

It’s also important to remember that DLRs are fallible and might take up to 72 hours to arrive. The message feedback feature will give you more insight into message status, and you don’t have to wait for the DLR to be returned. You can set your message as received and update your message metrics based on expected user actions.

The goal is to create a resilient messaging architecture that can withstand the inevitable complexities of SMS delivery. Automating your failover process is a crucial component of that strategy.

Pros and cons of multi-Region SMS redundancy

Although implementing multi-Region redundancy can increase the reliability and resilience of your SMS communications, there are both advantages and trade-offs to consider. Evaluating the specific needs of your use cases against the added complexity and costs is important in determining the optimal approach.

The following are key benefits of having a resilient SMS architecture:

  • Increased reliability and availability of SMS communications – Having redundant originators and routing across multiple Regions strengthens your ability to withstand Regional disruptions or carrier-specific issues, so you can continue sending SMS reliably.
  • Seamless failover during outages – The ability to automatically fail over to a secondary Region when issues occur in the primary Region minimizes disruptions and keeps your SMS flowing.
  • Reduced impact of carrier-specific problems – By diversifying your origination numbers across AWS accounts and Regions, you can avoid being heavily impacted by a problem with a single carrier or originator.

However, consider the following important trade-offs:

  • Increased complexity in configuration and management – Maintaining redundant resources (originators, phone pools, opt-out lists, and so on) across multiple Regions adds complexity to your SMS architecture. A multi-Region setup requires additional configuration and ongoing maintenance.
  • Additional costs – Provisioning origination numbers, short codes, and so on in multiple Regions can incur additional costs compared to a single-Region setup. There might also be costs for cross-Region data transfers if centralizing delivery logs and event data. Centralizing DLR data from multiple Regions likely requires additional storage and processing costs.
  • Potential reputation and deliverability challenges – When failing over to a different Region, your SMS messages might come from new originators. If customers aren’t prepared for this change, they might mistake legitimate messages for spam. These spam reports can harm your overall SMS deliverability rates.

Overall, the pros of increased reliability and resilience must be weighed against the cons of higher complexity and costs. The optimal approach will depend on the criticality of the SMS use cases and your organization’s risk tolerance.

Conclusion

By implementing the layered resiliency strategies outlined in this post, you can significantly improve the reliability of your critical SMS communications. Whether you start with originator-level redundancy using phone pools or build a fully Regional-resilient architecture, proactively investing in your setup helps your messages reach your customers, even in the face of unexpected challenges.

To get started, consider the following next steps:

  • Evaluate your current SMS workloads and determine what level of resiliency is right for your business needs and risk tolerance.
  • As a first step, implement phone pools in your primary Region to protect against single-originator filtering or blocking.
  • For critical applications, set up a secondary account and use AWS RAM to share your primary originators, providing a robust layer of account-level redundancy.

To learn more, explore the AWS End User Messaging documentation and the AWS RAM User Guide. For personalized guidance, work with your AWS account team to design the optimal SMS architecture for your business.

About the author

Migrating from API keys to service account tokens in Grafana dashboards using Terraform

Post Syndicated from Majdoulina Makbal original https://aws.amazon.com/blogs/big-data/migrating-from-api-keys-to-service-account-tokens-in-grafana-dashboards-using-terraform/

With the release of Grafana 9.4, Amazon Managed Grafana added support for service accounts, which have become the recommended authentication method for applications interacting with Amazon Managed Grafana, replacing the previous API key system.

While API keys are created with a specific role that determines their level of access, service accounts offer a more flexible and maintainable approach. They support multiple tokens, can be enabled or disabled independently, and aren’t tied to individual users, allowing applications to remain authenticated even if a user is deleted. Permissions can be assigned directly to service accounts using role-based access control, simplifying management of long-lived access for non-human entities like applications or scripts.

In this blog post, we walk through how to migrate from API keys to service account tokens when automating Amazon Managed Grafana resource management. We will also show how to securely store tokens using AWS Secrets Manager and automate token rotation with AWS Lambda. All infrastructure is deployed using Terraform, though the pattern can be adapted to your infrastructure-as-code framework of choice.

What are service accounts and tokens?

A service account is designed to authenticate automated tools and systems with Amazon Managed Grafana and is intended for programmatic access. A service account token is a secure credential issued to a service account and can be used to authenticate requests to the Amazon Managed Grafana HTTP API. Multiple tokens can be associated with a single service account, and tokens can be individually revoked or rotated without affecting other services or requiring changes to user accounts.

For a deeper understanding, see the Grafana service account documentation.

Solution overview

In this solution, we show you how to create a service account, reference it in your Terraform stack, and then implement rotation of the token associated with it using Lambda and Secrets Manager as shown in the following diagram:

Workflow diagram showing automated secret management between Terraform, AWS Secrets Manager, and Grafana workspace with Lambda rotation

Architecture diagram illustrating the integration between Terraform, AWS Secrets Manager secret store, and an Amazon Managed Grafana workspace, with secret rotation functionality.

The following are the basic steps to set up the solution.

  1. Set up Amazon Managed Grafana with service accounts.
  2. Update the secret in Secrets Manager with the token value.
  3. Automate resource creation in Amazon Managed Grafana using service account tokens in Terraform.
  4. Create a service account and token in your Amazon Managed Grafana workspace.
  5. Store the token securely using Secrets Manager.
  6. Use Terraform to automate Amazon Managed Grafana resource creation with the token.
  7. Automate the rotation of the service account token.

GitHub repo for cloning the code and deploying the Terraform stack.

Prerequisites

Before starting this walkthrough, make sure that you have the following:

Solution walkthrough

Use the following steps to set up and configure the solution.

Provision resources using the Terraform stack

The full source code of the solution is in sample-migrate-from-apikeys-grafana and is deployed using Terraform.

  1. Clone the repository.
git clone https://github.com/aws-samples/sample-migrate-from-apikeys-grafana.git
  1. Initialise a Terraform project.
terraform init
  1. Create infrastructure for the secrets and the Amazon Managed Grafana instance.
terraform apply —target=aws_secretsmanager_secret.token —target=aws_grafana_workspace.grafana

This step creates the Amazon Managed Grafana workspace and the Secrets Manager secret. In the next step, you bind the workspace with AWS IAM Identity Center and generate the service account token.

Retrieve service account token from the Amazon Managed Grafana workspace

You must have administrative privileges in your Amazon Managed Grafana workspace to perform this step. This applies whether you’re using IAM Identity Center or an external identity provider for authentication.

  1. To change a user’s role in AWS IAM Identity Center (console)
    1. Open the Amazon Managed Grafana console.
    2. In the navigation pane, choose Workspaces.
    3. Select the workspace you want to manage.
    4. On the AWS IAM Identity Center, choose the Assigned users tab.
    5. Select the row of the user that you want to modify.
    6. For Action, choose the following:
      • Make admin
    7. Confirm the role change.

  1. Select the workspace URL and sign in using your credentials, you should be able to create a service account under the name grafana-sa (or the name of the variable defined in /variables.tf).

  1. Assign the Editor role to the service account to allow it to create dashboards and folders. Learn more about service account roles in the Assign roles to a service account in Grafana.
  2. After the service account is created, add a service account token to it, again the name should be similar to the one defined in /variables.tf.

Add the token to Secrets Manager and create the rest of the resources

After you complete this step, the access token will be stored in Secrets Manager and will automatically be used in the provider definition during future runs of terraform apply.

  1. Copy the service account token.

  1. Paste it into the plaintext section of the Secrets Manager secret created in the previous section

  1. With the access token stored in Secrets Manager, there is no longer a need to restrict the apply operation to the rotation module using the --target flag. Use the following code to remove the restriction. 
    provider "grafana" {
  url  = "https://${aws_grafana_workspace.grafana.endpoint}"
  auth = module.grafana_sa_key_automation.grafana_sa_token
}

Clean up

To avoid incurring future charges, use the following command to delete unused Amazon Managed Grafana service accounts and Terraform-managed resources run the cli command terraform destroy.

Security notes

To protect the security of your organization, we recommend the following best practices:

  • Always follow least privilege principles. Grant the minimum permissions needed to the service account (for example, Editor instead of Admin).
  • Make sure that Amazon Simple Queue Service (Amazon SQS) queues, Secrets Manager secrets, and Amazon CloudWatch Logs are encrypted with a customer-managed KMS key if required by your organization.
  • Rotate secrets regularly to minimize exposure.

Conclusion

In this post, we demonstrated how to migrate from API keys to Amazon Managed Grafana service account tokens using Terraform, with secure storage in AWS Secrets Manager and optional automated token rotation via AWS Lambda.This modern approach improves security, scalability, and auditing in your automation pipelines.

For more information, see the Amazon Managed Grafana service account documentation.

About the authors

Majdoulina

Majdoulina Makbal

Majdoulina is a Delivery Consultant in AWS Professional Services, specialising in AI and ML solutions. With a strong background in industrial connected services, she brings extensive experience helping organisations across diverse industries transform their business vision into technological reality. Based in Munich, she’s mastering the art of explaining transformer architectures and federated learning over a Maß at Oktoberfest.

Use the Amazon DataZone upgrade domain to Amazon SageMaker and expand to new SQL analytics, data processing, and AI uses cases

Post Syndicated from David Victoria original https://aws.amazon.com/blogs/big-data/use-the-amazon-datazone-upgrade-domain-to-amazon-sagemaker-and-expand-to-new-sql-analytics-data-processing-and-ai-uses-cases/

Amazon DataZone and Amazon SageMaker announced a new feature that allows an Amazon DataZone domain to be upgraded to the next generation of SageMaker, making the investment customers put into developing Amazon DataZone transferable to SageMaker. All content created and curated through Amazon DataZone such as assets, metadata forms, glossaries, subscriptions, and so on are available to users through Amazon SageMaker Unified Studio after the upgrade.

As an Amazon DataZone administrator, you can choose which of your domains to upgrade to SageMaker through a user interface driven experience. You can use the upgraded domain to use your existing Amazon DataZone implementation in the new SageMaker environment and expand to new SQL analytics, data processing and AI uses cases. Additionally, after the upgrade, both Amazon DataZone and SageMaker portals remain accessible. This provides administrators flexibility with user rollout of SageMaker while providing business continuity for users operating within Amazon DataZone. By upgrading to SageMaker, users can build on their investment from Amazon DataZone by using the SageMaker unified platform, which serves as a central hub for all data, analytics, and AI needs.

SageMaker delivers an integrated experience for analytics and AI with unified access to all your data. Collaborate and build faster from a unified studio using familiar Amazon Web Services (AWS) tools for model development, generative AI, data processing, and SQL analytics, accelerated by Amazon Q Developer, the most capable generative AI assistant for software development. Access all your data whether it’s stored in data lakes, data warehouses, or third-party or federated data sources, with governance built in to meet enterprise security needs.

What we hear from customers

Customers have successfully used Amazon DataZone, enabling data analysts, data engineers, and machine learning teams to collaborate around a shared data catalog. With generative AI moving to center stage, these organizations now aim to address a wider range of use cases, from interactive notebook exploration to prompt engineering for generative-AI projects. Upgrading their Amazon DataZone domains to SageMaker Unified Studio brings everyone together in one place. Data analysts, data engineers, machine learning (ML) specialists, and AI innovators can create integrated solutions on the same governed data while using the tools that best match their work. For example, one of our customers, HEMA, uses Amazon DataZone as a single solution for cataloging, discovery, sharing, and governance of their enterprise data across business domains. They are moving to SageMaker to enable more machine learning and generative AI use cases.

“The launch of the domain upgrade feature allows us to take the investment from our production Amazon DataZone deployment and utilize it in Amazon SageMaker. Organizationally, we are doing more in the generative AI space and with Amazon SageMaker we can accomplish new use cases that leverage the assets curated through Amazon DataZone. With this feature we also love that both portals remain open at the same time so that we can thoughtfully transition user populations to Amazon SageMaker.”

– Tommaso Paracciani, Head of Data & Cloud Platforms at HEMA.

“We’ve invested a lot in building our data management platform for production and logistics, using Amazon DataZone, to accelerate our digital transformation. Evolving our data management solution to use Amazon SageMaker Unified Studio means Data Analysis, Data Engineering, Machine Learning & Generative AI features can now be done from the same place. With the domain upgrade feature, it allows us to onboard to Amazon SageMaker faster by utilizing the work done from Amazon DataZone“

– Volkswagen AG

Upgrade your Amazon DataZone domain to SageMaker Unified Studio

  1. On your Amazon DataZone domain home page, a banner appears at the top announcing the new domain upgrade feature. Choose Get started on this banner to open the upgrade wizard.

  1. A summary page explains the actions the upgrade wizard will perform and what to expect while it runs. Read the information carefully, then choose Start to begin the upgrade.

  1. On the configuration screen, specify the AWS Identity and Access Management (IAM) roles and ownership for your new SageMaker Unified Studio domain:
    1. Domain execution role – The runtime role the domain assumes for SageMaker operations.
    2. Domain service role – Authorizes the service to create and manage domain resources.
    3. Root domain owner (optional) – Designates the administrators of the upgraded root domain. IAM roles cannot sign in to the SageMaker Unified Studio UI. It is helpful to have a root domain owner who can sign in to the UI to modify authorization policies for the root domain.

After selecting the appropriate roles—and, if applicable, a root owner—choose Upgrade domain to launch the upgrade.

  1. When the upgrade finishes, a confirmation banner appears at the top of the domain detail page with two items:
    1. The Amazon DataZone portal URL
    2. The Manage Amazon DataZone upgrade button. Here you can see the Amazon DataZone URL, information about the upgrade, and an option to roll back the upgrade to Amazon DataZone.

  1. Scroll to the Users section of the SageMaker Unified Studio console. All identities that belonged to your original Amazon DataZone domain—along with the root domain owner you assigned in Step 3—now appear in the new domain automatically. No additional setup is required.

  1. Use the URL provided in Step 4 to open SageMaker Unified Studio, then sign in with your existing credentials. You’ll land on the SageMaker Unified Studio home page, confirming that you’re now working in your upgraded domain.

  1. In the Projects list, choose a project that existed in your original Amazon DataZone domain and that the current user can access. Select its name to open it and confirm that every asset and permission transferred correctly to SageMaker Unified Studio.

  1. Inside the project, you can view two key areas:
    • Project Environments – Verify that every environment linked to the project has been migrated.
    • Overview – Confirm the project’s general information, including owner, description, and status.

Checking both sections helps ensure that the project moved to SageMaker Unified Studio as expected.

Conclusion

In this post, we discussed the new capability in Amazon DataZone that allows a domain to be upgraded to the next generation of Amazon SageMaker. The investment customers put into developing Amazon DataZone is now transferable to SageMaker. All content created and curated through Amazon DataZone such as assets, metadata forms, glossaries, subscriptions, and so on are available to users through SageMaker Unified Studio after the upgrade. By upgrading to SageMaker, customers build on their investment from Amazon DataZone by using the SageMaker unified platform.

To learn more, visit the domain upgrade documentation.

About the authors

David Victoria is a Senior Technical Product Manager with Amazon SageMaker at AWS. He focuses on improving administration and governance capabilities needed for customers to support their analytics systems. He is passionate about helping customers realize the most value from their data in a secure, governed manner.

Leonardo David Gomez Virahonda is a Principal Analytics Specialist Solutions Architect at AWS, with a strong focus on data governance. He helps organizations across industries implement effective governance strategies using AWS services like Amazon DataZone, AWS Glue, Lake Formation, and SageMaker Catalog. Leonardo’s work spans metadata management, data lineage, access control, and compliance—empowering customers to make their data secure, discoverable, and ready for analytics and AI. He regularly shares best practices through technical blogs, enablement content, and sessions at AWS events like re:Invent and regional Summits.

Introducing universal installers for AWS CLI v2 on macOS

Post Syndicated from Andrew Asseily original https://aws.amazon.com/blogs/devops/introducing-universal-installers-for-aws-cli-v2-on-macos/

Amazon Web Services (AWS) is announcing the availability of universal macOS installers for the AWS Command Line Interface (AWS CLI) v2.

What’s new

Starting with AWS CLI v2 version 2.30.0, the AWS CLI installers will provide universal binary support for macOS that works natively on both Apple silicon and Intel processors with a single download. This eliminates the need for Rosetta translation, a compatibility layer that enables Intel-based applications to run on Apple silicon Macs.

Updating existing AWS CLI installations

If you’re using AWS CLI v2 on an Apple-silicon Mac, we recommend you upgrade to the latest version to install native binaries.

These changes only affect the official AWS CLI installers—building the AWS CLI from source will continue to natively support the host architecture.

Have questions or feedback? Contact us on GitHub.

Andrew Asseily

Andrew is a Software Development Engineer on the AWS CLI team. Outside of work, he’s an avid Brazilian Jiu-Jitsu practitioner.

Accelerate serverless testing with LocalStack integration in VS Code IDE

Post Syndicated from Micah Walter original https://aws.amazon.com/blogs/aws/accelerate-serverless-testing-with-localstack-integration-in-vs-code-ide/

Today, we’re announcing LocalStack integration in the AWS Toolkit for Visual Studio Code that makes it easier than ever for developers to test and debug serverless applications locally. This enhancement builds upon our recent improvements to the AWS Lambda development experience, including the console to IDE integration and remote debugging capabilities we launched in July 2025, continuing our commitment to simplify serverless development on Amazon Web Services (AWS).

When building serverless applications, developers typically focus on three key areas to streamline their testing experience: unit testing, integration testing, and debugging resources running in the cloud. Although AWS Serverless Application Model Command Line Interface (AWS SAM CLI) provides excellent local unit testing capabilities for individual Lambda functions, developers working with event-driven architectures that involve multiple AWS services, such as Amazon Simple Queue Service (Amazon SQS), Amazon EventBridge, and Amazon DynamoDB, need a comprehensive solution for local integration testing. Although LocalStack provided local emulation of AWS services, developers had to previously manage it as a standalone tool, requiring complex configuration and frequent context switching between multiple interfaces, which slowed down the development cycle.

LocalStack integration in AWS Toolkit for VS Code
To address these challenges, we’re introducing LocalStack integration so developers can connect AWS Toolkit for VS Code directly to LocalStack endpoints. With this integration, developers can test and debug serverless applications without switching between tools or managing complex LocalStack setups. Developers can now emulate end-to-end event-driven workflows involving services such as Lambda, Amazon SQS, and EventBridge locally, without needing to manage multiple tools, perform complex endpoint configurations, or deal with service boundary issues that previously required connecting to cloud resources.

The key benefit of this integration is that AWS Toolkit for VS Code can now connect to custom endpoints such as LocalStack, something that wasn’t possible before. Previously, to point AWS Toolkit for VS Code to their LocalStack environment, developers had to perform manual configuration and context switching between tools.

Getting started with LocalStack in VS Code is straightforward. Developers can begin with the LocalStack Free version, which provides local emulation for core AWS services ideal for early-stage development and testing. Using the guided application walkthrough in VS Code, developers can install LocalStack directly from the toolkit interface, which automatically installs the LocalStack extension and guides them through the setup process. When it’s configured, developers can deploy serverless applications directly to the emulated environment and test their functions locally, all without leaving their IDE.

Let’s try it out
First, I’ll update my copy of the AWS Toolkit for VS Code to the latest version. Once, I’ve done this, I can see a new option when I go to Application Builder and click on Walkthrough of Application Builder. This allows me to install LocalStack with a single click.

Once I’ve completed the setup for LocalStack, I can start it up from the status bar and then I’ll be able to select LocalStack from the list of my configured AWS profiles. In this illustration, I am using Application Composer to build a simple serverless architecture using Amazon API Gateway, Lambda, and DynamoDB. Normally, I’d deploy this to AWS using AWS SAM. In this case, I’m going to use the same AWS SAM command to deploy my stack locally.

I just do `sam deploy –guided –profile localstack` from the command line and follow the usual prompts. Deploying to LocalStack using AWS SAM CLI provides the exact same experience I’m used to when deploying to AWS. In the screenshot below, I can see the standard output from AWS SAM, as well as my new LocalStack resources listed in the AWS Toolkit Explorer.

I can even go in to a Lambda function and edit the function code I’ve deployed locally!

Over on the LocalStack website, I can login and take a look at all the resources I have running locally. In the screenshot below, you can see the local DynamoDB table I just deployed.

Enhanced development workflow
These new capabilities complement our recently launched console-to-IDE integration and remote debugging features, creating a comprehensive development experience that addresses different testing needs throughout the development lifecycle. AWS SAM CLI provides excellent local testing for individual Lambda functions, handling unit testing scenarios effectively. For integration testing, the LocalStack integration enables testing of multiservice workflows locally without the complexity of AWS Identity and Access Management (IAM) permissions, Amazon Virtual Private Cloud (Amazon VPC) configurations, or service boundary issues that can slow down development velocity.

When developers need to test using AWS services in development environments, they can use our remote debugging capabilities, which provide full access to Amazon VPC resources and IAM roles. This tiered approach frees up developers to focus on business logic during early development phases using LocalStack, then seamlessly transition to cloud-based testing when they need to validate against AWS service behaviors and configurations. The integration eliminates the need to switch between multiple tools and environments, so developers can identify and fix issues faster while maintaining the flexibility to choose the right testing approach for their specific needs.

Now available
You can start using these new features through the AWS Toolkit for VS Code by updating to v3.74.0. The LocalStack integration is available in all commercial AWS Regions except AWS GovCloud (US) Regions. To learn more, visit the AWS Toolkit for VS Code and Lambda documentation.

For developers who need broader service coverage or advanced capabilities, LocalStack offers additional tiers with expanded features. There are no additional costs from AWS for using this integration.

These enhancements represent another significant step forward in our ongoing commitment to simplifying the serverless development experience. Over the past year, we’ve focused on making VS Code the tool of choice for serverless developers, and this LocalStack integration continues that journey by providing tools for developers to build and test serverless applications more efficiently than ever before.

Archiving: The Steady Driver of Media & Entertainment Storage

Post Syndicated from Laquie TN Campbell original https://www.backblaze.com/blog/archiving-the-steady-driver-of-media-entertainment-storage/

A decorative image showing media icons on a gradient background.

Industry research consistently shows that archiving and preservation remain the largest drivers of storage demand in media and entertainment workflows. As of 2024, archiving—including both new and historical assets—accounts for the majority of digital storage capacity. 

This reflects an ongoing reality: Every production adds new terabytes of content, and studios/vendors are responsible for keeping it safe and usable long-term. And, for many M&E teams, traditional LTO tape libraries represent a cumbersome way to manage vast (and growing) archives. 

Increasingly, the decision is less whether to adopt cloud, and more how to use it responsibly. For some, that means hybrid systems that balance performance and scalability. For others, particularly smaller studios, cloud may become the backbone of both active and deep archives.

Free ebook: Why Media Workflows Are Embracing Cloud Storage—On Their Own Terms

Cloud media workflows are quick to promise a solution, but it’s more important for you to learn how to navigate. Read our ebook on how to use the cloud to best serve you and your team.

Your Media, Your Way

Why archiving dominates conversations—and what makes it so complex

Long-term preservation isn’t a “set-and-forget” task—technology evolves, file formats age, and migration becomes as essential as storage itself. Meanwhile, the shift to 4K, 8K, HDR, and immersive content means productions routinely generate petabytes of material. 

The challenge isn’t just volume, but ensuring ongoing integrity, accessibility, and migration compatibility over decades. That makes both current trends in file creation and future-proofing archives an active task. 

While the challenge can look different to different types of M&E teams, there are benefits for all of them:  

  • For editors and post-production teams, active archives keep high-resolution footage readily available, eliminating the frustration of digging through cold storage when a quick edit or repurposing request comes in.
  • For media asset managers, they transform archives into searchable, metadata-rich repositories that reduce retrieval time and prevent costly duplication of content.
  • For executives and producers, active archives protect past investments by making legacy assets easily accessible for remonetization in new markets, remasters, and marketing campaigns.
  • For IT and workflow engineers, they provide automated tiering and integration across on-prem and cloud systems, ensuring scalable performance without ballooning infrastructure costs.

Still, a recent NAB survey showed that archive capacity remains a challenge for 85% of respondents. Searchability is another weak spot, with some teams still relying on spreadsheets.

Why cloud adoption has been cautious

Although cloud storage offers flexibility, adoption in the M&E industry has been measured. Common concerns include:

  • High egress costs: Many providers charge significant fees for retrieving archived data. For media workflows that often involve moving large files in and out of storage, these costs can add up quickly.
  • Performance concerns: Latency and bandwidth limitations can disrupt workflows, especially in post-production environments that rely on fast access to high-resolution files.
  • Unpredictable workflows: Unlike enterprise archives where files may be rarely accessed, media archives are often “active.” Teams may suddenly need terabytes of content for a remastering project or marketing campaign. Cloud pricing models built around cold storage don’t always align well with this reality.
  • Trust and security: Especially in the early years of cloud, concerns around data sovereignty, intellectual property protection, and compliance slowed adoption. While cloud providers have strengthened their credentials in these areas, trust remains a consideration.
  • Established investments in on-prem: Many organizations already have significant capital invested in tape libraries, network attached storage (NAS), storage area network (SAN) systems, or colocation setups, making the shift to cloud a long-term transition rather than an overnight change.

How the cloud can help

The shift from “traditional” production to newer technologies in content filming and creation—including both hardware and software tools—leaves many M&E teams with several, competing demands for their tech stacks. Cloud workflows can offer significant benefits for scalability, searchability, and budget management.

Elastic capacity

Cloud removes the need for large upfront capital investments and scales as archives grow. For organizations with fluctuating storage needs, this flexibility is particularly valuable.

Cost-tiering options

Cloud services now offer multiple archival tiers—from “hot” to “deep archive”—allowing teams to balance cost with access needs. Combined with lifecycle management policies, this helps align budgets with actual usage.

Hybrid approaches

The most common strategy today is hybrid: keeping frequently accessed assets on-premises or in private cloud, while offloading less active content to public cloud. Surveys show hybrid adoption has grown significantly in the last five years, with expectations that it will continue to rise.

Collaboration and accessibility

For global teams, cloud improves accessibility. Editors, producers, and marketing teams in different regions can access the same archival assets without relying on physical transfers, VPNs, or duplicated storage.

AI-enabled metadata

Cloud platforms also support AI and ML services that enrich metadata. This transforms archives from passive repositories into searchable, discoverable libraries—unlocking new value from existing content.

The future of media archiving is in the cloud

The move to cloud is gradual, shaped by cost, performance, and workflow realities. Yet the volume and importance of archives—and cloud-based workflows—continue to grow. When paired with thoughtful strategies, cloud storage offers a flexible way to manage that growth while unlocking new creative value.

By designing storage approaches that balance innovation with practicality, M&E teams can ensure archives remain accessible, secure, and ready to support the next generation of storytelling.

The post Archiving: The Steady Driver of Media & Entertainment Storage appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

[$] A policy for Link tags

Post Syndicated from corbet original https://lwn.net/Articles/1037069/

The Git source-code management system stores a lot of information about
changes to code — but it does not hold everything that might be of interest
to a developer who needs to investigate a specific change in the future.
Commits in a repository are the end result of a (sometimes extended)
discussion; often, that discussion will result in changes to the code that
are not explained in the changelog. For some years now, many maintainers
have followed the convention of applying a Link tag to commits that points
back to the mailing-list posting of the change. Linus Torvalds has been
expressing his dislike for this convention for a while, though, and its
time appears to be coming to an end.

Security updates for Thursday

Post Syndicated from jake original https://lwn.net/Articles/1037777/

Security updates have been issued by AlmaLinux (python3.12-cryptography), Debian (chromium, hsqldb1.8.0, and imagemagick), Fedora (bustle, cef, maturin, rust-busd, rust-crypto-auditing-agent, rust-crypto-auditing-client, rust-crypto-auditing-event-broker, rust-monitord, rust-monitord-exporter, rustup, tuigreet, and wireshark), Oracle (kernel, microcode_ctl, and python3.12-cryptography), Red Hat (httpd:2.4 and multiple packages), SUSE (coreutils, curl, dpkg, ffmpeg-4, glib2, gnutls, go1.23-openssl, go1.24-openssl, go1.25-openssl, grub2, ImageMagick, jbigkit, kernel, libxslt, Mesa, opensc, opera, perl-JSON-XS, polkit, postgresql16, protobuf, python311, python311-deepdiff, sqlite3, ucode-intel, and warewulf4), and Ubuntu (bind9 and libxml2).

How FOSS Projects Handle Legal Takedown Requests (F-Droid)

Post Syndicated from corbet original https://lwn.net/Articles/1037703/

The F-Droid project has some
advice for free-software projects on how to deal with takedown
requests.

As part of our legal resilience research, we spoke with a range of
legal experts, software freedom advocates, and maintainers of
mature FOSS infrastructure to understand how others manage these
moments. In this article, we share what we learned, and how F-Droid
is incorporating these lessons into its own approach.

Promoting young people’s agency in the age of AI

Post Syndicated from Claire Johnson original https://www.raspberrypi.org/blog/promoting-young-peoples-agency-in-the-age-of-ai/

Part of teaching young people AI literacy skills is teaching them to critically think about AI, and to design AI applications that address problems they care about. How to do this was the focus of our June research seminar.

An educator helping a learner in the classroom

Working together to design AI

Our June research seminar was delivered by Netta Iivari, Professor in Information Systems at the University of Oulu’s INTERACT Research Unit.

The INTERACT research group focuses on understanding and supporting participatory design, user-centered design, user-driven innovation, and human interaction with technology in everyday life contexts. From this perspective, “users” aren’t considered as passive consumers, but as valuable co-creators and content producers. This calls for different approaches that place emphasis on empowerment and inclusion in designing, shaping, and co-creating information technology in everyday life.

As part of this work, Netta introduced the idea of ‘transformative agency’ — empowering children to believe they can solve problems they care about — and its application in secondary computing education. She showed examples of how to foster young people’s transformative agency within computing, specifically focusing on transdisciplinary approaches to learning about AI and inviting young people to critically analyse and design their futures with AI tools in it.

Netta began by giving an overview of two of the INTERACT Research Unit’s projects: 

  1. The Make a difference (MAD) project (2019–2023) explored critical design with young people, focusing on their emerging designer and maker identities in the context of tackling a significant societal problem — in this case, bullying. 
  2. Children’s transformative agency and emerging technologies for social good (TAKEOVER) (2024–2028), a current project, explores the potential of emerging technologies (artificial intelligence, virtual reality (VR), social robots, etc.) to address societal problems, such as climate change, gender equality, bullying, and discrimination. It focuses on children’s emerging transformative agency and activist identities when engaging with these tools and topics. 
An educator points to an image on a secondary learners computer screen.

Netta explained that these projects give young people an opportunity to begin to address the problems they care about, even though they may be very complex problems. From this problem-solving perspective, children are introduced (or ‘sensitised’) to emerging technologies as tools for social good.

She then went on to outline the key pedagogical approaches that underpin these projects:  

  1. Critical, ethical, empowering design
    This pedagogy draws on critical and speculative design traditions in design research and encourages young people to take a critical perspective towards society, its norms, and the status quo, as part of design thinking. Children consider the ethical values and consequences of their designs. They begin to experience the ways in which engaging in the design process can be empowering and transformative for them, collectively as well as individually. 
  2. Transformative agency of children
    This approach encourages young people to consider their capacity to have agency in the world, by enabling them to envision change and commit to taking action to solve problems that they care about. 
  3. Fostering transformative agency of children in the age of AI
    Transformative agency is achieved when young people engage in ‘expansive learning’ — when they learn something novel, together, and are encouraged to look beyond the confines of school work, the topic, themselves, and the tools available for solving the problem. This approach fosters an active, critical, reflective mindset that encourages children to believe that they can make change and have impact in the world. 

The project design process

The projects follow 3 design phases and include a range of plugged and unplugged activities, as shown in Figure 1.

Figure 1. The project phases

Netta then described in more detail some of the activities that have been used to address these different project phases and the design process involved. For example, to explore what are the problems that children really care about, they are asked to imagine ‘carrying a stone in your pocket for one week, as if it was a magic tool. Where could it be used in your everyday life? What problems could it solve? What problems would you like it to solve and how?’ 

Young people are then introduced to a range of novel technologies, for example, VR headsets, robots, and emulators of AI-driven social media platforms, such as “Somekone”, developed as part of the Generative AI project at the University of Eastern Finland. They deconstruct and reconstruct generative AI tools by prompting large language model chatbots such as ChatGPT, Gemini, Claude, etc. and exploring bias in their outputs. They perform small-scale algorithmic auditing and create mini language models (with Google Colab), using the text in Alice in Wonderland to train their models, and then open datasets (books as text files from Project Gutenberg). In exploring the responses generated, they experience the potential and the limitations of such tools and gain an important understanding of the human activity involved in the development of AI technologies. 

Secondary school age learners in a computing classroom.

Once they have had this ‘sensitising‘ exposure to a range of tools, they then work in groups on a project that makes use of AI to solve the societal problem they have chosen. These problems could encompass a range of topics, such as racism, animal rights, the impact of AI, war, mental health, bullying. The young people are prompted to think about how large language models can be used to solve the problem, or parts of the problem. But importantly, they are also asked to consider the different motives and perspectives of the multiple stakeholders involved in the problem and its solution and whether their model ideas will create new problems when deployed.

They follow the 3 project phases shown in Figure 1 to design and make a range of digital (robots, apps, videos) and non-digital artefacts to solve their problem. Netta emphasised that although it could take 10 weeks or more to implement all the suggested activities, it is also possible to pick and choose individual tasks from the 3 phases to suit available curriculum timescales.

Envisioning and critiquing AI futures

Other project tasks involve: 

  • Envisioning AI futures by imagining that a miracle has happened overnight and the problem has disappeared — what is the result? 
  • Critiquing AI futures by creating best and worst case scenarios of the consequences of the AI systems they design, creating video adverts promoting their AI solutions and anti-adverts, focusing on the possible negative consequences of their prototypes 
  • Fostering action-taking by presenting theatrical performances to showcase how their designs tackle a problem and illustrating the AI-related issues surrounding the topic or by creating activism campaign material to mobilise the school community on the same themes 
Secondary education learners in the classroom

These projects situate learning about data-driven technologies in real-world contexts and promote a transdisciplinary approach, teaching and learning about AI from a problem-solving perspective. 

This perspective conveys important messages to young people — that they do have agency and can take action in the face of many of the world’s problems, that they can and should be active, critical users of the new technologies that surround them, and that these technologies can be used to change the world for good. 

Netta ended the seminar by asking viewers to consider how they could foster transformative agency in the young people they teach and whether or not they consider it to be important in computing education.

Resources relating to the projects can be found at interact.oulu.fi.

Join our next seminar

In our current seminar series, we’re exploring teaching about AI and data science. Join us at our next seminar on Tuesday 14 October from 17:00 to 18:30 GMT to hear Viktoriya Olari talk about data-related concepts and practices for AI education in K–12.

To sign up and take part, click the button below. We’ll then send you information about joining. We hope to see you there.

I want to join the next seminar

The schedule of our upcoming seminars is online. You can catch up on past seminars on our previous seminars page.

The post Promoting young people’s agency in the age of AI appeared first on Raspberry Pi Foundation.

Revolutionizing Zabbix Maintenance with Artificial Intelligence

Post Syndicated from Grover Taipe original https://blog.zabbix.com/revolutionizing-zabbix-maintenance-with-artificial-intelligence/31284/

Can you imagine being able to schedule maintenance in Zabbix by simply telling a program: “I need to put the web server in maintenance tomorrow from 8 to 10 with ticket 100-178306”? That’s exactly what the Artificial Intelligence (AI) Scheduler Zabbix project I’ve developed does!

What problem does it solve?

Anyone who has worked with Zabbix knows that scheduling maintenance can sometimes be tedious, especially when you need to:

  • Configure complex routine maintenance
  • Handle Zabbix API bitmasks for specific days of the week or month
  • Search for specific hosts or groups
  • Document associated tickets

This project eliminates that friction by allowing the use of natural language to create both one-time and routine maintenance.

The magic behind the code

Conversational artificial intelligence

The system integrates both OpenAI GPT-4 and Google Gemini to interpret natural language requests. The AI doesn’t just understand what you want to do, but automatically:

  • Detects servers, groups, and dates
  • Identifies ticket numbers (XXX-XXXXXX format)
  • Automatically calculates complex Zabbix bitmasks
  • Generates contextual responses with examples
Fig. 1. Adding the AI Scheduler widget to your Zabbix dashboard

Advanced routine maintenance

What really stands out is its ability to handle complex patterns. Here are some practical examples that work:

  • “Daily backup for srv-backup from 2 to 4 AM with ticket 200-8341 until February 2027”
  • “Thursday and Friday maintenance from 5 to 7 AM until January 2027”
  • “Cleanup on the first Sunday of each month with ticket 100-178306 until December 2026”
Fig. 2. AI-generated maintenance summary with all calculated parameters

Elegant architecture

The project uses a three-layer architecture:

  • Frontend: Custom widget for Zabbix
  • Backend: Flask API with AI integration
  • Zabbix: Native API to create maintenance
Fig. 3. Maintenance successfully created and visible in Zabbix interface

Super-simple installation

One of the best features is how easy it is to get it running:

cp .env.example .env

You only need to configure your Zabbix URL and AI API key:

 docker compose up -d --build

And that’s it! You have an AI assistant working.

Multi-instance support

For organizations with multiple Zabbix servers, the project includes configuration for up to 5 simultaneous instances, each with its own configuration.

What impresses me most

Intelligent date detection

The system understands natural expressions like:

  • “Tomorrow from 8 to 10” → Next date with specific schedule
  • “Sunday from 2 to 4 AM” → Next Sunday at those hours
  • “24/08/25 10:00am” → Automatically converts the format

Automatic Bitmask management

Zabbix API bitmasks can be notoriously complicated. This system calculates them automatically:

  • Thursday and Friday = 8 + 16 = 24
  • Sundays only = 64
  • First week of the month with specific configuration
Fig. 4. Complex weekly maintenance scheduling with automatic bitmask calculation

Why is it important?

This project represents a natural evolution in systems administration. Instead of memorizing complex syntax or navigating multiple menus, you simply describe what you need in natural language. It’s especially valuable for:

  • Operations teams handling multiple maintenance tasks
  • Companies that need to document associated tickets
  • Organizations with complex maintenance patterns

The future is here

Projects like this demonstrate how artificial intelligence can make complex technical tools more accessible without sacrificing functionality. It’s not just automation – it’s intelligence applied to real infrastructure problems. If you work with Zabbix and are tired of manually configuring maintenance, this project is definitely worth checking out. It’s open source, well documented, and solves a real problem that many of us face every day. You can find the complete project on GitHub.

The post Revolutionizing Zabbix Maintenance with Artificial Intelligence appeared first on Zabbix Blog.

The collective thoughts of the interwebz