Post Syndicated from LGR original https://www.youtube.com/watch?v=hKif5gEV6kc
Introducing Oracle Database@AWS for simplified Oracle Exadata migrations to the AWS Cloud
Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/introducing-oracle-databaseaws-for-simplified-oracle-exadata-migrations-to-the-aws-cloud/
Today, we’re announcing the general availability of Oracle Database@AWS, a new offering for Oracle Exadata workloads, including Oracle Real Application Clusters (RAC) within AWS.
In the past 14 years, customers had the choice of self-managing Oracle database workloads in the cloud using Amazon Elastic Compute Cloud (Amazon EC2) or using fully managed Amazon Relational Database Service (Amazon RDS) for Oracle. Now, you have an additional option for your workloads that require Oracle RAC or Oracle Exadata for quicker and simpler migrations to the cloud. You also get a single invoice through AWS Marketplace, which counts towards AWS commitments and Oracle license benefits, including Bring Your Own License (BYOL) and discount programs such as Oracle Support Rewards.
With Oracle Database@AWS, you can migrate your Oracle Exadata workloads to Oracle Exadata Database Service on Dedicated Infrastructure or Oracle Autonomous Database on Dedicated Exadata Infrastructure within AWS with minimal changes. You can purchase, provision, and manage your Oracle Database@AWS deployments through familiar AWS tools and interfaces such as AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS APIs for applications running on AWS. The AWS APIs call the corresponding Oracle Cloud Infrastructure (OCI) APIs necessary to provision and manage the resources.
Since its preview last December, we’ve improved or added features to help run production workloads at general availability:
- Regional expansion – You can now use Oracle Database@AWS in the U.S. East (N. Virginia) and U.S. West (Oregon) Regions today. We are also announcing plans to expand to 20 AWS Regions globally. This broader availability supports the diverse needs of our customers across various geographical areas so more enterprises can benefit from this option. You can choose from different Exadata system sizes to match your workload requirements in your AWS Region.
- Zero-ETL and S3 backups – You can now benefit from zero-ETL integration with Amazon Redshift for analytics to remove the need to build and manage data pipelines for extract, transform, and load operations. With zero-ETL, you can unify your data on AWS without incurring cross network data transfer costs. We’re providing Amazon Simple Storage Service (Amazon S3) backups with up to eleven nines of data durability.
- Autonomous VM cluster – You can now provision an Autonomous VM Cluster in addition to an Exadata VM cluster on the Exadata Dedicated Infrastructure. You can run Oracle Autonomous Database on Dedicated Exadata Infrastructure, a fully managed database environment using committed hardware and software resources.
Oracle Database@AWS also integrates with other AWS services such as Amazon Virtual Private Cloud (Amazon VPC) Lattice for configuring network paths to AWS services such as S3 and Redshift directly, AWS Identity and Access Management (IAM) for authentication and authorization, Amazon EventBridge for monitoring database lifecycle events, AWS CloudFormation for infrastructure automation, Amazon CloudWatch for collecting and monitoring metrics, and AWS CloudTrail for logging API operations.
Getting started with Oracle Database@AWS
Oracle Database@AWS supports two key services: Oracle Exadata Database Service on Dedicated Infrastructure and Oracle Autonomous Database on Dedicated Exadata Infrastructure within AWS data centers.
These services physically reside within an Availability Zone in an AWS Region and logically reside in an OCI region, enabling seamless integration with AWS services through high-speed, low-latency connections.

You create an ODB network, a private, isolated network that hosts Oracle Exadata VM Clusters within an Availability Zone. Then, you use ODB peering accessible to EC2 application servers running in a VPC. To learn more, visit How Oracle Database@AWS works in the AWS documentation.
Request a private offer in AWS Marketplace
To begin your journey with Oracle Database@AWS, visit the AWS console or request the AWS Marketplace private offer. Your AWS and Oracle sales team will receive your request, then contact you to find the best option for your workloads, and activate your account.

When you activate and get access to Oracle Database@AWS, you can use the Dashboard to create an ODB network, Exadata infrastructure, and Exadata VM cluster or Autonomous VM cluster, and ODB peering connection.

To learn more, visit the Onboarding to Oracle Database@AWS and AWS Marketplace buyer private offers in the AWS documentation.
Create an ODB network
An ODB network is a private isolated network that hosts OCI infrastructure on AWS. The ODB network maps directly to the network that exists within the OCI child site, thus serving as the means of communication between AWS and OCI.
In the Dashboard, choose Create ODB network, enter a network name, choose the Availability Zone, and specify a CIDR ranges for client connections established by applications and backup connections used for taking automated backups. You can also enter a name to use as a prefix to your domain fixed as oraclevcn.com. For example, if you enter myhost, the fully qualified domain name is myhost.oraclevcn.com.

Optionally, you can configure ODB network access to perform automated backups to Amazon S3 and zero-ETL for near real-time analytics and ML on your Oracle data using Amazon Redshift.

After you create your ODB network, update your VPC route tables of your EC2 application servers with the client connection CIDR in the ODB network. To learn more, visit ODB network, ODB peering, and Configuring VPC route tables for ODB peering in the AWS documentation.
Create Exadata infrastructure
The Oracle Exadata infrastructure is the underlying architecture of your database servers, storage servers, and networking that run your Oracle Exadata databases.
Choose Create Exadata infrastructure, enter a name, and use the default Availability Zone. In the next step, you can choose Exadata.X11M for the Exadata system model. You can also set a default of 2 or up to 32 database servers and 3 or up to 64 storage servers with 80 TB storage capacity per server.

Finally, you can configure system maintenance preferences, such as scheduling, patching mode, and OCI maintenance notification contacts. You can’t modify an infrastructure after you create it from the AWS console. But, you can navigate to the OCI console and modify it.
To delete an Exadata infrastructure, visit Deleting an Oracle Exadata infrastructure in Oracle Database@AWS in the AWS documentation.
Create an Exadata VM cluster or Autonomous VM cluster
You can create VM clusters on Exadata infrastructure and deploy multiple VM clusters with different Oracle Exadata infrastructures in the same ODB network.
Here are two types of VM clusters:
- An Exadata VM cluster is a set of virtual machines that has a complete Oracle database installation that includes all features of Oracle Enterprise Edition.
- An Autonomous VM cluster is a set of fully managed databases that automate key management tasks using AI/ML with no human intervention required.
Choose Create Exadata VM cluster, enter a VM cluster name and a time zone, choose Bring Your Own License (BYOL) or license included for license options. In the next step, you can choose your Exadata infrastructure, grid infrastructure version, and Exadata image version. For database servers, you can choose the CPU core count, memory, and local storage for each VM or accept the defaults.

In the next step, you can configure the connectivity setting by choosing your ODB network and entering a prefix for the VM cluster. You can enter a port number for TCP access to the single client access name (SCAN) listener. The default port is 1521 or you can enter a custom SCAN port in the range 1024–8999. For SSH key pairs, enter the public key portion of one or more key pairs used for SSH access to the VM cluster.

Then, you can choose diagnostics and tags, review your settings, and create a VM cluster. The creation process can take up to 6 hours, depending on the size of the VM cluster.
Create and manage an Oracle database
When the VM cluster is ready, you can create and manage your Oracle Exadata databases in the OCI console. Choose Manage in OCI in the details page of the Exadata VM cluster. You will be redirected to the OCI console.

When you create an Oracle Database in the OCI console, you can select Oracle Database 19c or 23ai. When enabling automatic backups for your provisioned databases, you can use an S3 bucket or OCI Object Storage in the OCI region. To learn more, visit Provision Oracle Exadata Database Service in Oracle Database@AWS in the OCI documentation.
Things to know
Here are a couple of things to know about Oracle Database@AWS:
- Monitoring – You can monitor Oracle Database@AWS using Amazon CloudWatch metrics in the
AWS/ODBnamespaces for VM clusters, container databases, and pluggable databases. AWS CloudTrail captures all AWS API calls for Oracle Database@AWS as events. Using CloudTrail logs, you can determine the request that was made to Oracle Database@AWS, the IP address from which the request was made, when it was made, and additional details. To learn more, visit Monitoring Oracle Database@AWS. - Security – You can use IAM to assign permissions that determine who is allowed to manage Oracle Database@AWS resources and SSL/TLS encrypted connections to secure data. You can also use Amazon EventBridge for seamless event-driven database operations—all working together to maintain security standards while enabling efficient cloud operations. To learn more, visit Security in Oracle Database@AWS.
- Compliance – Your compliance responsibility when using Oracle Database@AWS is determined by the sensitivity of your data, your company’s compliance objectives, and applicable laws and regulations. We provides the following compliances with Oracle Database@AWS: SOC 1, SOC 2, SOC 3, HIPAA, C5, CSA STAR Attest, CSA STAR Cert, HDS (France), ISO Series (ISO/IEC 9001, 20000-1, 27001, 27017, 27018, 27701, 22301), PCI DSS, and HITRUST. To learn more, visit Compliance validation for Oracle Database@AWS.
- Support – Your AWS or Oracle sales account team can help you evaluate your current database infrastructure, determine how Oracle Database@AWS can best serve your organization’s requirements, and develop a tailored migration strategy and timeline. You can also get help from AWS Oracle Competency Partners specialized to architect, deploy, and manage Oracle-based workloads running in the AWS Cloud.
Now available and coming soon
Oracle Database@AWS is now available in the U.S. East (N. Virginia) and U.S. West (Oregon) Regions through the AWS Marketplace. Oracle Database@AWS pricing and any AWS Marketplace private offers are set by Oracle. You can see specific details around pricing on Oracle’s pricing page for the offering.
Oracle Database@AWS will expand to 20 more AWS Regions across the Americas, Europe, and Asia-Pacific including: US East (Ohio), US West (N. California), Asia Pacific (Hyderabad), Asia Pacific (Melbourne), Asia Pacific (Mumbai), Asia Pacific (Osaka), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Milan), Europe (Paris), Europe (Spain), Europe (Stockholm), Europe (Zurich), and South America (São Paulo).
You can get started with Oracle Database@AWS with using AWS console. To learn more, visit the Oracle Database@AWS User Guide and OCI documentation and send feedback through your usual AWS Support contacts or OCI support.
— Channy
How to Install Zabbix on Windows with a Linux Subsystem
Post Syndicated from Alexander Petrov-Gavrilov original https://blog.zabbix.com/how-to-install-zabbix-on-windows-with-a-linux-subsystem/30311/
It’s a very well known fact that Zabbix can only be installed on Linux. But what if you are in a Windows environment and getting a Linux machine is not so simple or even possible? This can obstruct the implementation of Zabbix, or at least significantly delay it. Not only that, building a POC outside of the future environment makes data procurement a lot more complicated. Is there a way to work around this and get Zabbix as close to Windows as we possibly can?
Table of Contents
WSL
WSL/WSL 2 is a fast and easy solution for installing and using Zabbix in a smaller Windows-dominant environment, be that a POC or a small company office. WSL 2 runs a real Linux kernel in a lightweight VM while being optimized for Windows. This means a faster start, lower resource consumption, and the ability to share files with Windows directly, meaning you can use Windows File explorer to find and manage the VM files.
WSL 2 also allows you to use Linux CLI while working with Windows (i.e. running vim from a Windows terminal and editing Windows files directly). At this point, you may be asking yourself, “Why not Hyper-V and VirtualBox?” Those are definitely options too, but they are quite heavy on system resources. In addition, boot times are a bit longer and sharing files between a host and a guest OS is clunkier.
Maybe Docker Desktop then? It’s an absolutely valid option, but that would require a bit of Docker knowledge and you would still be using WSL, technically speaking. So, with that said, WSL is definitely the fastest and most reliable way to sprung a Zabbix instance in a Windows-focused environment.
We will use WSL 2, but as a note WSL 1 is also available. Here are the differences:
- WSL 2 is usually the better performer overall, especially for dev environments. It also has better Linux compatibility.
- WSL 1 Linux files aren’t isolated, which can make them more accessible. In WSL 2, Linux runs in a virtual disk (ext4), so Linux and Windows files are more separate. Integration is still pretty good, however.
- WSL 2 has better Linux compatibility – systemd, iptables, etc.
- WSL 1 shared the same IP as Windows, WSL 2 is a VM – some networking required.
- With WSL 1 you can see Linux running processes in Task Manager. WSL 2 will have processes isolated.
Installing Zabbix using WSL
Install WSL
Open PowerShell as an Administrator and run:
PS C:\Windows\system32> wsl --install
If you’ve already have WSL 1 installed, update it:
PS C:\Windows\system32> wsl --update
You can also set WSL 2 as default:
PS C:\Windows\system32> wsl --set-default-version 2

Install/Get preferred Linux Distribution using either Microsoft Store (i.e. Ubuntu, Debian, Oracle Linux) or just download directly. I will be using Oracle Linux 9.4.

You can also download the RootFS tarball from the preferred distribution portal, but then the process will be a bit different. Create a folder using PowerShell:
PS C:\Windows\system32> mkdir C:\WSL\OracleLinux9
Copy the .tar.xz file to this folder, then run:
PS C:\Windows\system32> wsl --import OracleLinux9 C:\WSL\OracleLinux9 .\oraclelinux9-rootfs.tar.xz --version 2
After the image is installed or imported, start Oracle Linux using PowerShell:
PS C:\Windows\system32> oraclelinux94
When installation is finished, there is a prompt to create a default UNIX user account and password for the said user, as the username does not need to match your Windows username. I’ll set it to “zabbix” of course, but you can set it to any other.
PS C:\Windows\system32> Enter new UNIX username:
PS C:\Windows\system32> zabbix
PS C:\Windows\system32> New password: <your-password>
PS C:\Windows\system32> passwd: all authentication tokens updated successfully.
PS C:\Windows\system32> Installation successful!
Now OracleLinux is ready for use!
Prepare the system
You will be immediately logged in to the new environment. If logged out, to log in again just execute in PowerShel:
PS C:\Windows\system32> oraclelinux94
Being logged in, first double check that your selected OS is indeed installed by executing in the PowerShell, which will now serve as your VM CLI access point:
[zabbix@PC-NAME ~]$ cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="9.4"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="9.4"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Oracle Linux Server 9.4"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:9:4:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL=https://github.com/oracle/oracle-linux
Confirmation received, make sure all OS updates are installed:
[zabbix@PC-NAME ~]$ sudo dnf update -y
When the update process is finished, you will need to decide whether you would like to use systemd or not (this may increase booting time). I will enable systemd. To do this, edit the wsl.conf on the Linux subsystem:
vi /etc/wsl.conf
Add to the newly created file:
[boot]
systemd=true
Reboot the images (this command will reboot all of them):
PS C:\Windows\system32> wsl.exe --shutdown
Start back your Linux distribution:
PS C:\Windows\system32> oraclelinux94
Install Zabbix database
We will need to prepare the database engine. Again, any preferred database engine can be used, in this case I install and configure MariaDB:
[zabbix@PC-NAME ~]$ sudo dnf install -y mariadb-server mariadb
[zabbix@PC-NAME ~]$ sudo systemctl enable --now mariadb
Confirm MariaDB is running:
[zabbix@PC-NAME ~]$ Systemctl status mariadb
mariadb.service - MariaDB 10.5 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: disabled)
Active: active (running) since Tue 2025-04-29 12:39:54 EEST; 3min 55s ago
Docs: man:mariadbd(8)
https://mariadb.com/kb/en/library/systemd/
Main PID: 235 (mariadbd)
Status: "Taking your SQL requests now..."
Tasks: 9 (limit: 26213)
Memory: 109.6M
CGroup: /system.slice/mariadb.service
└─235 /usr/libexec/mariadbd --basedir=/usr
After confirmation, secure it a bit by creating a root password and selecting the options in bold:
[zabbix@PC-NAME ~]$ sudo mysql_secure_installation
Enter current password for root (enter for none):
OK, successfully used password, moving on...
Setting the root password or using the unix_socket ensures that nobody
can log into the MariaDB root user without the proper authorisation.
You already have your root account protected, so you can safely answer 'n'.
Switch to unix_socket authentication [Y/n] n
... skipping.
You already have your root account protected, so you can safely answer 'n'.
Change the root password? [Y/n] Y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!
Remove anonymous users? [Y/n] Y
... Success!
Disallow root login remotely? [Y/n] Y
... Success!
Remove test database and access to it? [Y/n] Y
Reload privilege tables now? [Y/n] Y
... Success!
Cleaning up...
All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!
Now to create the Zabbix database. Log in to MariaDB:
[zabbix@PC-NAME ~]$ sudo mysql -u root -p
[zabbix@PC-NAME ~]$ Enter password: <enter your password, won’t be visible>
Follow the steps from the Zabbix installation page:
MariaDB [(none)]> create database zabbix character set utf8mb4 collate utf8mb4_bin;
MariaDB [(none)]> create user zabbix@localhost identified by '<custom-password>';
MariaDB [(none)]> grant all privileges on zabbix.* to zabbix@localhost;
MariaDB [(none)]> set global log_bin_trust_function_creators = 1;
MariaDB [(none)]> quit;
Installing Zabbix
Install the Zabbix repository:
[zabbix@PC-NAME ~]$ sudo dnf install https://repo.zabbix.com/zabbix/7.0/centos/9/x86_64/zabbix-release-latest-7.0.el9.noarch.rpm
[zabbix@PC-NAME ~]$ dnf clean all
Proceed to install the Zabbix server, frontend, and agent:
[zabbix@PC-NAME ~]$ sudo dnf -y install zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf zabbix-sql-scripts zabbix-selinux-policy zabbix-agent
...
[zabbix@PC-NAME ~]$zabbix-agent-7.0.12-release1.el9.x86_64 zabbix-apache-conf-7.0.12-release1.el9.noarch zabbix-selinux-policy-7.0.12-release1.el9.x86_64 zabbix-server-mysql-7.0.12-release1.el9.x86_64 zabbix-sql-scripts-7.0.12-release1.el9.noarch
zabbix-web-7.0.12-release1.el9.noarch zabbix-web-deps-7.0.12-release1.el9.noarch zabbix-web-mysql-7.0.12-release1.el9.noarch
Complete!
Now import the initial database schema:
[zabbix@PC-NAME ~]$ zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -u zabbix -p zabbix
Enter password: <enter your DB user password and wait until you will see the next line appear>
[root@ZBX-5CD3221K14 zabbix]#
Disable the log_bin_trust_function_creators option after import has finished:
# mysql -uroot -p
password
MariaDB [(none)]> set global log_bin_trust_function_creators = 0;
MariaDB [(none)]> quit;
Add your Zabbix user database password to the Zabbix server configuration file:
[zabbix@PC-NAME ~]$ vi /etc/zabbix/zabbix_server.conf
### Option: DBPassword
# Database password.
# Comment this line if no password is used.
#
# Mandatory: no
# Default:
DBPassword=<your-DB-user-password>
Start the Zabbix server and frontend and add them to autorun:
[zabbix@PC-NAME ~]$ systemctl restart zabbix-server zabbix-agent httpd php-fpm
[zabbix@PC-NAME ~]$ systemctl enable zabbix-server zabbix-agent httpd php-fpm
Created symlink /etc/systemd/system/multi-user.target.wants/zabbix-server.service → /usr/lib/systemd/system/zabbix-server.service.
Created symlink /etc/systemd/system/multi-user.target.wants/zabbix-agent.service → /usr/lib/systemd/system/zabbix-agent.service.
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
Created symlink /etc/systemd/system/multi-user.target.wants/php-fpm.service → /usr/lib/systemd/system/php-fpm.service.
Installation of the backend is now finished, but we still need the frontend.
Exposing and installing the Zabbix frontend for WSL
Since WSL2 does not expose services to localhost by default, you need to determine the WSL IP:
[zabbix@PC-NAME ~]$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:15:5d:47:32:c6 brd ff:ff:ff:ff:ff:ff
inet 172.29.128.155/20 brd 172.29.143.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::215:5dff:fe47:32c6/64 scope link
valid_lft forever preferred_lft forever
Look for an IP like 172.x.x.x, then using your browser go to:
http://<WSL_IP>/zabbix
In this example, that would be:
http://172.29.128.155/zabbix
You can also port forward WSL to localhost with netsh in PowerShell:
PS C:\Windows\system32> netsh interface portproxy add v4tov4 listenport=8080 listenaddress=127.0.0.1 connectport=80 connectaddress=<WSL_IP>
Then you will be able to access Zabbix from http://localhost:8080/zabbix. Now, just finish the standard frontend setup and Zabbix is ready to use!
WSL advantages
Some extra advantages you get with this approach include clearer resource usage visibility:

Direct access to the Linux subsystem files through File explorer with your favorite Windows tools:

As you can see, docker is here as well. System and configuration files are also visible and editable:

Now you can proceed with building your Zabbix or Zabbix POC, (almost) without needing to leave your regular Windows environment!
The post How to Install Zabbix on Windows with a Linux Subsystem appeared first on Zabbix Blog.
Хоругвата на фундаментализма
Post Syndicated from original https://www.toest.bg/horugvata-na-fundamentalizma/

Центърът на София е известен с близостта, в която се намират един до друг православен храм, католическа църква, джамия и синагога. Тази симпатична топография се възприема като доказателство за религиозната толерантност на българина и все още често се изтъква като предимство на страната ни. Опитите за нарушаване на хармонията, например случаят, когато симпатизанти на партия „Атака“ нападнаха молещи се мюсюлмани, се посрещат с обществено порицание.
За човек, който живее в такава среда, понякога е трудно да го осъзнае, но междуверската търпимост наистина е достижение. Миналото на Европа, а и на света е показало, че някои от най-тежките и нерешими конфликти се пораждат от идеята, че една религия трябва да се наложи силом над останалите. Това, поне на пръв поглед, не е характерно за България. Макар да се гордеем с делото на покръстителя княз Борис и да изтъкваме, че сме дали православието на други народи, като руснаци и украинци, ние никога не сме били фанатични.
У нас винаги е имало алтернативни учения, например богомилството през средните векове и философията на Петър Дънов от по-ново време, а за някои хора те са неразделна част от българското. Освен това още преди покръстването българите са флиртували с Ватикана и макар в крайна сметка да избират друго, у нас има компактни общности католици, съществуващи до ден днешен. В страната се срещат също протестанти, апостолици (арменци), юдеи, в по-ново време мормони, будисти, привърженици на движението „Харе Кришна“. Няма как да не се отбележи и сравнително високият процент мюсюлмани, които съставляват втората по големина религия в страната. И макар миналото да пази някои травматични моменти, като цяло тези религиозни общности живеят в мир помежду си.
Напоследък обаче изглежда, че картината започва да се променя.
Българската православна църква (БПЦ) става все по-активна в обществения живот и се опитва да наложи ценностите си на всички. Тя може да си го позволи, защото, макар българите да не са от най-редовно черкуващите се народи, православието играе специална роля в историята ни. Мнозина смятат, че то е основен фактор за съхраняването ни като общност през вековете на османско владичество. Именно борбите за църковна независимост предшестват освободителните движения, а обобщението на всичко това е дадено от митрополит Климент (Васил Друмев):
Има православие – има и български народ; няма православие – няма и български народ.
Православната църква играе важна роля като знак за тиха съпротива срещу атеизма, силово налаган от комунистическата власт по време на тоталитарния период. В храмовете, които посещават, докато са следени от милицията, много българи откриват упование и обещание за справедливост във вечността, което е по-вдъхновяващо от сивите лозунги за светлото социалистическо бъдеще и преизпълнените петилетки. Вярата се превръща в алтернатива на грубия материализъм и затова в първите години на Прехода принадлежността към нея е почти част от демократичната идентичност.
За съжаление, тъкмо по време на тоталитаризма текат процеси, даващи негативно отражение днес.
Голяма част от висшия клир, а и не само, бива вербувана от комунистическата Държавна сигурност. Можем само да спекулираме дали някогашните агенти и доносници са станали вярващи, напасвайки християнските догми с дадените им от комунистическия кесар задачи, или пък са просто лицемерни. Факт е обаче, че някъде в този етап в Българската църква се заражда изключителна вярност към Русия, тогава част от Съветския съюз, където подобни агентурни процеси вече са протекли.
В днешната Руска федерация Православната църква изпълнява ролята на държавна доктрина, която оправдава и благославя завоевателните цели на режима на президента Владимир Путин. Тя окуражава подчинението пред властимащите. Това е показано във филма „Левиатан“ на Андрей Звягинцев, където свещеник със сковано лице и леден глас дава съвети на местен олигарх, че всяка власт на Земята е дадена от Бога и той не трябва да се бои да я изпълнява.
За Руската православна църква войната, която Путин води срещу Украйна, е свещена – концепция, която дори за средновековна Византия би била прекалена. Макар и благочестиво, както проповядва православието, Кремъл все пак има враждебно отношение към западните християни, особено към католиците, които се възприемат като част от вражеския колективен Запад. Поради това много руснаци, особено националистите, възприемаха с недоверие опитите на папа Франциск да посредничи за мир за войната в Украйна, докато в същото време украинци го упрекваха, че е твърде отстъпчив пред Москва. ЛГБТ хората са обявявани на практика за престъпници просто защото ги има. Напоследък на мушка попадат и тези, които нямат деца – смразяващ завой, който, за съжаление, може би намеква какво ни очаква и в България.
Причина за тревога
е изборът на сравнително младия и изключително деен Даниил за патриарх през миналата година. Като духовник той води аскетичен начин на живот, което е достойно за уважение. Нееднократно обаче е изразявал политически позиции, близки до тези на руската държава, и под негово ръководство Църквата започва все по-активно да се намесва и в светския живот. Неговото предстоятелство е не толкова начало, колкото кулминация на процес, започнал преди няколко години. Симптоматично беше поведението на БПЦ при посещението на папа Франциск в България, когато мюсюлмани, юдеи и протестанти се молиха заедно с главата на римокатолиците, но представителите на православното духовенство отказаха.
В наши дни видяхме Църквата да изразява отрицателно становище към традиция като нестинарството, което предизвика хумористични реакции в социалните мрежи. Привидно аргументът е железен спрямо канона – обичаят е езически. В действителност обаче между религията и дохристиянските вярвания в България, а и по цял свят често има симбиоза, включително датите, на които празнуваме Коледа и Великден, свързани пряко със зимното слънцестоене и пролетното равноденствие. Професор Клайв С. Луис, може би най-известният християнски апологет на ХХ век, дори стига дотам, че твърди как езическите митове за завърнали се от смъртта са подготвяли хората за истинското възкресение. Доколко тогава е удачно да се нападат хора, почитащи икони дори по време на чисто фолклорен ритуал?
Това отношение започва да се просмуква полека-лека и сред миряните. По проруска линия интелектуалци, свързани с вярата, заемат позиция срещу Вселенската патриаршия и в подкрепа на Руската православна църква, особено по въпроса коя е действителната църква в Украйна. Католиците, каквито у нас има хиляди, лековато са наричани еретици. Професор Калин Янакиев, чиито познания за историята на православието са изключителни, оборва това определение, но самият той признава, че е обект на нападки заради позициите си.
Невинен поздрав за еврейския празник Ханука на водеща медия у нас предизвика просташки коментари в социалните мрежи – нещо, което бе забелязано и от посланика на Израел. Част от тях бяха реакция на войната в Газа, но в други се долавяше нетолерантността към вярата, която не е „нашата“, „ние това не го празнуваме“. По време на последните местни избори в София в казус се превърна фактът, че кандидатът за кмет Васил Терзиев симпатизира на Петър Дънов. Дъновизмът действително противоречи на православната догма. Това обаче не би трябвало да е проблем за заемане на определен пост в светска държава. На всеки Хелоуин празнуващите с маски деца биват обвинявани в сатанизъм.
Тези неща изглеждат смешни и нелепи, но съвсем не са невинни.
Езикът на омразата може лесно да премине в действия, първоначално сравнително безобидни, като анекдотичните разкази за съборена украса на Хелоуин, но после опасни и агресивни, каквото би било физическото насилие срещу някой „друговерец“. Още повече че предстои въвеждането на религиозно обучение в училищата, което ще сегрегира децата и ще изолира католици, протестанти, евреи и атеисти. Тук не отварям дума за учениците с алтернативна сексуалност, каквато, така или иначе, е забранено да се обсъжда със закон, отново с одобрението на Църквата.
Като цяло трябва да се има предвид, че всяка религиозна общност споделя канони и вярвания и има право да следи за спазването им от своите последователи. От тази гледна точка е неправилно да очакваме Църквата да промени свои хилядолетни канони относно теми като брака и целомъдрието, нито да искаме публично да признае за приемливи учения, несъвместими със свещените ѝ книги.
В същото време България е светска страна, в която Църквата е отделена от държавата, и не е коректно да се създава обстановка на нетърпимост към хората извън паството на БПЦ.
Намирането на баланса не е лесна задача, тъй като религиозният фундаментализъм може да оправдае всяко зверство. Фанатично вярващите мислят, че спасяват неверниците. При положение че според вярата им душите им би следвало да са безсмъртни, а човешкият живот трае средно 70–80 години, тълкуванието е, че каквото и страдание да причинят в този живот, то бледнее пред риска душата на жертвата им да попадне в ада, където ще бъде подложена на вечни мъчения. Въпросът е, че поне в християнството, сред чиито деноминации е и православието, съществува концепцията за свободна воля, а тя се нарушава, когато възможните алтернативи биват потискани.
Разбира се, за ислямските фундаменталисти абсолютната свобода идва тогава, когато можеш да избереш Бога без никакви „пречки“. Само че това мислене е създало ужаса на самоубийствените атентати, както и режими като този на талибаните в Афганистан, където всяка радост от живота бива потисната в името на „благочестието“.
България все още е много далеч от такова състояние и в интерес на истината, православието е подкрепяно не толкова като единствен верен път към Бога, колкото като белег на националната идентичност. Това го прави елемент от национализма, който се разгаря у нас през последните вече 20 години (ако броим за началото му пробива на „Атака“ на парламентарните избори през 2005 г.). Въпреки че у нас и национализмът е свързан със силна привързаност към чужда държава, която пък ни е посочила официално за врагове.
Но първите стъпки към по-сериозно развихряне на някакъв религиозен фундаментализъм сякаш вече са направени. Важно е да си дадем сметка за това. Така поне няма да бъдем изненадани, ако един ден завалят директните предложения за забрана на цели вероизповедания (едно вече беше шкартирано) и ограничаването на права, които погрешно днес смятаме за даденост.
Българският народ все още има традиция във верската търпимост. Само времето ще покаже дали тя ще бъде продължена.
This is the New Double Wide NIC with 8x 25GbE Ports Using the Intel E830 NIC
Post Syndicated from Patrick Kennedy original https://www.servethehome.com/this-is-the-new-double-wide-nic-with-8x-25gbe-ports-using-the-intel-e830-nic/
At HPE Discover 2025 we found this 8-port 25GbE NIC using the new DSFF layout and based on the new Intel E830 200Gbps NIC silicon
The post This is the New Double Wide NIC with 8x 25GbE Ports Using the Intel E830 NIC appeared first on ServeTheHome.
Home Assistant 2025.8 Release Party
Post Syndicated from Home Assistant original https://www.youtube.com/watch?v=gNtNOtsTH1w
Comic for 2025.07.08 – Become Religious
Post Syndicated from Explosm.net original https://explosm.net/comics/become-religious
New Cyanide and Happiness Comic
The Best Thing…
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/shorts/40A1gnb5K_o
AWS Weekly Roundup: EC2 C8gn instances, Amazon Nova Canvas virtual try-on, and more (July 7, 2025)
Post Syndicated from Elizabeth Fuentes original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-amazon-bedrock-api-keys-amazon-nova-canvas-virtual-try-on-and-more-july-7-2025/
Every Monday we tell you about the best releases and blogs that caught our attention last week.
Before continuing with this AWS Weekly Roundup, I’d like to share that last month I moved with my family to San Francisco, California, to start a new role as Developer Advocate/SDE, GenAI.
This excites me because I’ll have the opportunity to connect with new communities in the Bay Area while tackling exciting new challenges. If you’re part of a community focused on building generative AI and agentics applications, or know of one, I’d love to connect. Let’s connect!
Last week’s launches
Here are the launches from last week:
- New Amazon EC2 C8gn instances powered by AWS Graviton4 offering up to 600Gbps network bandwidth – Amazon Elastic Compute Cloud (Amazon EC2) C8gn instances are now generally available, powered by AWS Graviton4 processors and 6th generation AWS Nitro Cards. These network-optimized instances deliver up to 600 Gbps network bandwidth. This represents the highest bandwidth among EC2 network-optimized instances, with up to 192 vCPUs and 384 GiB memory. They provide 30% higher compute performance than C7gn instances and are ideal for network-intensive workloads like virtual appliances, data analytics, and cluster computing jobs.
- Build the highest resilience apps with multi-Region strong consistency in Amazon DynamoDB global tables – Amazon DynamoDB global tables now supports multi-Region strong consistency (MRSC) for applications requiring zero Recovery Point Objective (RPO). This capability ensures applications can read the latest data from any Region during outages, addressing critical needs in payment processing and financial services. MRSC requires three AWS Regions configured as either three full replicas or two replicas plus a witness, providing the highest level of application resilience for mission-critical workloads.
- Amazon Nova Canvas update: Virtual try-on and style options now available – Amazon Nova Canvas introduces virtual try-on capabilities that help you visualize how clothing looks on a person by combining two images, plus eight new pre-trained style options (3D animation, design sketch, vector illustration, graphic novel, etc.) for generating images with improved artistic consistency. Available in three AWS Regions, these features enhance AI-powered image generation capabilities for retailers and content creators seeking realistic product visualizations.
- Amazon Q in Connect now supports 7 languages for proactive recommendations – Amazon Q in Connect, a generative AI-powered assistant for customer service, now provides proactive recommendations in seven languages: English, Spanish, French, Portuguese, Mandarin, Japanese, and Korean. The AI-powered customer service assistant detects customer intent during voice and chat interactions to help agents resolve issues quickly and accurately.
- Amazon Aurora MySQL and Amazon RDS for MySQL integration with Amazon SageMaker is now available – This integration provides near real-time data availability for analytics. It automatically extracts MySQL data into lakehouses with Apache Iceberg compatibility. You can then access this data seamlessly through various analytics engines and machine learning tools.
- Amazon Aurora DSQL is now available in additional AWS Regions – Amazon Aurora DSQL expands to Asia Pacific (Seoul) and now supports multi-Region clusters across Asia Pacific and European regions. This serverless, distributed SQL database offers unlimited scalability, highest availability, and zero infrastructure management with AWS Free Tier access.
Other AWS blog posts
- Optimize RAG in production environments using Amazon SageMaker JumpStart and Amazon OpenSearch Service – Learn how to optimize Retrieval Augmented Generation (RAG) in production environments using Amazon SageMaker JumpStart and Amazon OpenSearch Service. This comprehensive guide demonstrates implementing RAG workflows with LangChain, covers OpenSearch optimization strategies, provides setup instructions, and explains benefits of combining these AWS services for scalable, cost-effective generative AI applications.v
- Agentic GenAI App Using Bedrock, MCP servers on EKS – This post shows how to build a scalable AI chat application using Amazon Bedrock, Strands Agent, and Model Context Protocol (MCP) servers deployed on Amazon Elastic Kubernetes Service (Amazon EKS). The architecture combines agentic workflows with containerized microservices for intelligent, auto-scaling conversations with multiple foundation models.
- Enforce table level access control on data lake tables using AWS Glue 5.0 with AWS Lake Formation – AWS Glue 5.0 introduces Full-Table Access (FTA) control for Apache Spark with AWS Lake Formation, providing table-level security without fine-grained access overhead. This feature supports native Spark SQL/DataFrames for Lake Formation tables. It enables read/write operations on Iceberg and Hive tables with improved performance and lower costs.
Upcoming AWS events
Check your calendars and sign up for these upcoming AWS events:
- AWS re:Invent – Register now to get a head start on choosing your best learning path, booking travel and accommodations, and bringing your team to learn, connect, and have fun. Early-career professionals can apply for the All Builders Welcome Grant program, designed to remove financial barriers and create diverse pathways into cloud technology. Applications are now open and close on July 15, 2025.
- AWS NY Summit – You can gain insights from Swami’s keynote featuring the latest cutting-edge AWS technologies in compute, storage, and generative AI. My News Blog team is also preparing some exciting news for you. If you’re unable to attend in person, you can still participate by registering for the global live stream. Also, save the date for these upcoming Summits in July and August near your city.
- AWS Builders Online Series – If you’re based in one of the Asia Pacific time zones, join and learn fundamental AWS concepts, architectural best practices, and hands-on demonstrations to help you build, migrate, and deploy your workloads on AWS.
- Join AWS Gen AI Lofts – Experience AWS Gen AI Lofts across San Francisco, Berlin, Dubai, Dublin, Bengaluru, Manchester, Paris, Tel Aviv, and additional locations – hands-on workshops, expert guidance, investor networking, and collaborative spaces designed to accelerate your generative AI startup journey.
You can browse all upcoming in-person and virtual events.
That’s all for this week. Check back next Monday for another Weekly Roundup!
— Eli
U-Boot v2025.07 released
Post Syndicated from jake original https://lwn.net/Articles/1029092/
The U-Boot universal bootloader project
has announced the release of version 2025.07. It has multiple new features
including “uthreads” (inspired by the “bthreads” coroutines in the barebox bootloader), exFAT support,
new architecture and SoC support and improvements to existing platforms,
cleanups, better testing, and more. Project leader Tom Rini took the
opportunity to mention his efforts
toward getting some help with the project and more formal governance:
As this is a full release, and not just a release candidate I’m hoping
for a few more people to read this and then read what I’m linking to as
well. For the overall health of the project, and the community, I’m
hoping to find a few people within the community that can help with
overall organization and management. I would like to long term be able
to move us to being under the Software Freedom Conservancy umbrella and
that in turn means having a organizational structure that’s not just a
single person.
He also noted that there is a community meeting on July 8th, 2025 at 9am (GMT -06:00) on
Google Meet.
„Киберпънк 2077“. Удоволствие и лудонаративен дисонанс (трета част)
Post Syndicated from original https://www.toest.bg/kiberpunk-2077-udovolstvie-i-ludonarativen-disonans-3/
<< Към втора част

Северина Станкева: Според мен В. препраща и към едноименния роман на Пинчън. Там паралелно текат два разказа: от една страна – този на Бени Профейн, бивш моряк от американските Военноморски сили, който безцелно се шляе из Ню Йорк; от друга – този на Хърбърт Стенсил, англичанин, обсебен да намери мистериозната В., която присъства в дневниците на изчезналия му баща.
В. се появява постоянно в различни фигури: като жена в центъра на политическа интрига в Кайро през XIX век, като плъх от нюйоркското метро, който иска да стане монахиня, като града Валета, като малтийка, която е модифицирала тялото си толкова, че почти нищо естествено не е останало в него – има стъклено око с часовников механизъм, метална пластина в черепа и изкуствени крака.
Освен очевидната близост с кибернетичните протези, в „Киберпънк“ – и в романа, и в играта – имаме, най-общо казано, две линии на всяко ниво, които в крайна сметка така и не могат да се съберат, за да образуват постоянен център, но парадоксално, не могат да бъдат и съвсем ясно отделени. Разцеплението е в самия главен герой, доколкото той е буквално обсебен от друга персона. И доколкото се олюлява между тоталния нихилизъм и търсенето на смисъл в града, който обещава високи технологии и слава, но заедно с това носи мизерен живот. Разрив има и у Джони, чиято сребърна ръка е всъщност производство на „Арасака“ – корпорацията, срещу която е насочен бунтът му. Понеже тези противоречия са вплетени наративно, започнах с това, че играта ми се струва по-скоро резонантна, макар да съм съгласна, че изпълняването на тривиални поръчения, когато се предполага, че главният герой умира, е класически пример за лудонаративен дисонанс.
Връщайки се към невъзможността да се разграничи автентичното от фалша, изглежда, че съпротивата е обезвредена от процес, наречен от Дебор recuperation (възстановяване) – в него всяка революционна идея се попива от масовата култура. Един от въпросите на играта е възможно ли да има ответен удар, или détournement (преобръщане), при който, обратно, средствата на зрелището се използват с подривни цели. Като че ли ясен отговор не е даден, дори ми се струва, че допълнително се проблематизира невъзможността за отличаване на едното от другото.
Например в мисията Killing in the name, чието заглавие неслучайно препраща към песен на антиавторитарната, но комерсиално много успешна банда Rage Against the Machine, В. тръгва по следите на мистериозния хакер Сведенборг-Ривиера, разпространяващ криптирани бунтовнически слогани из интернет, като „Човечеството е само финансова пирамида, скрита зад фасада от сълзи“, от които Джони е изключително впечатлен. След доста продължително лутане в търсене на източника става ясно, че Сведенборг всъщност е хакната машина за гадаене, която е препрограмирана да произвежда псевдофилософски брътвежи. Играчът има три възможности: да остави машината, както си е, да я изключи или да я препрограмира отново, така че да говори още по-големи глупости от типа на „Средствата за производство трябва да принадлежат на колективното несъзнавано“. Джони е най-доволен от последната. Невъзможността да се отсъди категорично за значението на подобни действия е изключително интересна тема.

Кадри от „Киберпънк“
Николай Генов: Да мислим Джони като отпадъчен остатък от една традиция ми се струва особено важен ход, защото подобна интерпретация отваря неговия образ към литературния му първоизточник и с това позволява да свържем две различни медии. В случая, разбира се, визирам книгите от поредицата „Киберпънк 2020“ – настолната ролева серия на Майк Пондсмит, публикувана през 1988 г., чийто свят компютърната „Киберпънк 2077“ наследява.
В този текст от края на 80-те години Джони е доста по-различен от превъплъщението на Киану Рийвс. Той е, така да се каже, далеч по-наивен и чист; не е толкова циничен, самодеструктивен, фанатичен или брутален. Има си перчем. Вежлив е, извинява се често. С две думи, добро момче, което само иска да спаси своята приятелка Алт от ръцете на „Арасака“ в разказа „Не изтлявай“ (Never Fade Away). За целта той е готов да подгрее и настърви тълпа младежи срещу корпорацията, използвайки собствената си музика като оръжие през 2013 г.
Защо това има някакво значение?
Както Чавдар вече отбеляза, ние не можем да бъдем сигурни доколко дигиталният образ на Джони отговаря на действителния. Фенове вече забелязват определени наративни разминавания. Например Морган Черната ръка (Blackhand) – друг важен герой от фикционалната вселена, към когото има препратки в компютърната игра – бива нает от „Милитех“, за да взриви кулата на техния най-голям конкурент. Джони, вече някак променен след смъртта на Алт, е с него. Годината е 2023-та. Екипите на двамата де факто изпълняват корпоративна поръчка. Не така ни е представена историята през очите на двойника обаче. Това променен разказ ли е, или подвеждащо свидетелство? Проблем на адаптацията или повествователна стратегия? Имало ли е някога истински бунт, или и той ще се окаже поредната фикция?
Струва ми се, че отговорът може да дойде само през главния герой и решенията на играча; впрочем хубав повод да се запитаме отново какво точно е В. и какви са неговите функции в „2077“.
Миглена Николчина: Преди настолните игри на 80-те са реалните прототипи от 60-те – екстатично-трагичната биография на Джим Морисън например. Вървейки назад, ще стигнем до Хийтклиф, до Байрон, до бунта на романтизма. В тази перспектива бунтарският аспект на автодеструктивността на Джони ми се вижда логичен, каквито и противоречиви черти да притежава.
В моралната или въобще в личностната хетерогенност на персонажите има обаче и аспект, произтичащ от „стереоскопичната“ направа на героите в ролевите видеоигри: изборите, които прави играчът, „извайват“ не само облика на аватара, но и на неигровите действащи лица. Аватарът е съединен с останалите персонажи в мрежа, като скачени съдове са, промените засягат цялата система. Това че влюбеността на моята аватарка в Джони го възприемаше като анимус, като аспект на собствената ѝ психика, някак неизбежно предполагаше той да се жертва, тоест да се разтопи, да изчезне като отвъдно сияние в собствената ѝ кратка слава.
Впрочем може би най-тежкият избор е между Рийд и хакерката „Пойна птица“ (Songbird – ако си бях превела името ѝ навреме, може би нямаше да застана на нейна страна – кому „пее“ тя?). В този избор може би се крие и най-дълбоката ирония на играта, тъй като и двамата обслужват един и същи имперски режим, който разчита на лоялност, без да се отплаща с лоялност. Двамата са персонажи в добавката „Фантомна свобода“, която повдига на степен дистопийните аспекти на играта. Редица детайли, включително името на обожествения господар на една отцепила се като автономна зона част на града, говорят за преднамерена аналогия между „Фантомна свобода“, от една страна, а от друга, „Сърцето на мрака“ на Джоузеф Конрад и базирания върху новелата филм на Копола „Апокалипсис сега“. И в трите случая Курц/Кърц/Кърт Хансен е бивш служител на империята, която иска да го отстрани, защото вече не ѝ се подчинява, но и защото като неин продукт я компрометира. Той действа, сякаш е загубил разсъдъка си, държи се като божество, боготворен е от онези, които смазва, и е преминал всички граници на чудовищно кървава злоупотреба с властта си. И в трите случая обаче тази лудост се състои в смъкването на лицемерната идеологическа фасада на бившите му господари, в които е вярвал – той просто продължава да прави в собствената си зона това, което е правил за тях, оголвайки бруталната истина от „смокиновия лист“ на претенциите за право и морал.
Сравнението с Конрад и Копола обаче не работи в полза на играта. Новелата и филмът неумолимо ни водят към страховита развръзка, която ни среща с човек, поел върху себе си злото в пълно съзнание, човек, който – за да го кажем по Ницше тук – се е взрял в бездната, и тя също се е взряла в него. „Ужасът. Ужасът“ – е последната му реплика, преди да умре. Той е престъпникът и жертвата – за да се върнем към тази тема – засмукал в себе си вината и греха на онези, които е обслужвал.
Лудонаративният дисонанс, за жалост, превръща Кърт Хансен в поредния казионен противник, който трябва да бъде отстранен; не му позволява да постигне статута на своите предшественици. Така заковаването на пироните върху разпънатия Грешник отново ще се окаже по-откровената версия на една тема, която пронизва играта на всички нива.


Кадри от „Киберпънк“
Еньо Стоянов: Когато обсъждаме играта, не бива да забравяме и как тя тематизира изборите, които вменява на играча. Още преди първата мисия от основния сюжет, чиито последствия определят ситуацията на В., един от персонажите формулира темата така: „Дали искаш да изгориш в блясъка на славата, или да изтлееш като господин/госпожа Никой в собственото си легло?“ Тоест алтернатива между индивидуален бунт, утвърждаващ смисъла на живота само под формата на преждевременна и зрелищна смърт, и съответно комфорта на безропотно подчинение на корпоративните господари на града.
Несъмнено всички герои, които коментираме тук – Джони¹, Грешника, В. (поне в началото) – са склонни да предпочитат първото². Но играта всякак се опитва да покаже защо това е фалшив избор. И смъртта „в блясъка на славата“ неизбежно се оказва обезсмислена, тъй като дирижиращите спектакъла корпорации отново си я присвояват – на мястото на атентата, извършен от Джони, в съвремието на играта има музеен атракцион; Джошуа – независимо колко искрен е – вижда стойност единствено в превръщането на мъченичеството си в медийно шоу; а В. … – там вече нещата зависят от избора на играча.
Което ме връща към казаното от Миглена в първата част на разговора ни – дали спектакълът не подрива мрачните теми на играта. Може би по-скоро съблазънта му е самата мрачна тема, определяща нейния свят.
Чавдар Парушев: Ще добавя нещо по повод решенията, които играчът взима сам, и стереоскопичните отражения от тях в изграждането на неигровите действащи лица, както и по повод изборите, които играта вменява на играча. Финалът на играта предполага да бъде преодоляна специфичната раздвоеност на В. като две личности в едно тяло. Да се направи лудонаративен избор и да се запази единият за сметка на другия персонаж, за да завърши разказът на играта. През повечето време смятах, че ще избера В. В крайна сметка реших тъкмо обратното. Може би защото схванах избора като това дали жертвам и двамата за кратка отсрочка на неизбежния край на В., или само него, за да може Джони истински да оживее.
Но може би финалният избор е възможно да бъде схванат и като избор между две времена. От една страна, Джони и неговият бунт от фикционалната 2023-та като съпротивляващото се минало, от друга – В. от 2077 като настоящето или новото, което се бори да намери собствено място под слънцето, да оцелее под натиска на притискащите го фактори. Схващане, оформено и от собственото ми проиграване, което разпредели двамата в ролите на наставник и ученик по принуда с известна реципрочност и размяна на ролите между Джони и В.
В този смисъл за мен бунтът на настоящето се оказа някак твърде очевиден и самозатворен, твърде много сведен само до оцеляване. Докато този в миналото се оказа по-интересен. Какъв би бил вторият живот на Джони Сребърната ръка? Да кажем, ако разработчиците на играта решат да продължат с втора част с Джони като аватар за играча? Какво ако миналото се завърне вече не като дигитален призрак или като пародиен брътвеж на панаирджийска машинна ясновидка, пробутана на майтап като революционен пророк и за още по-голям смях взета на сериозно? Ами ако миналото се завърне като помъдряла, претърпяла развитие и способна да действа личност с поуките от грешките и с отстояната вярност на принципите си? А не като пасивен геологически пласт, който стои под повърхнината на настоящето, за да оформя неравностите – гънките, бабуните и прорезите на релефа му?
Тази съпротива чрез минало като дееспособна памет на втора степен също ли би била толкова обречена, колкото другите, срещу дистопичността на безпаметното настояще на подкупни корпорации, улични престъпни банди, търговци на оръжие и виртуални наркотици, лекари кибернетици, вуду хакери и заплашителни джунгли от изкуствени интелекти зад високи черни стени, които съставляват фикцията на играта? Играта отваря, не затваря подобни въпроси.
2 Играчите могат да избират между три варианта за произход на В., единият от които е всъщност на корпоративен служител, захвърлен от корпорацията, на която служи, въпреки и дори заради това, че изпълнява корпоративните заповеди. Тоест и комфортът, обещаван от корпорацията, се оказва измамен.
В рубриката „Игромислие“ публикуваме разговори, в които се срещат, съпоставят и противопоставят различни гледни точки към многоизмерния, многожанров феномен на видеоигрите – не толкова като електронен спорт, колкото като нов синтез на изкуствата и като ново поле на общуване и социалност.
Bash-5.3-release available
Post Syndicated from jake original https://lwn.net/Articles/1029079/
The GNU project’s Bourne Again
SHell (Bash) has released version 5.3, with some significant new
features, including some from the associated
Readline 8.3 release, which provides
command-line editing and other features for Bash and lots of other
programs. Bash 5.3 has a “new form of command substitution that executes the command in
“, pathname-completion sorting
the current shell execution context
will be handled based on the GLOBSORT shell variable, generated
completions can go to a shell variable instead of to stdout, the source
code has been updated to C23, and more. Meanwhile:
Readline has new features as well. There is a new option that allows
case-insensitive searching, a new command that executes a named readline
command, and a new command that exports possible word completions in a
specified format for consumption by another process.
[$] A tour of the niri scrolling-tiling Wayland compositor
Post Syndicated from jzb original https://lwn.net/Articles/1025866/
Niri
is a relatively new Rust-based compositor
for Wayland with a different take on tiling window management: windows
are placed onscreen in an “infinite” row that can expand beyond the
bounds of the visible workspace. It is not a full-blown desktop
environment, but niri may be a suitable option for Linux users who
want tiling features and the minimalism of a window manager for
Wayland.
2025 CyberVadis report now available for due diligence on third-party suppliers
Post Syndicated from Tea Jioshvili original https://aws.amazon.com/blogs/security/2025-cybervadis-report-now-available-for-due-diligence-on-third-party-suppliers/
We’re excited to announce that AWS has completed the CyberVadis assessment of its security posture with the highest score (Mature) in all assessed areas. This demonstrates our continued commitment to meet the heightened expectations for cloud service providers. Customers can now use the 2025 AWS CyberVadis report and scorecard to reduce their supplier due-diligence burden.
With the increasing adoption of cloud products and services across multiple sectors and industries, AWS is a critical component of customers’ third-party environments. Regulated customers, such as those in the financial services sector, are held to high standards by regulators and auditors when it comes to exercising effective due diligence on third parties.
Many customers use third-party risk management services such as CyberVadis to better manage risks from their evolving third-party environments and drive operational efficiencies. In support of these efforts, AWS has completed its annual CyberVadis security posture assessment, conducted by CyberVadis security analysts.
CyberVadis is a comprehensive third-party risk assessment process that combines the speed and scalability of automation with the certainty of analyst validation. CyberVadis assessments employ a dynamic and comprehensive approach to third-party risk assessment, replacing outdated static spreadsheets and the need for annual AWS assessment access requests. This cloud-based solution provides advanced capabilities by integrating AWS responses with analytics and sophisticated risk models to deliver an in-depth view of the security posture of AWS.
CyberVadis’s risk assessment methodology evaluates 20 topics covering the entire cybersecurity life cycle across four phases: Identify, Protect, Detect, and React. These topics include Data Privacy, Access Management, and Infrastructure Security. The assessment criteria are based on international information security standards, including ISO 2700x, NIST Cybersecurity Framework, Cybersecurity for ICS, PCI DSS, NIS2 and GDPR.
Customers can use CyberVadis results to map the assessment of AWS to commonly used industry frameworks and standards to instantly gain visibility into controls coverage.
AWS customers can download the complete 2025 AWS Assessment Report directly through CyberVadis’s portal using their own account, or through AWS Artifact.
We value your feedback and questions. Reach out to the AWS Compliance team through the Contact Us page. If you have feedback about this post, submit comments in the Comments section below. To learn more about our other compliance and security programs, see AWS Compliance Programs.
Security updates for Monday
Post Syndicated from jake original https://lwn.net/Articles/1029073/
Security updates have been issued by Debian (thunderbird and xmedcon), Fedora (darktable, mbedtls, sudo, and yarnpkg), Mageia (catdoc and php), Red Hat (java-1.8.0-ibm, kernel, python-setuptools, python3, python3.11, python3.12, python3.9, socat, sudo, tigervnc, webkit2gtk3, webkitgtk4, xorg-x11-server, and xorg-x11-server-Xwayland), SUSE (alloy, apache-commons-fileupload, apache2-mod_security2, assimp-devel, chromedriver, clamav, clustershell, corepack22, ctdb, curl, dpkg, erlang-rabbitmq-client, ffmpeg-4, firefox, firefox-esr, flake-pilot, fractal, gdm, ggml-devel-5699, gio-branding-upstream, git-lfs, glib2, glibc, go1.23, go1.24, govulncheck-vulndb, gpg2, grafana, grype, helm, himmelblau, icu, jgit, jq, jupyter-bqplot-jupyterlab, jupyter-jupyterlab-templates, jupyter-matplotlib, jupyter-nbclassic, jupyter-nbdime, jupyter-panel, jupyter-plotly, keylime-ima-policy, kubernetes1.30-apiserver, kubernetes1.31-apiserver, kubernetes1.32-apiserver, libbd_btrfs-devel, libetebase-devel, libmozjs-128-0, libprotobuf-lite31_1_0, libQt5Bootstrap-devel-static-32bit, libsoup, libsoup-2_4-1, libsoup-3_0-0, libspdlog1_15, libssh, libssh-config, libsystemd0, libtpms-devel, libwireshark18, libwx_gtk2u_adv-suse16_0_0, mirrorsorcerer, moarvm, nix, nodejs-electron, nova, oci-cli, opa, openbao, ovmf-202505, pam, pam_pkcs11, perl, perl-32bit, perl-CryptX, perl-File-Find-Rule, perl-YAML-LibYAML, podman, polaris, postgresql-jdbc, pure-ftpd, python-furo-doc, python-requests, python310, python311, python311-Django, python311-Django4, python311-jupyter-core, python311-Pillow, python311-pydata-sphinx-theme, python311-requests, python311-salt, python311-urllib3, python312, python313, python314, python39, radare2, redis, samba, SDL, SDL2, sudo, teleport, thunderbird, tomcat, tomcat10, tomcat11, traefik, traefik2, valkey, velociraptor, vim, xorg-x11-server, and xwayland), and Ubuntu (linux-ibm, linux-intel-iotg, linux-lowlatency, linux-lowlatency-hwe-6.11, and linux-oem-6.14).
Желязков започна да продава от онези 4400 имота
Post Syndicated from Боян Юруков original https://yurukov.net/blog/2025/jelyazkov-prodava/
На 8-ми май министър председателят Желязков обяви, че са изготвили списък с 4400 държавни имота, за които е отпаднала необходимост и ще бъдат продадени. В следващите дни настояваше, че няма да се бавят и ще продават онези, за които било проявен интерес и в момента са в тежест на държавата. Въпреки многобройните запитвания, не стана ясно какво означава „отпаднала необходимост“, как някои са проявили или обявили, че проявяват интерес и каква е методологията за определяне на тези имоти. Казаха обаче, че всичко ще е прозрачно.
След като два месеца нямаше нито отговори, нито списък, нито методология, успях да получа данни от тях за имотите и направих карта, която да показва кои са тези имоти и къде са. Картата предизвика много реакции, включително отговор от Министерски съвет, че всъщност нямало да продават веднага, че това бил предварителен списък и след внимателен анализ ще преценят къде е отпаднала необходимост и какво да се прави. Много медии и активисти използваха картата да намират обекти, които ще се продават, а не следва по различни причини. Оказа се също, че много кметове не са били дори уведомени за плановете за държавни имоти в техните общини. За много от обектите дори не се знаеше каква е собствеността и в коя компания с държавно участие са свършили.
Затова дадох възможност за подаване на сигнали направо в картата. Получихме няколко десетки за последната седмица и се преглеждат. Целта е да се задават конкретни и добре формулирани въпроси към съответните институции от пленарна зала.
Много повече бяха запиванията къде са търговете, къде може да си купи човек имот. Сякаш доста повече хора искаха да „намажат“ от хаоса, който прозира в целия процес, отколкото такива, които искаха да спрат безвъзвратната загуба особено на апетитни парчета земя. В действителност, по-големият интерес към такива търгове не е лошо. Не се съмнявам, че има много държавни имоти, които тънат в разруха и не се използват. Принципно няма нищо лошо в това да се продадат и използва и големият интерес към тях само би следвало да повиши цената им. Както изтъкнах пред Свободна Европа, проблемът е, че сред тези 4400 несъмнено са намушкани не един и два имота, към които отдавна има апетити и планове и се използва повода да бъдат подарени сред традиционната липса на прозрачност и хаос.
Първото го намалихме. Сега натискаме по второто.

Агенция за публичните предприятия и контрол
Това е наследникът на небезизвестната Агенция за приватизация. Именно те трябва да извършат търговете за онези имоти сред 4400-те, които Желязков все пак реши да продаде. Както каза – не веднага, а след внимателен анализ.
Тези дни автоматизирах следенето на регистъра им и вече в реално време на GovAlert може да се следи дали има нови търгове и промени по съществуващи. Вече са публикувани съобщения за планираните към този момент – 15 от които само 4 имат насрочени дати. Работя по това да сложа имотите, за които се отнасят търговете на картата с „ония“ списък на Желязков, както и в картата за градоустройството на София, Пловдив и Благоевград. Няма да ги включа в картата със застрояването в София. Същото важи за почти 600-те търга, които агенцията е провела в последните 5 години.

Докато разглеждах търговете, забелязах няколко познати. Сред 15-те планирани търга, има шест включени в списъка на Желязков – същите, за които каза, че трябвало внимателен анализ, който тепърва щял да се прави. Проблемът с това изказване е, че някои от тези търгове са били обявени преди да бъде направено, преди да публикувам картата си, да се разбере какво правят и да предоставят дори данните.
- Имот в с. Драгоево, Шумен – търг обявен на 1. юли, насрочен за 24. юли | Карта | Търг
- Имот в с. Тодор Икономово, Шумен – търг обявен на 1. юли | Карта | Търг
- Имот в Габрово – търг обявен на 16. юни | Карта | Търг
- Имот в Разград – търг обявен на 13. юни | Карта | Търг
- Имот в Разград – търг обявен на 10. юни | Карта | Търг
- Имот в Свиленград – търг обявен на 9. юни | Карта | Търг
Иначе казано, първите шест от 4400 вече са били пуснати за продажба след решението на правителството. Доколкото последното съобщение на МРРБ, че щяло да има подробен анализ и прозрачност преди каквото и да се продава да противоречи на твърденията на Желязков преди това, тези действия на агенцията всъщност потвърждава притесненията ни, че ще бързат.
Какви са измеренията на това ще разберем тепърва. Вече може да следим за нови електронни търгове през GovAlert (търсете АППК), но не знам дали ще правят и такива, които не се обявяват в публичния им регистър и дали всички продажби от държавни институции и компании минават през тази агенция. Би трябвало, но цинизмът и опитът с работа с държавни институции неизменно носи със себе си съмнения.
Паметник на културата с предизвестен край

Междувременно днес попаднах на интересна продажба от същата агенция. Първият етаж в тази къща заедно с 50% от общите части е бил продаден през 2021 за 540 хиляди лв. на оръжейния търговец Кирил Кленовски. Кленовски е свързан с Пеевски. През 2016-та е купил втория етаж заедно с останалото от къщата. Самата къща е паметник на културата и предвид местоположението цената е много под себестойността дори на парцела. Мисля, че знаем какво ще се случи с къщата. На това място може да се строи до 5-6 етажа освен, ако нямаш човек в СОС и ВАС. Как
The post Желязков започна да продава от онези 4400 имота first appeared on Блогът на Юруков.
Overcome your Kafka Connect challenges with Amazon Data Firehose
Post Syndicated from Swapna Bandla original https://aws.amazon.com/blogs/big-data/overcome-your-kafka-connect-challenges-with-amazon-data-firehose/
Apache Kafka is a popular open source distributed streaming platform that is widely used in the AWS ecosystem. It’s designed to handle real-time, high-throughput data streams, making it well-suited for building real-time data pipelines to meet the streaming needs of modern cloud-based applications.
For AWS customers looking to run Apache Kafka, but don’t want to worry about the undifferentiated heavy lifting involved with self-managing their Kafka clusters, Amazon Managed Streaming for Apache Kafka (Amazon MSK) offers fully managed Apache Kafka. This means Amazon MSK provisions your servers, configures your Kafka clusters, replaces servers when they fail, orchestrates server patches and upgrades, makes sure clusters are architected for high availability, makes sure data is durably stored and secured, sets up monitoring and alarms, and runs scaling to support load changes. With a managed service, you can spend your time developing and running streaming event applications.
For applications to use data sent to Kafka, you need to write, deploy, and manage application code that consumes data from Kafka.
Kafka Connect is an open-source component of the Kafka project that provides a framework for connecting with external systems such as databases, key-value stores, search indexes, and file systems from your Kafka clusters. On AWS, our customers commonly write and manage connectors using the Kafka Connect framework to move data out of their Kafka clusters into persistent storage, like Amazon Simple Storage Service (Amazon S3), for long-term storage and historical analysis.
At scale, customers need to programmatically manage their Kafka Connect infrastructure for consistent deployments when updates are required, as well as the code for error handling, retries, compression, or data transformation as it is delivered from your Kafka cluster. However, this introduces a need for investment into the software development lifecycle (SDLC) of this management software. Although the SDLC is a cost-effective and time-efficient process to help development teams build high-quality software, for many customers, this process is not desirable for their data delivery use case, particularly when they could dedicate more resources towards innovating for other key business differentiators. Beyond SDLC challenges, many customers face fluctuating data streaming throughput. For instance:
- Online gaming businesses experience throughput variations based on game usage
- Video streaming applications see changes in throughput depending on viewership
- Traditional businesses have throughput fluctuations tied to consumer activity
Striking the right balance between resources and workload can be challenging. Under-provisioning can lead to consumer lag, processing delays, and potential data loss during peak loads, hampering real-time data flows and business operations. On the other hand, over-provisioning results in underutilized resources and unnecessary high costs, making the setup economically inefficient for customers. Even the action of scaling up your infrastructure introduces additional delays because resources need to be provisioned and acquired for your Kafka Connect cluster.
Even when you can estimate aggregated throughput, predicting throughput per individual stream remains difficult. As a result, to achieve smooth operations, you might resort to over-provisioning your Kafka Connect resources (CPU) for your streams. This approach, though functional, might not be the most efficient or cost-effective solution.
Customers have been asking for a fully serverless solution that will not only handle managing resource allocation, but transition the cost model to only pay for the data they are delivering from the Kafka topic, instead of underlying resources that require constant monitoring and management.
In September 2023, we announced a new integration between Amazon and Amazon Data Firehose, allowing builders to deliver data from their MSK topics to their destination sinks with a fully managed, serverless solution. With this new integration, you no longer needed to develop and manage your own code to read, transform, and write your data to your sink using Kafka Connect. Data Firehose abstracts away the retry logic required when reading data from your MSK cluster and delivering it to the desired sink, as well as infrastructure provisioning, because it can scale out and scale in automatically to adjust to the volume of data to transfer. There are no provisioning or maintenance operations required on your side.
At release, the checkpoint time to start consuming data from the MSK topic was the creation time of the Firehose stream. Data Firehose couldn’t start reading from other points on the data stream. This caused challenges for several different use cases.
For customers that are setting up a mechanism to sink data from their cluster for the first time, all data in the topic older than the timestamp of Firehose stream creation would need another way to be persisted. For example, customers using Kafka Connect connectors, like These users were limited in using Data Firehose because they wanted to sink all the data from the topic to their sink, but Data Firehose couldn’t read data from earlier than the timestamp of Firehose stream creation.
For other customers that were running Kafka Connect and needed to migrate from their Kafka Connect infrastructure to Data Firehose, this required some extra coordination. The release functionality of Data Firehose means you can’t point your Firehose stream to a specific point on the source topic, so a migration requires stopping data ingest to the source MSK topic and waiting for Kafka Connect to sink all the data to the destination. Then you can create the Firehose stream and restart the producers such that the Firehose stream can then consume new messages from the topic. This adds additional, and non-trivial, overhead to the migration effort when attempting to cut over from an existing Kafka Connect infrastructure to a new Firehose stream.
To address these challenges, we’re happy to announce a new feature in the Data Firehose integration with Amazon MSK. You can now specify the Firehose stream to either read from the earliest position on the Kafka topic or from a custom timestamp to begin reading from your MSK topic.
In the first post of this series, we focused on managed data delivery from Kafka to your data lake. In this post, we extend the solution to choose a custom timestamp for your MSK topic to be synced to Amazon S3.
Overview of Data Firehose integration with Amazon MSK
Data Firehose integrates with Amazon MSK to offer a fully managed solution that simplifies the processing and delivery of streaming data from Kafka clusters into data lakes stored on Amazon S3. With just a few clicks, you can continuously load data from your desired Kafka clusters to an S3 bucket in the same account, eliminating the need to develop or run your own connector applications. The following are some of the key benefits to this approach:
- Fully managed service – Data Firehose is a fully managed service that handles the provisioning, scaling, and operational tasks, allowing you to focus on configuring the data delivery pipeline.
- Simplified configuration – With Data Firehose, you can set up the data delivery pipeline from Amazon MSK to your sink with just a few clicks on the AWS Management Console.
- Automatic scaling – Data Firehose automatically scales to match the throughput of your Amazon MSK data, without the need for ongoing administration.
- Data transformation and optimization – Data Firehose offers features like JSON to Parquet/ORC conversion and batch aggregation to optimize the delivered file size, simplifying data analytical processing workflows.
- Error handling and retries – Data Firehose automatically retries data delivery in case of failures, with configurable retry durations and backup options.
- Offset select option – With Data Firehose, you can select the starting position for the MSK delivery stream to be delivered within a topic from three options:
- Firehose stream creation time – This allows you to deliver data starting from Firehose stream creation time. When migrating from to Data Firehose, if you have an option to pause the producer, you can consider this option.
- Earliest – This allows you to deliver data starting from MSK topic creation time. You can choose this option if you’re setting a new delivery pipeline with Data Firehose from Amazon MSK to Amazon S3.
- At timestamp – This option allows you to provide a specific start date and time in the topic from where you want the Firehose stream to read data. The time is in your local time zone. You can choose this option if you prefer not to stop your producer applications while migrating from Kafka Connect to Data Firehose. You can refer to the Python script and steps provided later in this post to derive the timestamp for the latest events in your topic that were consumed by Kafka Connect.

The following are benefits of the new timestamp selection feature with Data Firehose:
- You can select the starting position of the MSK topic, not just from the point that the Firehose stream is created, but from any point from the earliest timestamp of the topic.
- You can replay the MSK stream delivery if required, for example in the case of testing scenarios to select from different timestamps with the option to select from a specific timestamp.
- When migrating from Kafka Connect to Data Firehose, gaps or duplicates can be managed by selecting the starting timestamp for Data Firehose delivery from the point where Kafka Connect delivery ended. Because the new custom timestamp feature isn’t monitoring Kafka consumer offsets per partition, the timestamp you select for your Kafka topic should be a few minutes before the timestamp at which you stopped Kafka Connect. The earlier the timestamp you select, the more duplicate records you will have downstream. The closer the timestamp to the time of Kafka Connect stopping, the higher the likelihood of data loss if certain partitions have fallen behind. Be sure to select a timestamp appropriate to your requirements.
Overview of solution
We discuss two scenarios to stream data.
In Scenario 1, we migrate to Data Firehose from Kafka Connect with the following steps:
- Derive the latest timestamp from MSK events that Kafka Connect delivered to Amazon S3.
- Create a Firehose delivery stream with Amazon MSK as the source and Amazon S3 as the destination with the topic starting position as Earliest.
- Query Amazon S3 to validate the data loaded.
In Scenario 2, we create a new data pipeline from Amazon MSK to Amazon S3 with Data Firehose:
- Create a Firehose delivery stream with Amazon MSK as the source and Amazon S3 as the destination with the topic starting position as At timestamp.
- Query Amazon S3 to validate the data loaded.
The solution architecture is depicted in the following diagram.

Prerequisites
You should have the following prerequisites:
- An AWS account and access to the following AWS services:
- Amazon Elastic Compute Cloud (Amazon EC2)
- Amazon Data Firehose
- AWS Identity and Access Management (IAM)
- Amazon MSK
- Amazon S3
- An MSK provisioned or MSK serverless cluster with topics created and data streaming to it. The sample topic used in this is
order. - An EC2 instance configured to use as a Kafka admin client. Refer to Create an IAM role for instructions to create the client machine and IAM role that you will need to run commands against your MSK cluster.
- An S3 bucket for delivering data from Amazon MSK using Data Firehose.
- Kafka Connect to deliver data from Amazon MSK to Amazon S3 if you want to migrate from Kafka Connect (Scenario 1).
Migrate to Data Firehose from Kafka Connect
To reduce duplicates and minimize data loss, you need to configure your custom timestamp for Data Firehose to read events as close to the timestamp of the oldest committed offset that Kafka Connect reported. You can follow the steps in this section to visualize how the timestamps of each committed offset will vary by partition across the topic you want to read from. This is for demonstration purposes and doesn’t scale as a solution for workloads with a large number of partitions.
Sample data was generated for demonstration purposes by following the instructions referenced in the following GitHub repo. We set up a sample producer application that generates clickstream events to simulate users browsing and performing actions on an imaginary ecommerce website.
To derive the latest timestamp from MSK events that Kafka Connect delivered to Amazon S3, complete the following steps:
- From your Kafka client, query Amazon MSK to retrieve the Kafka Connect consumer group ID:

- Stop Kafka Connect.
- Query Amazon MSK for the latest offset and associated timestamp for the consumer group belonging to Kafka Connect.
You can use the get_latest_offsets.py Python script from the following GitHub repo as a reference to get the timestamp associated with the latest offsets for your Kafka Connect consumer group. To enable authentication and authorization for a non-Java client with an IAM authenticated MSK cluster, refer to the following GitHub repo for instructions on installing the aws-msk-iam-sasl-signer-python package for your client.

Note the earliest timestamp across all the partitions.
Create a data pipeline from Amazon MSK to Amazon S3 with Data Firehose
The steps in this section are applicable to both scenarios. Complete the following steps to create your data pipeline:
- On the Data Firehose console, choose Firehose streams in the navigation pane.
- Choose Create Firehose stream.

- For Source, choose Amazon MSK.
- For Destination, choose Amazon S3.

- For Source settings, browse to the MSK cluster and enter the topic name you created as part of the prerequisites.
- Configure the Firehose stream starting position based on your scenario:
- For Scenario 1, set Topic starting position as At Timestamp and enter the timestamp you noted in the previous section.

- For Scenario 2, set Topic starting position as Earliest.

- For Scenario 1, set Topic starting position as At Timestamp and enter the timestamp you noted in the previous section.
- For Firehose stream name, leave the default generated name or enter a name of your preference.
- For Destination settings, browse to the S3 bucket created as part of the prerequisites to stream data.
Within this S3 bucket, by default, a folder structure with YYYY/MM/dd/HH will be automatically created. Data will be delivered to subfolders pertaining to the HH subfolder according to the Data Firehose to Amazon S3 ingestion timestamp.

- Under Advanced settings, you can choose to create the default IAM role for all the permissions that Data Firehose needs or choose existing an IAM role that has the policies that Data Firehose needs.

- Choose Create Firehose stream.

On the Amazon S3 console, you can verify the data streamed to the S3 folder according to your chosen offset settings.

Clean up
To avoid incurring future charges, delete the resources you created as part of this exercise if you’re not planning to use them further.
Conclusion
Data Firehose provides a straightforward way to deliver data from Amazon MSK to Amazon S3, enabling you to save costs and reduce latency to seconds. To try Data Firehose with Amazon S3, refer to the Delivery to Amazon S3 using Amazon Data Firehose lab.
About the Authors
Swapna Bandla is a Senior Solutions Architect in the AWS Analytics Specialist SA Team. Swapna has a passion towards understanding customers data and analytics needs and empowering them to develop cloud-based well-architected solutions. Outside of work, she enjoys spending time with her family.
Austin Groeneveld is a Streaming Specialist Solutions Architect at Amazon Web Services (AWS), based in the San Francisco Bay Area. In this role, Austin is passionate about helping customers accelerate insights from their data using the AWS platform. He is particularly fascinated by the growing role that data streaming plays in driving innovation in the data analytics space. Outside of his work at AWS, Austin enjoys watching and playing soccer, traveling, and spending quality time with his family.
How Stifel built a modern data platform using AWS Glue and an event-driven domain architecture
Post Syndicated from Amit Maindola original https://aws.amazon.com/blogs/big-data/how-stifel-built-a-modern-data-platform-using-aws-glue-and-an-event-driven-domain-architecture/
Stifel Financial Corp. is an American multinational independent investment bank and financial services company, founded in 1890 and headquartered in downtown St. Louis, Missouri. Stifel offers securities-related financial services in the United States and Europe through several wholly owned subsidiaries. Stifel provides both equity and fixed income research and is the largest provider of US equity research.
In this post, we show you how Stifel implemented a modern data platform using AWS services and open data standards, building an event-driven architecture for domain data products while centralizing the metadata to facilitate discovery and sharing of data products.
Stifel’s modern data platform use case
Stifel envisioned a data platform that delivers accurate, timely, and properly governed data, providing consistency throughout the organization whenever users access the information. This approach showed limitations as the data complexity increased, data volumes grew, and demand for quick, business-driven insights rose. These challenges are encountered by financial institutions worldwide, leading to a reassessment of traditional data management practices. Under the federated governance model, Stifel developed a modern data strategy based on the following objectives:
- Managing ingestion and metadata
- Creating source-aligned data products complying with Stifel business streams
- Integrating source-aligned data products from other domains (Stifel business units)
- Producing consumer-aligned data products for specific business purposes
- Publishing data products to a centralized data catalog
Some of the Stifel challenges highlighted in the preceding list required building a data platform that can:
- Boost agility by democratizing data, thus reducing time to market and enhancing the customer experience
- Improve data quality and trust in the data
- Standardize tools and eliminate the shadow information technology (IT) culture to increase scalability, reduce risk, and minimize operational inefficiencies
Following the federated governance model, Stifel has organized its domain structure to provide autonomy to various functional teams while preserving the core values of data mesh. The following diagram depicts a high-level architecture of the data mesh implementation at Stifel.

Each data domain has the flexibility to create data products that can be published to the centralized catalog, while maintaining the autonomy for teams to develop data products that are exclusively accessible to teams within the domain. These products aren’t available to others until they are deemed ready for broader enterprise use. Domains have the freedom to decide which data they want to share. They can either:
- Make their data products visible to everyone through the central catalog
- Keep their data products visible only within their own domain
By implementing an event-driven domain architecture, organizations can achieve significant business advantages while positioning themselves for future growth and innovation. Stifel data products refreshes were dependent on data assets with variable cadence. Event-driven architecture enables real-time or near real-time updates by allowing data products to automatically respond to changes in underlying data assets as they occur, rather than relying on fixed batch schedules that might miss critical updates or waste resources on unnecessary refreshes. The key is to carefully plan the implementation and make sure of alignment with business objectives while considering both technical and organizational factors. This architecture style particularly suits organizations that:
- Need real-time processing capabilities
- Have complex domain interactions
- Require high scalability
- Want to improve business agility
- Need better system integration
- Are pursuing digital transformation
The following are some of the key AWS Services that helped Stifel to build their modern data platform.
- AWS Glue is a serverless data integration service that’s used for data processing to build data assets and data products in the domains. Data is also cataloged in AWS Glue Catalog, making it straightforward to discover and query with supported engines.
- Amazon EventBridge provides a scalable and flexible serverless event bus that facilitates seamless communication between different domains and services. By using EventBridge, Stifel was able to implement a publish-subscribe model where domain events can be emitted, filtered, and routed to appropriate consumers based on configurable rules. EventBridge supports custom event buses for domain-specific events, enabling clear separation of concerns and improved manageability.
- AWS Lake Formation helped in providing centralized security, governance, and catalog capabilities while preserving domain autonomy in data product creation and management. With Lake Formation, data domains were able to maintain their independent data products within a federated structure while enforcing consistent access controls, data quality standards, and metadata management across the organization.
- Apache Hudi on Amazon Simple Storage Service (Amazon S3) offers an optimized way to store data assets and products and promotes interoperability across other services.
Stifel’s solution architecture
The following diagram illustrates the data mesh architecture that Stifel uses to build a domain-driven architecture. In this system, various domains create data products and share them with other domains through a central governance account that uses Lake Formation.

Let’s look at some of the key design components that are being used to enable and implement data mesh and event driven design
Data ingestion framework
The data ingestion framework consists of several processor modules that are built using several AWS services and metadata driven architecture. The following diagram shows the architecture of the raw data ingestion framework.

The framework gets raw data files from both internal Stifel systems and third-party data sources. These files are processed and stored in a raw data ingestion account on Amazon S3 in open table format Apache Hudi. This stored data is then shared with different parts of the organization, called data domains. Each domain can use this shared data to create their own data products.
As a file (in CSV, XML, JSON and custom formats) lands into the landing bucket, an Amazon S3 event notification is created and placed in an Amazon Simple Queue Service (Amazon SQS)queue. The Amazon SQS queue triggers an AWS Lambda function and saves the metadata (such as the name of the file, date and time the file was received, and the file size) to a file audit data store (Amazon Aurora PostgreSQL-Compatible Edition).
An EventBridge time scheduler invokes an AWS Step Functions workflow at pre-determined intervals. The Step Functions workflow orchestrates the batch ingestion from raw to staging layer.
- The Step Functions workflow orchestrates a set of Lambda functions to get the list of unprocessed raw files from the audit data store and create batches of raw files to process them in parallel. The Step Functions workflow then triggers parallel AWS Glue jobs that process each batch of raw files.
- Each raw file is validated for any data quality checks and the data is saved to staging tables in Hudi format. Any errors encountered are logged into an audit table and a notification is generated for support team. For all successfully processed raw files, the file status is updated to
PROCESSEDand logged into an audit table. - After the Hudi table is updated, a data refresh event is sent to EventBridge and then passed to the Central Mesh Account. The Central Mesh Account forwards these events to the data domains to notify them that the raw tables are refreshed, allowing the data domains to use this data for creating their own data products.
Event driven data product refresh
The Stifel data lake is based on a data mesh architecture where several data producers share data across data domains. A mechanism is needed to alert consumers who depend on other data producers’ data products when those source data products are refreshed, so that the consumers can update their own data products accordingly. The following diagram describes the technical architecture of event-based data processing. The central governance account acts as the central event bus, which receives all data refresh events from all data producers. The central event bus forwards the events to consumer accounts. The consumer accounts filter the events consumers are interested in from data producers for their data processing needs.

Orchestration design
Stifel designed and implemented an event-based data pipeline orchestration system that triggers data pipelines when specific events occur. This system processes data immediately after receiving all required dependency events, enabling efficient workflow management.
The following diagram describes the logical architecture of the domain data pipeline orchestration framework.

The orchestration framework includes the components described in the following list. The data dependencies and data pipeline state management metadata are hosted in an Aurora PostgreSQL database.
- Data refresh processor: Receives data refresh events from central mesh and local data domain and evaluates if the domain data products data dependencies are met
- Data product dependency processor: Retrieves metadata for the product, kicks off a corresponding data domain AWS Glue job, and updates metadata with the job information
- Data pipeline state change processor: Monitors the domain data jobs and takes actions based on the job’s final status (
SUCCEEDorFAILED) and then creates incident tickets for failed jobs
Conclusion
Stifel has improved its data management and reduced data silos by adopting a data product approach. This strategy has positioned Stifel to become a data-driven, customer-centric organization. The company combines federated platform practices with AWS and open standards. As a result, Stifel is achieving its decentralization objectives through a scalable data platform. This platform empowers domain teams to make informed decisions, drive innovation, and maintain a competitive edge. Here are the some of the advantages Stifel got from an event-driven domain architecture (EDDA):
- Business agility: Rapid market response, new business capability integration, scalable domains, quicker feature deployment, and flexible process modification
- Customer experience: Real-time processing, responsive interactions, personalized services, consistent omnichannel presence, and enhanced service availability
- Operational efficiency: Reduced system coupling, optimal resource use, scalable systems, lower maintenance overhead, and efficient data processing
- Cost benefits: Lower development costs, reduced infrastructure expenses, decreased maintenance costs, efficient resource usage, and a better ROI on technology investments
In this post, we demonstrated how Stifel is building a modern data platform by recognizing the critical importance of data in today’s financial landscape. This strategic approach not only enhances operational efficiency but also positions Stifel at the forefront of technological innovation in the financial services industry. To learn more and get started, see the following resources:
- Design a data mesh architecture using AWS Lake Formation and AWS Glue
- What is a Data Mesh?
- Data Mesh Delivering Data-Driven Value at Scale
- Build a modern data architecture and data mesh pattern at scale using AWS Lake Formation tag-based access control
About the authors
Amit Maindola is a Senior Data Architect focused on data engineering, analytics, and AI/ML at Amazon Web Services. He helps customers in their digital transformation journey and enables them to build highly scalable, robust, and secure cloud-based analytical solutions on AWS to gain timely insights and make critical business decisions.
Srinivas Kandi is a Senior Architect at Stifel focusing on delivering the next generation of cloud data platform on AWS. Prior to joining Stifel, Srini was a delivery specialist in cloud data analytics at AWS helping several customers in their transformational journey into AWS cloud. In his free time, Srini likes to explore cooking, travel and learn new trends and innovations in AI and cloud computing.
Hossein Johari is a seasoned data and analytics leader with over 25 years of experience architecting enterprise-scale platforms. As Lead and Senior Architect at Stifel Financial Corp. in St. Louis, Missouri, he spearheads initiatives in Data Platforms and Strategic Solutions, driving the design and implementation of innovative frameworks that support enterprise-wide analytics, strategic decision-making, and digital transformation. Known for aligning technical vision with business objectives, he works closely with cross-functional teams to deliver scalable, forward-looking solutions that advance organizational agility and performance.
Ahmad Rawashdeh is a Senior Architect at Stifel Financial. He supports Stifel and its clients in designing, implementing, and building scalable and reliable data architectures on Amazon Web Services (AWS), with a strong focus on data lake strategies, database services, and efficient data ingestion and transformation pipelines.
Lei Meng is a data architect at Stifel. His focus is working in designing and implementing scalable and secure data solutions on the AWS and helping Stifel’s cloud migration from on-premises systems.
Hello World 27 out now: Integrated computer science
Post Syndicated from Meg Wang original https://www.raspberrypi.org/blog/hello-world-27-out-now-integrated-computer-science/
While in some countries, such as England, computing is taught as a standalone subject, in others, like the USA, computing concepts are integrated across the school curriculum. In our brand-new issue of Hello World, out today for free, educators share ways to integrate computer science into your classroom.
Integrating CS to broaden participation
The argument for making computing and computer science (CS) standalone has often been about quality. We’ve heard educators say that teaching CS as part of other subjects can be hard, especially if you don’t have a CS background. On the other hand, integrating computer science into other subjects can offer a more accessible entry point for young people, broadening participation in CS education. And the critical thinking and problem-solving skills young people gain through computer science can enhance their learning of any subject.
As digital technology increasingly shapes our world, it may be that thoughtful cross-curricular CS education is the most effective way to empower all young people to become confident and critical technology users.
Issue 27 of Hello World features a range of practical articles with ideas for integrating CS over a variety of subjects at the primary, elementary, and high-school levels.
For example:
- James Abela shares how to teach coding across the curriculum using OctoStudio and the concepts of sequence, selection, and repetition
- Jesualdo Martínez Molina presents hands-on examples of weaving together cross-curricular and modern foreign languages in the primary classroom
- Jane Waite introduces the Autonomy framework, which explores whether we can effectively teach two things at once
Also in this issue:
- Laurie Gale introduces PRIMMDebug, a new way to teach debugging
- Teresa Harris Boag defines strategies for a whole-school approach to artificial intelligence (AI) to engage parents and school staff in developing an effective AI strategy
- Tiffany Jones shares how she ensures that students can see themselves in tech
And much, much more.
Jake Baskin, Executive Director of the Computer Science Teachers Association, says in this issue of Hello World: “If you’re a teacher who is implementing CS principles in your classroom, you are a computer science teacher.”
Whether CS is your specialist subject or not, Hello World is full of ideas from your fellow educators on how to inspire your students.
New podcast series
The Hello World podcast is also back, with a miniseries in audio and video focused on integrated CS. If you’re subscribed already, the three new episodes will show up in your favourite podcast app on Tuesdays.

Share your thoughts & subscribe to Hello World
We hope you enjoy this issue of Hello World. Please get in touch with your article ideas or what you would like to see in the magazine.
- Subscribe to Hello World for free to never miss a magazine issue
- Share your thoughts and ideas about Hello World and the new issue with us via the Raspberry Pi Foundation social media channels
- Find out how you can write for the magazine
The post Hello World 27 out now: Integrated computer science appeared first on Raspberry Pi Foundation.
Introducing simple and secure egress policies by hostname in Cloudflare’s SASE platform
Post Syndicated from Ankur Aggarwal original https://blog.cloudflare.com/egress-policies-by-hostname/
Cloudflare’s SASE platform is on a mission to strengthen our platform-wide support for hostname- and domain-based policies. This mission is being driven by enthusiastic demands from our customers, and boosted along the way by several interesting engineering challenges. Today, we’re taking a deep dive into the first milestone of this mission, which we recently released in open beta: egress policies by hostname, domain, content category, and application. Let’s dive right in!
Customers use our egress policies to control how their organization’s Internet traffic connects to external services. An egress policy allows a customer to control the source IP address their traffic uses, as well as the geographic location that their traffic uses to egress onto the public Internet. Control of the source IP address is especially useful when accessing external services that apply policies to traffic based on source IPs, using IP Access Control Lists (ACLs). Some services use IP ACLs because they improve security, while others use them because they are explicitly required by regulation or compliance frameworks.
(That said, it’s important to clarify that we do not recommend relying on IP ACLs as the only security mechanism used to gate access to a resource. Instead, IP ACLs should be used in combination with strong authentication like Single Sign On (SSO), Multi Factor Authentication (MFA), passkeys, etc.).
Let’s make the use case for egress policies more concrete with an example.
Imagine that Acme Co is a company that has purchased its own dedicated egress IP address 203.0.113.9 from Cloudflare. Meanwhile, imagine a regulated banking application (https://bank.example.com) that only grants access to the corporate account for Acme Co when traffic originates from source IP address 203.0.113.9. Any traffic with a different source IP will be prevented from accessing Acme Co’s corporate account. In this way, the banking application uses IP ACLs to ensure that only employees from Acme Co can access Acme Co’s corporate account.

Continuing our example, suppose that Acme Co wants to ensure that the banking application is off limits to all of its employees except those on its finance team. To accomplish this, Acme Co wants to write an egress policy that allows members of the finance team to egress from 203.0.113.9 when accessing https://bank.example.com, but employees outside of finance will not egress from 203.0.113.9 when attempting to access https://bank.example.com.
As shown in the figure above, the combination of the banking application’s IP ACLs and Acme Co’s egress policies ensures that https://bank.example.com is only accessible to its finance employees at Acme Co.
While this all sounds great, until now, this scenario was fairly difficult to achieve on Cloudflare’s SASE platform. While we have long supported egress policies by user groups and other user attributes, we did not support writing egress policies by hostname. Instead, customers had to resort to writing egress policies by destination IP addresses.
To understand why customers have been clamoring for egress policies by hostname, let’s return to our example:
In our example, Acme Co wants to write a policy that allows only the finance team to access https://bank.example.com. In the past, in the absence of egress policies by hostname, Acme Co would need to write its egress policy in terms of the destination IP address of the banking application.
But how does Acme Co know the destination IP address of this banking application? The first problem is that the destination IP address belongs to an external service that is not controlled by Acme Co, and the second problem is that this IP address could change frequently, especially if the banking application uses ephemeral infrastructure or sits behind a reverse proxy or CDN. Keeping up with changes to the destination IP address of an external service led some of our customers to write their own homegrown scripts that continuously update destination IP Lists which are then fed to our egress policies using Cloudflare’s API.
With this new feature, we do away with all these complications and simply allow our customers to write egress policies by hostname.
Before we continue, we should note that this new feature also supports writing egress policies by:
-
Domain: For example, we can now write an egress policy for
*.bank.example.com, rather than an individual policy for each hostname (bank.example.com,app.acmeco.bank.example.com,auth.bank.example.com, etc.) -
Category: For example, we can now write a single egress policy to control the egress IP address that employees use when accessing a site in the Cryptocurrency content category, rather than an individual policy for every Cryptocurrency website.
-
Application: For example, we can write a single egress policy for Slack, without needing to know all the different host and domain names (e.g.
app.slack.com,slack.com,acmeco.slack.com,slack-edge.com) that Slack uses to serve its application.
Here’s an example of writing an egress policy by application:

A view of the Cloudflare dashboard showing how to write an egress policy for a set of users and Applications. The policy is applied to users in the “finance” user group when accessing Applications including Microsoft Team, Slack, BambooHR and Progressive, and it determines the source IP that traffic uses when it egresses to the public Internet.
Now let’s get into the engineering challenges behind this feature.
Egress polices are part of Cloudflare Gateway. Cloudflare Gateway is a Secure Web Gateway (SWG) that operates as both a layer 4 (L4) and layer 7 (L7) proxy. In other words, Cloudflare Gateway intercepts traffic by inspecting it at the transport layer (layer 4, including TCP and UDP), as well as at the application layer (layer 7, including HTTP).
The problem is that egress policies must necessarily be evaluated at layer 4, rather than at layer 7. Why? Because egress policies are used to select the source IP address for network traffic, and Cloudflare Gateway must select the source IP address for traffic before it creates the connection to the external service bank.example.com. If Gateway changes the source IP address in the middle of the connection, the connection will be broken. Therefore, Gateway must apply egress policies before it sends the very first packet in the connection. For instance, Gateway must apply egress policies before it sends the TCP SYN, which of course happens well before it sends any layer 7 information (e.g. HTTP). (See here for more information on Gateway’s order of enforcement for its policies.)
The bottom line is that Gateway has no other information to use when applying the egress policy, other than the information in the IP header and the L4 (e.g. TCP) header of an IP packet. As you can see for the TCP/IPv4 packet below, a destination hostname is not part of the IP or TCP header in a packet. That’s why we previously were not able to support egress policies by hostname, and instead required administrators to write egress policies by destination IP address.

We took advantage of the fact that Cloudflare Gateway also operates its own DNS resolver. Every time an end user wants to access a destination hostname, the Gateway resolver first receives a DNS query for that hostname before sending its network traffic to the destination hostname.
To support egress policies by hostname, Gateway associates the DNS query for the hostname with the IP address and TCP/UDP information in the network connection to the hostname. Specifically, Gateway will map the destination IP address in the end-user’s network connection to the hostname in the DNS query using a “synthetic IP” mechanism that is best explained using a diagram:

Let’s walk through the flow:
1. When the end user makes a DNS query for bank.example.com, that DNS query is sent to the Gateway resolver.
2. The Gateway resolver does a public DNS lookup to associate bank.example.com to its destination IP address, which is 96.7.128.198.
3. However, the Gateway resolver will not respond to the DNS query using the real destination IP 96.7.128.198. Instead, it responds with an initial resolved IP address of 100.80.10.10. This is not the real IP address for bank.example.com; instead, it acts as a tag that allows Gateway to identify network traffic destined to bank.example.com. The initial resolved IP is randomly selected and temporarily assigned from one of the two IP address ranges below, which correspond to the Carrier Grade Network Address Translation (CGNAT) IP address spaces as defined in RFC 6598 and RFC 6264, respectively.
IPv4: 100.80.0.0/16
IPv6: 2606:4700:0cf1:4000::/64
4. Gateway has now associated the initial resolved IP address 100.80.10.10, with the hostname bank.example.com. Thus, when Gateway now sees network traffic to destination IP address 100.80.10.10, Gateway recognizes it and applies the egress policy for bank.example.com.
5. After applying the egress policy, Gateway will rewrite the initially resolved address IP 100.80.10.10, on the network traffic with the actual IP address 96.7.128.198 for bank.example.com, and send it out the egress IP address so that it can reach its destination.
The network traffic now has the correct destination IP address, and egresses according to the policy for bank.example.com, and all is well!
So far, we’ve seen how the mechanism works with individual hostnames (i.e. Fully Qualified Domain Names (FQDNs) like bank.example.com). What about egress policies for domains and subdomains like *.bank.example.com? What about content categories and applications, which are essentially sets of hostnames grouped together?
We are able to support these use cases because (returning to our example above) Gateway temporarily assigns the initial resolved IP address 100.80.10.10 to the hostname bank.example.com for a short period of time. After this short time period, the initial resolved IP address is released and returned into the pool of available addresses (in 100.80.0.0/16), where it can be assigned to another hostname in the future.
In other words, we use a random dynamic assignment of initial resolved IP addresses, rather than statically associating a single initial resolved IP address with a single hostname. The result is that we can apply IPv4 egress policies to a very large number of hostnames, rather than being limited by the 65,536 IP addresses available in the 100.80.0.0/16 IPv4 address block.
Randomly assigning the initial resolved IP address also means that we can apply a single egress policy for a wildcard like *.bank.example.com to any traffic we happen to come across, such as traffic for acmeco.bank.example.com or auth.bank.example.com. A static mapping would require the customer to write a different policy for each individual hostname, which is clunkier and more difficult to manage.
Thus, by using dynamic assignments of initial resolved IP addresses, we simplify our customers’ egress policies and all is well!
Actually, not quite. There’s one other problem we need to solve.
Cloudflare has an extensive global network, with servers running our software stack in over 330 cities in 125 countries. Our architecture is such that sharing strongly-consistent storage across those servers (even within a single data center) comes with some performance and reliability costs. For this reason, we decided to build this feature under the assumption that state could not be shared between any Cloudflare servers, even servers in the same data center.
This assumption created an interesting challenge for us. Let’s see why.
Returning to our running example, suppose that the end user’s DNS traffic lands on one Cloudflare server while the end user’s network traffic lands on a different Cloudflare server. Those servers do not share state. Thus, it’s not possible to associate the mapping from hostname to its actual destination IP address (bank.example.com = 96.7.128.198) which was obtained from the DNS traffic, with the initial resolved IP that is used by the network traffic (i.e. 100.80.10.10). Our mechanism would break down and traffic would be dropped, as shown in the figure below.

We solve this problem by ensuring that DNS traffic and network traffic land on the same Cloudflare server. In particular, we require DNS traffic to go into the same tunnel as network traffic so that both traffic flows land on the same Cloudflare server. For this reason, egress policies by hostname are only supported when end users connect to the Cloudflare network using one of the following on-ramps:
-
The WARP client (which we recently upgraded to send DNS traffic inside the WARP tunnel)
-
PAC files
-
Browser Isolation
We are actively working to expand support of this feature to more onramps.
There’s a lot more coming. Besides expanding support for more onramps, we also plan to extend this support to hostname-based rulesets in more parts of Cloudflare’s SASE. Stand by for more updates from us on this topic. All of these new features will rely on the “initial resolved IP” mechanism that we described above, empowering our customers to simplify their rulesets and enforce tighter security policies in their Cloudflare SASE deployments.
Don’t wait to gain granular control over your network traffic: log in to your Cloudflare dashboard to explore the beta release of egress policies by hostname / domain / category / application and bolster your security strategy with Cloudflare SASE.







