Post Syndicated from jzb original https://lwn.net/Articles/996337/
Timothée Ravier has written a
blog post about changes in the Fedora Atomic
Desktops for Fedora Linux 41. Some of the notable new
features for Atomic Desktops include bootloader updates enabled by
default for UEFI systems, first steps towards using bootable containers,
and more.
Post Syndicated from Donnie Prakoso original https://aws.amazon.com/blogs/aws/simplify-and-enhance-amazon-s3-static-website-hosting-with-aws-amplify/
We are announcing an integration between AWS Amplify Hosting and Amazon Simple Storage Service (Amazon S3). Now, you can deploy static websites with content stored in your S3 buckets and serve over a content delivery network (CDN) with just a few clicks.
AWS Amplify Hosting is a fully managed service for hosting static sites that handles various aspects of deploying a website. It gives you benefits such as custom domain configuration with SSL, redirects, custom headers, and deployment on a globally available CDN powered by Amazon CloudFront.
When deploying a static website, Amplify remembers the connection between your S3 bucket and deployed website, so you can easily update your website with a single click when you make changes to website content in your S3 bucket. Using AWS Amplify Hosting is the recommended approach for static website hosting because it offers more streamlined and faster deployment without extensive setup.
Here’s how the integration works starting from the Amazon S3 console:
Deploying a static website using the Amazon S3 console
Let’s use this new integration to host a personal website directly from my S3 bucket.
To get started, I navigate to my bucket in the Amazon S3 console . Here’s the list of all the content in that S3 bucket:
To use the new integration with AWS Amplify Hosting, I navigate to the Properties section, then I scroll down until I find Static website hosting and select Create Amplify app.
Then, it redirects me to the Amplify page and populates the details from my S3 bucket. Here, I configure my App name and the Branch name. Then, I select Save and deploy.
Within seconds, AWS Amplify has deployed my static website, and I can visit the site by selecting Visit deployed URL. If I make any subsequent changes in my S3 bucket for my static website, I need to redeploy my application in the Amplify console by selecting the Deploy updates button.
I can also use the AWS Command Line Interface (AWS CLI) for programmatic deployment. To do that, I need to get the values for required parameters, such as APP_ID and BRANCH_NAME from my AWS Amplify dashboard. Here’s the command I use for deployment:
aws amplify start-deployment --appId APP_ID --branchName BRANCH_NAME --sourceUrlType=BUCKET_PREFIX --sourceUrl s3://S3_BUCKET/S3_PREFIXAfter Amplify Hosting generates a URL for my website, I can optionally configure a custom domain for my static website. To do that, I navigate to my apps in AWS Amplify and select Custom domains in the navigation pane. Then, I select Add domain to start configuring a custom domain for my static website. Learn more about setting up custom domains in the Amplify Hosting User Guide.
In the following screenshot, I have my static website configured with my custom domain. Amplify also issues an SSL/TLS certificate for my domain so that all traffic is secured through HTTPS.
Now, I have my static site ready, and I can check it out at https://donnie.id.
Things you need to know
More available features – AWS Amplify Hosting has more features you can use for your static websites. Visit the AWS Amplify product page to learn more.
Deployment options – You can get started deploying a static website from Amazon S3 using the Amplify Hosting console, AWS CLI, or AWS SDKs.
Pricing – For pricing information, visit Amazon S3 pricing page and AWS Amplify pricing page.
Availability – Amplify Hosting integration with Amazon S3 is now available in AWS Regions where Amplify Hosting is available.
Start building your static website with this new integration. To learn more about Amazon S3 static website hosting with AWS Amplify, visit the AWS Amplify Hosting User Guide.
Happy building,
— Donnie
Post Syndicated from jzb original https://lwn.net/Articles/996332/
The Raspberry Pi project has announced
a new version of Raspberry Pi OS. It includes a number of
significant changes, the most notable of which is that the Raspberry
Pi Desktop now uses Wayland by default for all Pi models using the
labwc compositor:
For most of this year, we have been working on porting labwc to the
Raspberry Pi Desktop. This has very much been a collaborative process
with the developers of both labwc and wlroots: both have helped us
immensely with their support as we contribute features and
optimisations needed for our desktop.
This release also features Linux 6.6.51, improved touchscreen support, a new
screen configuration tool called raindrop, and more. See the
release
notes for a full list of changes.
Post Syndicated from jake original https://lwn.net/Articles/995383/
The kernel graphics driver for the Apple M1 and M2 GPUs is, rather
famously, written in Rust, but it has achieved conformance with
various graphics standards, which is also noteworthy. At the X.Org Developers Conference
(XDC) 2024, Alyssa Rosenzweig gave an update on the status of the
driver, along with some news about the kinds of games it can support (YouTube video, slides).
There has been lots of progress since her talk at XDC last year (YouTube video),
with, of course, still more to come.
Post Syndicated from jzb original https://lwn.net/Articles/996326/
The first stable release of the Thunderbird mail client for Android is now available:
Just over two years ago, we announced
our plans to bring Thunderbird to Android by taking K-9 Mail under
our wing. The journey took a little
longer than we had originally anticipated and there was a lot to
learn along the way, but the wait is finally over! For all of you who
have ever asked “when is Thunderbird for Android coming out?”, the
answer is – today!
It is immediately available on the Google
Play Store, via GitHub
Releases, or from the Thunderbird web site, and
it will be “coming soon
” to the F-Droid repository for FOSS Android
applications. See the release
notes for detailed information about Thunderbird 8.0 for
Android.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/10/simson-garfinkel-on-spooky-cryptographic-action-at-a-distance.html
Excellent read. One example:
Consider the case of basic public key cryptography, in which a person’s public and private key are created together in a single operation. These two keys are entangled, not with quantum physics, but with math.
When I create a virtual machine server in the Amazon cloud, I am prompted for an RSA public key that will be used to control access to the machine. Typically, I create the public and private keypair on my laptop and upload the public key to Amazon, which bakes my public key into the server’s administrator account. My laptop and that remove server are thus entangled, in that the only way to log into the server is using the key on my laptop. And because that administrator account can do anything to that server—read the sensitivity data, hack the web server to install malware on people who visit its web pages, or anything else I might care to do—the private key on my laptop represents a security risk for that server.
Here’s why it’s impossible to evaluate a server and know if it is secure: as long that private key exists on my laptop, that server has a vulnerability. But if I delete that private key, the vulnerability goes away. By deleting the data, I have removed a security risk from the server and its security has increased. This is true entanglement! And it is spooky: not a single bit has changed on the server, yet it is more secure.
Read it all.
Post Syndicated from jzb original https://lwn.net/Articles/996310/
Security updates have been issued by AlmaLinux (buildah), Debian (python-git, texlive-bin, and xorg-server), Mageia (chromium-browser-stable), Red Hat (kernel), SUSE (Botan, go1.22-openssl, go1.23-openssl, grafana, libgsf, pcp, pgadmin4, python310-pytest-html, python313, xorg-x11-server, and xwayland), and Ubuntu (nano, python-urllib3, and xorg-server, xwayland).
Post Syndicated from Jon Schipp original https://blog.rapid7.com/2024/10/30/the-importance-of-asset-context-in-attack-surface-management/
This is the last of the four blogs (Help, I can’t see! A Primer for Attack Surface Management Blog Series, The Main Components of an Attack Surface Management (ASM) Strategy, and Understanding your Attack Surface: Different Approaches to Asset Discovery) covering the foundational elements of Attack Surface Management (ASM), and this topic covers one of the main drivers for ASM and why companies are investing in it, the context it delivers to inform better security decision making.
ASM goes far beyond traditional IT asset visibility by bringing in the relevant security context that helps teams better prioritize and remediate. In general, the more context that you can make sense of, the more equipped your teams will be to make good decisions and drive toward action.
A clear example of this can be seen in an investigation of a machine under an active threat recorded by your SIEM or XDR solution. You likely have thousands of assets in your environment where the security team is unclear about the machine’s purpose. You now leverage context from your ASM solution to learn that the machine has access to several critical business networks and that it has a high-risk exposure on it related to an ongoing active threat. It’s just a matter of time before compromise and lateral movement. This augmented context during an investigation enables you to immediately make this the number one priority for your team.
Another key example involves identities. By inventorying all the identities across your environment, you can easily determine which ones have MFA disabled, and further filter based on those that have administrative access to a business application. To improve this identity context even further, you can pull in additional context from tools like KnowBe4 to understand how likely the user is to click on a phishing email based on their phishing training success rate. The marriage of identity data with security controls and business context helps teams better prioritize their most at-risk users for remediation.
Let’s look further at the key types of asset context that we believe are critical for effective ASM.
The first, and arguably most important, is the asset’s business context. This enables teams to understand the business function and risk, as well as the chain of command for contact or remediation. Visibility into the chain of command provides teams with the system owner, primary user, and which department and leader they fall under.
This business context is often pulled from CMDBs such as ServiceNow, Directory Services, HR tools like Workday, and by ingesting tags from CSP and security tool data sources. To effectively leverage business context, organizations need to develop and maintain an information architecture across the environment. Business context also helps identify which assets are a key dependency for business critical applications.
Understanding an asset’s vulnerabilities and exposures along with security control, mitigations, and business context is key to giving vulnerability teams the necessary means to make the best prioritization decisions. If a group of 100 machines all contain a Known Exploitable Vulnerability (KEV) that is being used in the wild by a specific piece of malware that is targeting your industry, your team may need to be up all night trying to remediate or mitigate this critical risk. But what if the majority of those same machines also have a security control or configuration in place that effectively causes that piece of malware to fail? Instead, your team can focus on a much smaller number within that group that lacks the required controls and focus on remediating those instead. Being able to harness all the available security context for assets enables teams to prioritize much more effectively.
Finally, threat context derived from SIEM, Threat Intelligence Platforms (TIP), and endpoint security tools enables security operations teams to gain insight into active threats and investigations when looking at an asset. It also enables teams to threat-hunt across all asset data, understand the blast radius from a compromised machine, and use threat insights to prioritize response. If you can identify all machines that have a specific vulnerability and are also seeing TTPs related to it, remediation activities for these machines can be prioritized.
A key factor in having confidence in security data and the context derived from it is having belief in the accuracy and integrity of the data itself. There are a few ways in which technology can help deliver that confidence. Because ASM is all about having visibility across your data and tooling silos, the final thing to consider is technology features related to an organization’s ability to analyze, troubleshoot, and configure data so that it matches your view of the attack surface. We can break this section into 3 main areas:
According to research from 451 Group, most security teams rely on between 11 and 30 different security tools to manage and secure their environments. Each of these tools only provides a partial view of the environment, and only from a particular perspective. As an example, Active Directory typically only sees Windows machines that are joined to the Domain Controller, DHCP only sees networked devices that have broadcasted and been given a lease, and CSPM tools only see cloud resources for Cloud Service Providers that have been configured.
Due to these visibility gaps, a holistic ASM solution must be able to see across these data silos and tools by ingesting and correlating data from many different sources, deduplicating it to deliver an accurate, continuously updated view of an organization’s asset landscape.
Data transparency is all about giving users the ability to understand where their data has come from, how well the data is being ingested, and how the data is populated within the data model. This also enables users to follow & configure correlation logic. It is critical that you trust the data of a solution that is intended to become the ‘single source of truth’ for security data in your organization, so we cannot emphasize enough the importance of having the right visibility into how data is used in an ASM solution.
For reference, I’m including several examples of how data transparency is a core capability of Rapid7’s Surface Command.
In the image below, we’re looking at the distribution of raw asset records to uniquely correlated assets in an organization. The system has received over 200,000 raw assets from many different data sources, and is able to narrow it down through its asset correlation algorithm to 63,179 unique assets.
The next example shows correlation effectiveness and property fulfillment (data fields with actual values) for Azure AD’s Device type. This capability is available on a per-connector basis and can be used to see how well the data source in question is correlating with other data sources (i.e., are they seeing the same assets?), and also how much of the data is being fulfilled by the API which can help pinpoint configuration issues that are limiting your view of your attack surface.
The final example is a table view of all the data sources coming into the system and key insights from them. This can be used to assess the quality of your data sources and to debug issues like when duplicate records occur. In that case, correlation rules can be updated to reduce those duplications so users get the best correlation, and thus the best and most accurate view of their attack surface.
This transparency into data ingestion and correlation is also critical when working with other stakeholders in the business, ensuring that everyone is in alignment on the most accurate data.
The final key aspect to successful ASM is being able to customize data in the way that an organization wants to see it. Teams rely on some tools more than others, and the weighting of those tools should match the overall preferences of the business. If Active Directory is your source of truth for ‘business owner’ and ‘department’ information over ServiceNow CMDB, then the system should be able to re-correlate the data based on the way an organization sees and utilizes the data.
Below, we show an example of how we are able to configure data prioritization in Rapid7’s Surface Command. Weighting the data can be configured on a per-property basis, so any ingestible and correlatable field can be customized to prioritize which tool should be preferred in the event of a data conflict. This enables teams to select and leverage the tools that they trust the most for specific data and use cases, so the attack surface matches the way they see their environment.
Over the past four blogs, I have tried to cover some of the key benefits and use cases for ASM. Much of it comes down to the core value that you can only protect what you know about, but in reality, it’s more complex than that.
The context that ASM solutions can provide you about both the external threat, and internal cyber risks, help security teams focus on what is most critical to protecting their organization. With the ever-growing number of vulnerabilities and non-patchable exposures, it just isn’t practical to expect to address everything, so prioritization is key. This is where the real value of ASM lies.
Once we understand our overall security posture, which assets are the most critical to the business, which services are the most exposed to attacks, we have the context needed to drive an effective cybersecurity program. We can take these insights and make them actionable, working with colleagues in DevOps and IT to harden machines and patch the most high-risk vulnerabilities. If we are successful in finding the gaps before the attacker, then we should also reduce the burden downstream on our SOC and IR teams.
I hope you found this blog series valuable. I’d encourage you to explore more information on Rapid7’s market-leading attack surface and exposure management solutions at https://www.rapid7.com/products/command/attack-surface-management-asm/.
Post Syndicated from Teresa Dodson original https://www.backblaze.com/blog/backblaze-partners-with-opti9-and-adds-canadian-data-region/
Backblaze and Opti9 are partnering up to bring Backblaze B2 Cloud Storage to joint customers around the world as well as businesses in Canada who are required to keep their data within national borders.
Opti9 is the international leader in hybrid cloud solutions that delivers managed cloud services, application development and modernization, backup and disaster recovery, security, and compliance solutions to businesses around the world. By bringing Backblaze into their solution set, Opti9 is onboarding high performance, low cost cloud storage that works within all the solutions they provide.
Increasingly, companies seeking managed services support are demanding solutions made up of best-in-breed providers. While traditional cloud platforms work against this principle of interoperability, Backblaze and solution providers like Opti9 are committed to delivering cloud solutions without the limitations, complexity, and high pricing that are holding businesses back.
As Jim Stechyson, the President of Opti9 put it:
Backblaze and Opti9 focus on empowering businesses with the best cloud solutions available. Being able to integrate the high performance and low total cost of ownership of Backblaze’s object storage into our set of solutions will greatly enhance our ability to drive success for our customers.
Interested resellers or customers who want to start working with Opti9 and Backblaze today can go to the Opti9 website. Check out our joint S3 compatible hot storage offering and book your demo to get started.
For customers based in Canada, Backblaze will be opening a new data region centered in Toronto in the first quarter of 2025. As part of the partnership, Opti9 will be the exclusive provider of server backup solutions in the Canadian channel for Backblaze B2 Reserve and the Powered by Backblaze program.
The new Canadian data region gives businesses the freedom to access Backblaze’s open, interoperable cloud solution, while still allowing customers to benefit from local storage and compliance. Located in Toronto, Ontario, the data center has been assessed and maintains a security program that addresses the requirements of SOC 1 Type 2, SOC 2 Type 2, ISO 27001, PCI DSS, and HIPAA. The region will be available to customers in the first quarter of 2025.
If you’d like to receive notifications about the data region opening date and when you can start storing data in Canada, you can sign up for the waitlist today.
The post Backblaze Partners with Opti9 and Adds Canadian Data Region appeared first on Backblaze Blog | Cloud Storage & Cloud Backup
Post Syndicated from Nyein Chan Zaw original https://blog.zabbix.com/monitoring-a-complex-infrastructure-environment-with-zabbix/28954/
Inviting the members of our global community to share their Zabbix dashboards with us prompted a flood of fascinating responses, and we’re highlighting a few of the most interesting submissions here on our blog. This week’s entry comes to us from Nyein Chan Zaw, who is based in Bangkok, Thailand and works as an Infrastructure Specialist for Green Will Solution. Read on to see how he uses his Zabbix dashboard to monitor a highly intricate infrastructure in real time.
I appreciate the chance to share my dashboard, and I would also like to share a use case that demonstrates the practical implementation of Zabbix for real-time infrastructure monitoring.
This Zabbix dashboard provides a comprehensive view of the network’s real-time health, server availability, traffic patterns, and key performance metrics of essential infrastructure components. It is designed for monitoring production, office, and virtual server zones, including network devices, physical servers, and virtual machines. The current view is the first page of a two-page dashboard, which focuses on general network monitoring:
The second page is dedicated solely to monitoring infrastructure nodes:
Traffic Monitoring: The dashboard tracks real-time traffic from critical network uplinks, including AIS and TRUE, offering visibility into bandwidth usage (e.g., 64.50 Kbps and 13.05 Kbps). It also monitors internal traffic and key devices like the FortiGate firewall, helping ensure optimal network performance and security.
Host Health Monitoring: CPU and memory utilization for top hosts (e.g., GW-WINDOW11, GW-AD-DOMAIN) are displayed, enabling efficient resource management. Alerts are triggered for high resource usage, allowing for a proactive response to performance issues.
Disk Usage: Disk space on key hosts, such as the Zabbix virtual machine and other core servers, is monitored to avoid file system over-utilization, which can lead to potential service interruptions.
Availability Overview: The dashboard provides a summary of host availability, including how many are available, unavailable, or have unknown statuses. Monitoring methods like active agent and SNMP are also shown, giving an overall view of network health.
Visual Topology Map: A detailed network map shows the production, office, virtual, and test zones, along with devices and connections. This visualization aids in quickly identifying problem areas and understanding how systems are interlinked.
Severity and Problem Monitoring: The dashboard classifies issues by severity, from critical problems to warnings. Real-time issues (such as VM downtime or system failures) are highlighted, enabling the team to resolve issues quickly.
Performance Metrics: Graphs display performance metrics, such as bandwidth usage and CPU load, offering insights into system bottlenecks or overuse, particularly in critical devices like firewalls.
This Zabbix dashboard enables an infrastructure team to efficiently monitor network performance, manage resource usage, and ensure device availability. The clear visual interface helps quickly identify issues, reducing downtime and ensuring higher reliability of critical services.
The first page of the dashboard demonstrates Zabbix’s capabilities for centralized monitoring across large infrastructures. By integrating data from network devices, servers, and virtual machines, it empowers IT teams to make informed decisions and address issues before they escalate. The second page provides a detailed focus on the infrastructure nodes, ensuring that all critical systems are effectively monitored for optimal operation across the IT environment.
The post Monitoring a Complex Infrastructure Environment with Zabbix appeared first on Zabbix Blog.
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=5L9npA9hYOo
Post Syndicated from Patrick Kennedy original https://www.servethehome.com/sth-youtube-750k-subscribers-sth-labs-10k/
In the last 36 hours the main STH YouTube channel hit 750K subscribers. STH Labs the shorts channel hit 10K, and STH was on Fox Business
The post STH YouTube at 750K Subscribers and STH Labs Passes 10K appeared first on ServeTheHome.
Post Syndicated from Светла Енчева original https://www.toest.bg/slabi-ambitsii-nepoznavane-na-izbiratelite-mizhav-rezultat/
Когато парламентарните избори са толкова начесто, колкото през последните години, човек претръпва. И все по-малко се стряска от резултатите – както от прогресиращото раздробяване на парламента (в който за малко не влязоха 9 партии и коалиции), така и от поредната популистка партия, почти неочаквано преминала 4-процентовата бариера (в случая – партията на Радостин Василев МЕЧ).
А не е да няма от какво да се стресне човек. Четири от деветте групи в новото Народно събрание („Възраждане“, БСП, ИТН и МЕЧ) са евроскептични и повече или по-малко проруски. Разделеното на две ДПС никога не се е славило с твърда геополитическа ориентация. Председателят на ГЕРБ нееднократно е показвал, че ако на някого не се харесват евроатлантическите му ценности, той има и други.
Така че алтернативите за съставяне на кабинет са няколко.
Първата е пореден нестабилен опит за проевропейско управление с участието на ГЕРБ и ПП–ДБ в коалиция било с ДПС – Доган, било с някоя от другите партии. След провала на кабинета на Николай Денков подобен опит от страна на ПП–ДБ трудно ще се прости от избирателите на коалицията. Още повече че няма основание да се очаква, че Пеевски няма и този път демонстративно да дърпа конците, независимо дали ДПС – Ново начало е формално в управлението, или не.
Втората алтернатива е ГЕРБ да се опита да състави правителство без ПП–ДБ. Това няма да е лесна задача, защото постигането ѝ включва още няколко партии и коалиции. На този етап Борисов изключва съвместно управление с „Възраждане“, а партията на Радостин Василев иска да участва в съставянето на мнозинство против ГЕРБ и ДПС.
Ако „Възраждане“ се опита да състави проруска коалиция без ГЕРБ и ПП–ДБ, в нея ще трябва да участва и ДПС – Ново начало, за да има тя мнозинство. А Костадин Костадинов едва ли би искал да получава публична подкрепа точно от Пеевски.
Вариант е и някаква форма на правителство на малцинството – със скрита подкрепа от страна на партии и коалиции, които уж са против, но когато се наложи, депутатите им услужливо не се регистрират за гласуване. Или гласуват предложенията на правителството, а после си намират оправдание.
И разбира се, отново може да не се състави редовно правителство, да имаме пореден служебен кабинет и поредни предсрочни избори.
Ако има някаква изненада в резултатите от вота, тя е в избирателната активност, която е по-висока, отколкото на предходното гласуване на 7 юни 2024 г., макар да се очакваше тенденцията за намаляване на броя на отишлите до урните да се запази. И все пак едва малко под 39% от имащите право на глас са го упражнили, а останалите 61% не са.
За ниската избирателна активност има ред предпоставки: твърде честите предсрочни избори, липсата на перспектива някоя от политическите сили да управлява самостоятелно, съответно – безпредметността на голяма част от предизборните обещания, които поради липсата на подкрепящо мнозинство не могат да бъдат изпълнени.
Всичко това обаче е вярно само при наличие на изходната предпоставка, че гласуват има-няма една трета от избирателите. Ако някоя партия или коалиция успее да намери път към негласуващите, политическата картина в България може да бъде коренно различна. Но по нищо не личи това да се прави. Напротив, гласуването се е ограничило до твърдите ядра. С изключение на нововъзникващите популистки партии и ДПС – Ново начало.
Когато не се поставят амбициозни цели и не се прави възможното те да се постигнат, а хоризонтът не стига много по-далече от носа, няма как да се очакват впечатляващи резултати.
Дори първата политическа сила – ГЕРБ – вече не си и поставя за цел да спечели повече от 50% от гласовете, за да може да управлява самостоятелно. Декларираната от партията цел, при чието постигане Бойко Борисов би станал отново премиер, беше едва 80 депутати – с 41 по-малко от необходимите за мнозинство. Друг е въпросът дали ГЕРБ изобщо иска да управлява самостоятелно.
ПП–ДБ от своя страна дори не дадоха заявка, че е възможно да спечелят изборите. Те се радват, че са на второ място, а не на трето или четвърто. Влязоха в кампанията с ясното убеждение, че няма да бъдат първи. И поставиха невъзможното за реализация условие да се избере равноотдалечен от всички партии премиер. А за тях не може да се каже, че не искат да управляват самостоятелно. Напротив – основният им проблем е, че няма други групи в парламента, които да споделят целите им.
Изобщо сещате ли се за послание от последната кампания, независимо на коя политическа сила, което да разбуни духовете? Да вдъхнови едни, да ядоса други, хората да говорят за него, да мотивира избиратели да отидат до урните? Сещате ли се за предложение – извън общото повишаване на доходите, – което да е насочено към представителите на определена социална група така, че да стигне до много от тях? Колко предложения за подобряване конкретно на вашия живот можете да изброите?
Докато в България се провеждат парламентарни избори, кандидатпрезидентската кампания в САЩ е в разгара си. Тамошният политическият пейзаж е различен от българския по ред причини.
Първо, политиката в Щатите е на практика двупартийна – не че не съществуват кандидати, които не са нито от републиканците, нито от демократите, но те нямат особени шансове. Второ, избирателната система е структурирана по коренно различен начин – от значение е не общият брой на гласувалите, а кой печели в отделните щати. Трето, самото общество и култура се отличават не само от българските, но и от европейските като цяло.
Като имаме предвид тези уточнения, политическите сили в България имат какво да научат от американските по отношение на провеждането на кампания. Особено предвид факта, че избирателната активност в САЩ през годините по-скоро нараства и е стигнала нива от около две трети от имащите право на глас.
На първо място, американските граждани не са тера инкогнита нито за политиците, нито за агенциите за изследване на общественото мнение (които никой в САЩ не нарича социологически). Избирателите са разделени в множество групи, всяка от които има определени типологични характеристики, ценности и интереси.
Няма просто жени например. Жените могат да бъдат млади или не, от предградията, от конкретен щат и населено място, с определена расова принадлежност, етнос, религия и пр. Или избирателите с латиноамерикански произход, които също не могат да се слагат под един знаменател. Имигрантите от Венесуела и Куба преобладаващо гласуват за републиканците, защото републиканците наричат демократите комунисти, а те точно от комунистите са избягали. На много чернокожи мъже пък им е трудно да гласуват за жена, била тя и чернокожа. И т.н., и т.н.
И демократите, и републиканците имат послания към определени групи и правят всичко по силите си тези послания да стигнат до своите адресати. В т.нар. колебаещи се щати буквално няколко гласа могат да бъдат решаващи за това кой ще стане следващият президент на САЩ. Затова кампаниите се опитват да стигнат до всеки.
Един от най-оспорваните щати е Пенсилвания. И макар евреите да са едва 2% от населението на страната, и републиканци, и демократи правят всичко по силите си да говорят с всеки евреин в щата и да спечелят гласа му.
И Доналд Тръмп, и Камала Харис се стараят да привличат максимален брой избиратели, макар и по различен начин. Тръмп избягва да излиза извън зоната си на комфорт и предпочита да се заобикаля с аудитория, която подкрепя – и усилва – посланията му. Харис от своя страна се опитва в максимална степен да компенсира факта, че избирателите не я познават добре, и не пропуска възможност да се представи – дори на територията на „вражеската“ телевизия Fox. Защото знае, че е в по-слаба позиция, и за да победи, трябва „да се вдигне за косата“.
Кандидат-президентката на демократите дори участва в телевизионна дискусия с избиратели, които още не са решили дали и за кого да гласуват. По време на дискусията ѝ се наложи да отговаря както на гласоподавателка, защитаваща палестинците, така и на еврейка, притеснена от антисемитизма в американските университети. И направи всичко по силите си отговорите ѝ да не отблъснат нито една от двете, колкото и трудно да изглежда това.
В България за избирателите обикновено се говори в много мъгляви категории, често натоварени с негативни конотации – „жълтопаветници“, „гербаджии“, „националисти“, „турци“, „роми“ и пр. Още по-мъгляво е възприемането на имащите право на глас като някакво единно цяло. То се изразява в твърдения, че българите са по дефиниция консервативни или пък че „не са готови“ за някоя по-либерална промяна.
Социологическите агенции правят по-детайлни разбивки на гласоподавателите – например по пол, възраст, населено място, образование, както и за кого са гласували на предишни избори. Но от техните анализи не следва особена промяна в поведението на политическите сили. Сякаш е природен факт, че едни гласуват така, други иначе, а повече от половината изобщо не гласуват.
Да вземем негласуващите. На последните избори най-малко са гласувалите в областите Сливен (28,78%), Кърджали (29,93%), Шумен (30,85%), Пловдив-окръг (31,71%). В София пък има значителна разлика между 23-ти МИР, където до урните са отишли най-голям дял избиратели спрямо цялата страна – 46,61%, и 24-ти МИР, в който бюлетина са пуснали едва 31,65%. Какви хора живеят на тези места? Какви са проблемите им? Защо около 70% от тях се чувстват непредставени?
Да се познават различни групи избиратели с техните ценности, интереси, страхове и надежди – без да се стига до типичната за САЩ детайлност – не е невъзможна задача. Не е нито твърде скъпо за джоба на парламентарно представените партии и коалиции, нито прекалено сложно да се направят количествени и качествени изследвания, чиито резултати да хвърлят светлина върху потенциалните гласоподаватели. И да се предложат решения за адекватни послания към тях.
Отказът да се опознаят избирателите стига до степен, в която те практически са все по-малко парламентарно представени. И макар по данни от 2023 г. над 60% от българските граждани да смятат, че демокрацията е най-добрата форма на управление, а към март 2024 г. около 60% категорично да подкрепят европейската ориентация на страната ни, рисковете за геополитически завой към Русия се увеличават.
Най-лесно е цялата отговорност да се прехвърля върху избирателите и те да бъдат обвинявани, че не гласуват, с което не само не си защитават интересите, а и увеличават тежестта на контролирания вот. По-трудно е да се намери път към тях, да се убеждават, да се предложат решения на проблемите им, да се дадат отговори на страховете им.
Трудно е, но е необходимо. Защото продължаването на поредицата от предсрочни избори не е най-лошото, което може да се случи. По-лошо ще е да се докараме до диктатура, в която изборите вече няма да имат съвсем никакво значение.
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=l0VTFTcLSvw
Post Syndicated from Grab Tech original https://engineering.grab.com/reduced-memory-cpu-usage-grabx-sdk
GrabX is Grab’s central platform for product configuration management. It has the capacity to control any component within Grab’s backend systems through configurations that are hosted directly on GrabX.
GrabX clients read these configurations through an SDK, which reads the configurations in a way that’s asynchronous and eventually consistent. As a result, it takes about a minute for any updates to the configurations to reach the client SDKs.
In this article, we discuss our analysis and the steps we took to reduce the peak memory and CPU usage of the SDK.
Our GrabX clients noticed that the GrabX SDK tended to require high memory and CPU usage. From this, we saw opportunities for further improvements that could:
At a high-level, creating, updating, and serving configuration values via the GrabX SDK involved the following process:
The GrabX backend ensures that the latest configuration data is available to client SDKs.
a. The GrabX backend checks every minute for any newly created or updated configurations.
b. If there are new or updated configurations, GrabX backend creates a new JSON file. This file contains all existing and newly created configurations. It’s important to note that all configurations across all services are stored in a single JSON file.
c. The backend module uploads this newly created JSON file to an AWS S3 bucket.
d. The backend module assigns a version number to the new JSON file and updates a text file in the AWS S3 bucket. This text file stores the latest JSON file version number. The client SDK refers to this version file to check if a newer version of the configuration data is available.
In this section we outline the areas of improvement we identified within the SDK design.
We saw an opportunity for service-based data partitioning. The configuration data for all services was consolidated into a single JSON file. Upon studying the data read patterns of client services, we observed that most services primarily needed to access configuration data specific to their own service. However, the present design required storing configuration data for all other services. This resulted in unnecessary memory consumption.
By using a single JSON file for storing old and new configuration data, we saw a significant increase in the size of the JSON file.
The SDK only needs the full data when it starts; the more common case is that it needs to stay updated with the latest configuration. Even in that scenario, the SDK needed to fetch a complete new JSON file every minute no matter the size of the updates. Consequently, the process of downloading, decoding, and loading high volumes of data at a high frequency (every minute) caused the client SDK to spike in memory and CPU usage.
An additional factor which contributed to memory and CPU usage during the decoding phase was the inefficiency of the default JSON decode library to decode this large (>100MB) JSON file. Decoding this JSON file was heavy on available CPU resources, which tended to starve the service of its ability to handle incoming requests. This manifested as increasing the P99 latency of the service.
We proposed modifications to the existing SDK design, which we discuss in this section.
The proposed solution involved partitioning the data based on services. We chose this approach because a single configuration typically belonged to a single service, and most services primarily needed to read configurations that pertained to their own service.
Upon analysing the distribution of service-configuration, we discovered that 98% of client services required less than 1% of the total configuration data. Despite this, they were required to maintain and reload 100% of the configuration data. Furthermore, the service with the largest number of configurations only required 20% of the total configuration data.
Therefore, we proposed a shift towards service-based partitioning of configuration data. This allowed individual client services to access only the data they needed to read.
Our proposal also included creating a separate JSON file for each configuration in a service. Previously, all data was stored in a single JSON file housed in an AWS S3 bucket, which supported a maximum of 3,500 write/update requests and 5,500 read requests per second.
By storing each configuration in a separate JSON file, we were able to create a different S3 prefix for each configuration file. These S3 prefixes helped us to maximise S3 throughput by enhancing the read/write performance for each configuration. AWS S3 can handle at least 3,500 PUT/COPY/POST/DELETE requests or 5,500 GET/HEAD requests per second for each partitioned Amazon S3 prefix.
Therefore, with each configuration’s data stored in a separate S3 file with a different prefix, the GrabX platform could achieve a throughput of 5,500 read requests and 3,500 write/update requests per second per configuration. This was beneficial for boosting read/write capacity when needed.
We proposed to create a changelog file at the service level. In other words, a changelog file was created for each service. This file was used to keep track of the latest update version, as well as previous service configuration update versions. This file also recorded the configurations which were created or updated in each version. This enables the SDK to accurately identify the configurations that were created or updated in each update version. This was useful to update the specific configurations belonging to a service on the client side.
We proposed that SDK client services should be allowed to subscribe to a list of services for which they need to read configuration data. The SDK was initialised with data of the subscribed services and received updates only for configurations corresponding to the subscribed services.
The SDK only sought updates for the subscribed services. The client SDK needed to read the changelog file for each of the subscribed services, comparing the latest changelog version against the SDK version number. Whenever a newer changelog version was available, the SDK updated the variables with the latest version.
This approach significantly reduced the volume of data that the SDK needed to download, decode, and load into memory during both initialisation and each subsequent update.
In summary, we identified ways to optimise CPU and memory usage in the GrabX SDK. Our analysis revealed that frequent high resource consumption hindered the wider adoption of GrabX. We proposed a series of modifications, including partitioning data by service and creating separate JSON files for each configuration.
After benchmarking the proposed solution with a variety of configuration data sizes, we found that the solution has the potential to reduce memory utilisation by up to 70% and decrease the maximum CPU utilisation by more than 50%. These improvements significantly enhance the performance and scalability of the GrabX SDK.
Moving forward, we plan to continue optimising the GrabX SDK by exploring additional improvements, such as reducing its initialisation time. These efforts aim to make GrabX an even more robust and reliable solution for product configuration management within Grab’s ecosystem.
Grab is the leading superapp platform in Southeast Asia, providing everyday services that matter to consumers. More than just a ride-hailing and food delivery app, Grab offers a wide range of on-demand services in the region, including mobility, food, package and grocery delivery services, mobile payments, and financial services across 700 cities in eight countries.
Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!
Post Syndicated from Explosm.net original https://explosm.net/comics/ghost-2
New Cyanide and Happiness Comic
Post Syndicated from xkcd.com original https://xkcd.com/3005/
Post Syndicated from Bryton Herdes original https://blog.cloudflare.com/cloudflare-perspective-of-the-october-30-2024-ovhcloud-outage
On October 30, 2024, cloud hosting provider OVHcloud (AS16276) suffered a brief but significant outage. According to their incident report, the problem started at 13:23 UTC, and was described simply as “An incident is in progress on our backbone infrastructure.” OVHcloud noted that the incident ended 17 minutes later, at 13:40 UTC. As a major global cloud hosting provider, some customers use OVHcloud as an origin for sites delivered by Cloudflare — if a given content asset is not in our cache for a customer’s site, we retrieve the asset from OVHcloud.
We observed traffic starting to drop at 13:21 UTC, just ahead of the reported start time. By 13:28 UTC, it was approximately 95% lower than pre-incident levels. Recovery appeared to start at 13:31 UTC, and by 13:40 UTC, the reported end time of the incident, it had reached approximately 50% of pre-incident levels.
Traffic from OVHcloud (AS16276) to Cloudflare
Cloudflare generally exchanges most of our traffic with OVHcloud over peering links. However, as shown below, peered traffic volume during the incident fell significantly. It appears that some small amount of traffic briefly began to flow over transit links from Cloudflare to OVHcloud due to sudden changes in which Cloudflare data centers we were receiving OVHcloud requests. (Peering is a direct connection between two network providers for the purpose of exchanging traffic. Transit is when one network pays an intermediary network to carry traffic to the destination network.)
Because we peer directly, we exchange most traffic over our private peering sessions with OVHcloud. Instead, we found OVHcloud routing to Cloudflare dropped entirely for a few minutes, then switched to just a single Internet Exchange port in Amsterdam, and finally normalized globally minutes later.
As the graphs below illustrate, we normally see the largest amount of traffic from OVHcloud in our Frankfurt and Paris data centers, as OVHcloud has large data center presences in these regions. However, in that shift to transit, and the shift to an Amsterdam Internet Exchange peering point, we saw a spike in traffic routed to our Amsterdam data center. We suspect the routing shifts are the earliest signs of either internal BGP reconvergence, or general network recovery within AS12676, starting with their presence nearest our Amsterdam peering point.
The postmortem published by OVHcloud noted that the incident was caused by “an issue in a network configuration mistakenly pushed by one of our peering partner[s]” and that “We immediately reconfigured our network routes to restore traffic.” One possible explanation for the backbone incident may be a BGP route leak by the mentioned peering partner, where OVHcloud could have accepted a full Internet table from the peer and therefore overwhelmed their network or the peering partner’s network with traffic, or caused unexpected internal BGP route updates within AS12676.
Upon investigating what route leak may have caused this incident impacting OVHcloud, we found evidence of a maximum prefix-limit threshold being breached on our peering with Worldstream (AS49981) in Amsterdam.
Oct 30 13:16:53 edge02.ams01 rpd[9669]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 141.101.65.53 (External AS 49981) changed state from Established to Idle (event PrefixLimitExceeded) (instance master)As the number of received prefixes exceeded the limits configured for our peering session with Worldstream, the BGP session automatically entered an idle state. This prevented the route leak from impacting Cloudflare’s network. In analyzing BGP Monitoring Protocol (BMP) data from AS49981 prior to the automatic session shutdown, we were able to confirm Worldstream was sending advertisements with AS paths that contained their upstream Tier 1 transit provider.
During this time, we also detected over 500,000 BGP announcements from AS49981, as Worldstream was announcing routes to many of their peers, visible on Cloudflare Radar.
Worldsteam later posted a notice on their status page, indicating that their network experienced a route leak, causing routes to be unintentionally advertised to all peers:
“Due to a configuration error on one of the core routers, all routes were briefly announced to all our peers. As a result, we pulled in more traffic than expected, leading to congestion on some paths. To address this, we temporarily shut down these BGP sessions to locate the issue and stabilize the network. We are sorry for the inconvenience.”
We believe Worldstream also leaked routes on an OVHcloud peering session in Amsterdam, which caused today’s impact.
Cloudflare has written about impactful route leaks before, and there are multiple methods available to prevent BGP route leaks from impacting your network. One is setting max prefix-limits for a peer, so the BGP session is automatically torn down when a peer sends more prefixes than they are expected to. Other forward-looking measures are Autonomous System Provider Authorization (ASPA) for BGP, where Resource Public Key Infrastructure (RPKI) helps protect a network from accepting BGP routes with an invalid AS path, or RFC9234, which prevents leaks by tying strict customer and provider relationships to BGP updates. For improved Internet resilience, we recommend that network operators follow recommendations defined within MANRS for Network Operators.
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=Kqg6WLcXQiw
Post Syndicated from Николай Марченко original https://bivol.bg/dps-peevski-fakti-bivol.html
Лидерът на “ДПС Ново начало” Делян Славчев Пеевски е станал причината за мобилизиране на много на брой екипи, съответно и големи разходи за сметка на бюджета, от страна на Министерството…