Post Syndicated from corbet original https://lwn.net/Articles/949294/
As of this writing, 9,842 non-merge changesets have found their way into
the mainline repository since the 6.7 merge window opened. Nearly a third
of those consist of the entire bcachefs development history but, even
discounting that, there has been a lot of material landing for the next
release. Read on for a summary of the most interesting changes pulled so
far in this development cycle.
Post Syndicated from jake original https://lwn.net/Articles/950061/
Security updates have been issued by Debian (phppgadmin and vlc), Fedora (attract-mode, chromium, and netconsd), Red Hat (.NET 7.0, c-ares, curl, ghostscript, insights-client, python, squid, and squid:4), SUSE (kernel and roundcubemail), and Ubuntu (libsndfile).
Post Syndicated from Kevin Low original https://aws.amazon.com/blogs/security/how-to-use-chaos-engineering-in-incident-response/
Simulations, tests, and game days are critical parts of preparing and verifying incident response processes. Customers often face challenges getting started and building their incident response function as the applications they build become increasingly complex. In this post, we will introduce the concept of chaos engineering and how you can use it to accelerate your incident response preparation and testing processes.
Chaos engineering is a formalized approach that uses fault injection experiments to create real-world conditions needed to understand how your system will react to unknowns and build confidence in the system’s resiliency and security.
Modern applications can have multiple components, including web, API, application, and data persistence layers. To respond to potential security events, you must understand the failure scenarios across each component and their downstream impacts. One challenge is that creating incident response processes and playbooks for components in a silo doesn’t consider known unknowns—how these components interact with each other—and can’t reveal unknown unknowns such as second-order effects during a security event.
As an example, consider the personalization microservice shown in Figure 1.
The microservice relies on two Amazon Elastic Compute Cloud (Amazon EC2) instances that are deployed in an auto scaling group across two Availability Zones. An upstream data collection microservice sends data for the personalization microservice to process. In addition, a downstream website microservice takes the personalized data and displays it to customers.
Figure 1: Architecture of the personalization microservice
Now imagine that unexpected activity occurred on an EC2 instance. The instance started to query a domain name that’s associated with cryptocurrency-related activity. A first set of unknowns already emerges:
Security professionals may not consider all of these questions when building and designing their threat detection and incident response capabilities.
In our example, Amazon GuardDuty is able to detect the unexpected activity and generates the CryptoCurrency:EC2/BitcoinTool.B!DNS finding within 15 minutes. The security team takes a snapshot for further forensics before the instance is isolated, as shown in Figure 2.
Figure 2: Architecture after GuardDuty detects unexpected activity and the security team isolates the EC2 instance
Although this might seem like an adequate response in isolation, it leads to more questions.
From a security perspective:
From an operational perspective:
Creating detection and incident response plans in isolation doesn’t consider the second order effects that could have an impact on the integrity and availability of the system.
Chaos engineering is a formalized process that can help solve this problem. It creates failure in a controlled environment with well-defined experiments to generate data on system behavior during a simulated event. You can use this data to improve incident response processes and make proactive changes that improve the security of your workloads. By using chaos engineering, developer and security teams can reveal additional unknowns and understand areas of opportunity to improve incident response processes and workload availability.
Chaos engineering has five phases—steady state, hypothesis, run experiment, verify, and improve—which we’ll discuss in more detail next.
The first phase involves an understanding of the behavior and configuration of the system under normal conditions. Instead of focusing on the internal attributes of the system, you should focus on an output metric or indicator that ties operational metrics and customer experience together. Including these output metrics in your hypothesis helps you collect data on security events and understand how these events and your response to them impact business outcomes.
Returning to our earlier example, this could be the latency when a user attempts to retrieve personalized information. This output is critical to the customer experience and relies on multiple operational metrics.
In addition, two key metrics in incident response are time to detect (TTD) and time to remediate (TTR). These metrics help capture how effectively your team has responded to the security event.
By defining your steady state, you can detect deviations from that state and determine if your system has fully returned to the known good state. You should identify the relevant metrics to measure your system and make these metrics simple for engineers to consume.
Using AWS, you can collect logs from the different services that you use in a workload, such as Amazon VPC Flow Logs, Amazon CloudWatch log groups, and AWS CloudTrail. For more details about the different log sources, see Logging strategies for security incident response.
After you understand the steady state behavior, you can write a hypothesis about it. Security hypotheses can take the following form:
When _________ happens, ________ system will notify the team within _______ and the application’s metric _________ will remain at ________.
It can be challenging to decide what should happen. Chaos engineering recommends that you choose real-world events that are likely to occur and that will impact the user experience. Get your team to brainstorm. For security issues, this is an ideal time to use your threat model as the starting point for discussions. Starting with one of your identified threats and then running experiments based on that threat can help you test both your processes and automation.
After you’ve chosen your component, decide which variable to influence or what could happen in your complex system. For example, a misconfigured Amazon Simple Storage Service (Amazon S3) bucket or an open database port could lead to unintended exposure of customer data. A software flaw in your application could lead to the misuse of resources by an unauthorized user.
Here are a few examples of hypotheses:
The next phase is to run the experiment. You don’t need to run experiments in production right away. A great place to get started with chaos engineering is the staging environment. One benefit of the AWS Cloud is that you can configure your staging environment to be identical to production. This increases the value of using an approach like chaos engineering before you get to production. By running experiments in staging, you can see how your system will likely react in production while earning trust within your organization.
As you gain confidence, you can begin running experiments in production. Because you configured staging to be identical to production, the risk of this transition is mitigated.
You can use AWS Fault Injection Simulator (FIS), our fully managed service for running fault injection experiments. FIS supports multiple fault injection actions, such as injecting API errors, restarting instances, running scripts on instances, disrupting network connectivity, and more. For the full list, see the FIS actions reference.
Although FIS doesn’t support security-related actions out of the box, you can use FIS to run AWS Systems Manager Automation documents that can run AWS APIs and scripts to simulate security events. To learn how to set up FIS to run a Systems Manager document that turns off bucket-level block public access for a randomly-selected S3 bucket, see the workshop Chaos Kitty – Gamifying Incident Response with Chaos Engineering. To learn how to set up FIS to run experiments that simulate events such as an RDP brute force event, lateral movement, cryptocurrency mining, and DNS data exfiltration, see the workshop Validating security guardrails with Chaos Engineering.
During this phase, you must understand the scope of impact of your experiment and work to minimize it. If an Amazon CloudWatch alarm goes into an alarm state, FIS can automatically stop the experiment. You should have a plan to return the environment to the steady state if the experiment has an unintended impact.
As you run your experiment, remember to document the key metrics and human responses, such as whether incident responders were confident, knew where to find the correct resources, or were aware of the escalation points.
The next step is to analyze and document the data to understand what happened. Lessons learned during the experiment are critical and should promote a culture of support instead of blame.
Here are some questions that you should address:
Here are a few examples of things you might learn from your chaos engineering experiments:
Use your learnings to improve the workload. It’s vital that you get leadership alignment and support to prioritize the remediation of findings from chaos experiments or other testing scenarios. Examples include improving incident response playbooks, creating new forms of automation, or creating preventative controls to prevent the event from happening. For more guidance on playbooks, see these sample incident response playbooks and the workshop Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake.
Preparation is important in incident response. As you improve your processes, run more experiments to collect additional data and continue to iteratively improve. Automate chaos experiments on new environments or applications with minimal user traffic before directing the majority of traffic to it. As you use chaos engineering approaches to prepare incident response processes, your detection and incident response capabilities should improve.
It’s vital to be prepared when a security event happens. In this blog post, you learned about the five phases of chaos engineering—steady state, hypothesis, design and run the experiment, learn and verify, and improve and fix—and how you can use them to accelerate your incident response preparation and testing processes. For more information on chaos engineering, see the following resources. Choose a workload and run an experiment on it to verify and improve your incident response processes today.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Want more AWS Security news? Follow us on Twitter.
Post Syndicated from LGR original https://www.youtube.com/watch?v=B_CN_5m7xqo
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=y9v887ht57E
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/11/new-york-increases-cybersecurity-rules-for-financial-companies.html
Another example of a large and influential state doing things the federal government won’t:
Boards of directors, or other senior committees, are charged with overseeing cybersecurity risk management, and must retain an appropriate level of expertise to understand cyber issues, the rules say. Directors must sign off on cybersecurity programs, and ensure that any security program has “sufficient resources” to function.
In a new addition, companies now face significant requirements related to ransom payments. Regulated firms must now report any payment made to hackers within 24 hours of that payment.
Post Syndicated from original https://www.toest.bg/za-suzidanieto-sa-nuzhni-idei-razruhata-ne-iziskva-plan/
Георги Гаврилов е роден на 15 юни 1991 г. в София. Следва специалност „Физика“ в СУ „Св. Климент Охридски“, а след това и магистратура „Физика на ядрото и елементарните частици“. Автор е на четири стихосбирки и множество публикации в електронното списание за литература „Кръстопът“, „Литературен вестник“, списанията „Море“,„Страница“, „Жената днес“, „Ах, Мария“, „Лик“ и др. Съставител е на сборника „Поезия срещу войната“ (Scribens, 2022), включващ в благотворителна инициатива текстове на 101 автори от България и чужбина в помощ на бежанците от Украйна. Стихове на Георги Гаврилов са преведени на турски, арабски, бенгалски, испански, френски, немски, английски и др. Георги е един от основателите на „Хралупата – пространство за литература и култура“ в София и част от издателство Scribens.
Докато вече привършвахме това интервю, настъпи израелският 9/11. На фона на апокалиптичната (в известен смисъл) поезия в най-новата ти книга как би коментирал последните събития от света?
Като нов стар очакван абсурд. Естествено, че нападението на „Хамас“ е военно престъпление, естествено, че е терористичен акт, естествено, че и за тях, и за всички е ясно, че действия от този род не са и няма как да бъдат от полза за някакъв положителен край на Палестинския въпрос. Напротив, ситуацията е доведена до състояние: едните трябва да изчезнат – като хора, като нация, като население. Не смятам, че каквото и да е от това може да бъде наречено свещено, оправдано и за доброто на света или на част от него. Последствията, както и причиняващият ги акт са във вреда на мира, човешкото и съхраняването на малкото останало от изчерпаемите ни психически сили. Още повече, не виждам никакво припокриване на идеалите на тези крайни религиозни фракции с мисленето на глобалния и конструктивен човек. Пътят към разрешаване на проблемите между Израел и Палестина може да е труден, но със сигурност не е този.
Да се върнем обаче на повода за този разговор – новата ти книга „Последният Буенос Айрес“ (изд. „Знаци“, 2023), която е своеобразен поетичен „Произход на видовете“, библейска и еволюционна история. Усещането обаче е, че се връщаме назад по стъпките на Сътворението, към апокалипсиса на първичния мрак, към последните мигове преди изригването на Помпей. Това ли се случва и как всъщност си представяш този апокалипсис?
Както и повечето неща, за които говорим през идеята за „събитие“, апокалипсисът не е събитие, а процес. Изучаваме историята чрез дати, часове и моменти, но това е единствено защото нямаме друга възможност за обхват на случилото се.
Войната в Украйна не започна на 24 февруари 2022 г. – тогава армията на Руската федерация навлезе в територията на Украйна; войната не започна и през 2014 г., когато незаконно беше анексиран Крим – това са само последните жалони от един дълъг път към настоящето. Можем да връщаме още и още назад и сигурно никога няма да е достатъчно рано, за да кажем, че днешното не е било възможно да се случи.
Вероятно по същия начин трябва да разсъждаваме за апокалипсиса: когато той бъде медийно обявен, няма да е изненада – той отдавна ще се е развивал, ще е придобивал образ. Това е засегнато в книгата като тема. Изкривената ни представа за тези големи „събития“ ни поставя в роля на очакващи нещо, което се случва междувременно и постепенно и ние вече сме част от него, предстои да разберем какъв магнитуд ще достигне.
Заглавието и имената на циклите в книгата ни дават много конкретна топография. Защо точно Буенос Айрес?
Шеговитият ми отговор би бил: „Защото звучи добре.“ Разбира се, не това е причината да се спра точно на този град. Историята на името му е обяснена посредством циклите. Градът е основан във времена на епидемии от малария (лош въздух), когато европейците са търсили нови места, които да населят и където въздухът да е чист. Връзката на блатата и застоялите водоеми с болестта е била миризмата, не комарите.
Буенос Айрес [на испански означава „хубав въздух“ или „добри ветрове“ – б.р.] е надежда за свободно дишане, за ново начало. Подобни места стават все по-малко. Конкретиката е ползвана в чисто художествен смисъл. Заглавието е метафора за нашето търсене на глътка въздух далеч от пандемии, войни и пълно капитулиране на междучовешките отношения.
Ако светът продължава „поради своята недостатъчност“, както пишеш, то тогава в какво би се състояло осъществяването му?
За природата той е във всеки момент съвършен, даже за Вселената. Ние живеем в моментната крайна точка на времето, което прави всичко в хармония с големите закони. За човека – обратно – осъществяването на света е винаги в следващата крачка.
Човекът изобретява идеята за бъдеще, за което Вселената няма понятие. Най-горещата година в историята, най-голямото земетресение, най-унищожителната атомна бомба, най-великите сред най-великите спортисти, писатели, държавници – тази гладиаторска надпревара, дори боравеща с понякога ужасяващи понятия, съблазнява съвременника да преживее нещо, което не фигурира в учебниците. Храним се с концепцията за феномен, който да осмисли поне статистически живота ни. Понякога този глад е надълбоко, срамен, прикрит, но го има в гена на човека. Само че всеки, който брои и измерва, е обречен, защото числата нямат край.
„създаден за седем дни/и разрушен за миг“. Убеден ли си, че разрушението винаги е много по-бързо и по-скоротечно от съзиданието?
Съзиданието винаги е по-трудно, енергоемко и неустойчиво от разрухата, която, затворена в собственото си осмисляне, не може да бъде съкрушена. Съзиданието няма право на грешна стъпка, разрухата няма грешна стъпка за себе си. Това е смисълът на тези редове; дори и протичайки като процес, разрушението се нуждае от един кълн, докато светът трябва неуморно да възобновява своите милиарди отделни крехки греди. Съзиданието започва от нищото, нужни са му идеи, концепции, проби, докато разрухата винаги работи с вече готовото и нейната задача не изисква план.
Какво ще пише на надгробния камък на нашето съвремие, на собственото ти поколение?
Надявам се, че още не знаем, защото това би значело, че сме приключили с работата, с дейността си; че стореното е достатъчно, а не мисля, че е така. Напротив – точно в тези години, до които сме се довели, е необходимо да забравим за покоя на надгробния камък, а нека следващото поколение ни даде своята оценка за щетите и постиженията. Освен това, ако мислим в такава посока, мислим в посока на самоувековечаване – първия и най-страшен признак на много предишни поколения, които очевидно са грешили в преценката си. По-важно ми изглежда преди това да видим надгробния паметник на диктатурите и на него да пише „Стига толкова“.
Как се постига вечност, как всъщност я разбираш?
Още едно понятие, изобретено от нас. В езика ни има доста такива, те нямат реални примери, нямат наблюдаеми дефиниции. Вечността е родена от нас, но не е наша и ако се постига, ще се постигне в наше отсъствие, наличието ни не може да доведе до трайност. В литературен смисъл вечността има друго предназначение, понякога можем частично да я изпитаме, като мостра на парфюм, но с условието, че този парфюм не е наличен по друг начин. За един ден стига, ароматът се задържа.
А как, по думите ти, се „пресолява рана“?
Солта в раната е болка. Пресолената манджа има вкус само на сол и на нищо друго от съставките си. Опитите да изстискаме максимално много мъка от нещо водят до обезчувствяване. Човекът е приспособимо същество и бързо свиква с нови „нули“ на толеранса си към едно или друго. Пресоляването на раната е промяна в тази „нула“, което всякога води до нуждата от по-големи дози от същото за постигане на същия ефект. Наблюдавахме го по време на пандемията от коронавирус, наблюдаваме го и по време на войната в Украйна. 10, 100, 1000 смъртни случая първия път стряскат, втория път стряскат по-малко, на десетия път са просто очакваната част от новинарската емисия.
Повтаря ли се, или се пренаписва историята? И ако мислим за нея литературно – графоман плагиат ли е човечеството?
Ако всички хора имаха едновременно усещането, че са част от човечеството, нищо от това нямаше да се случва. Само че нашата „мрежа“ е по-скоро съставена от пунктири, отколкото от непрекъснати нишки. „Невидимото“ човечество за всеки един индивид се превръща в абстракция, към която не може да се присъедини. Тогава самостоятелният живот приема функцията на стотици изминали поколения, без да е възприел непреживяното по друг начин, освен като мит. Ако съществуваше пълно препредаване на действителното отминало, мрежата може би щеше да бъде много по-добре свързана. Историята се рестартира с всяко новородено. Нямаме една история, имаме осем милиарда паралелни истории.
Какво е способно да отдели човека от грешките/греховете му?
Собственият му опит, страданието и любовта, образованието и семейната култура. Нищо не може да те застрахова срещу грешки или грехове, но много излишни трагедии биха били избегнати, ако в процеса на подрастване се наблегне на подобни човекооформящи теми. Семейната, училищната и университетската среда са от първостепенно значение. В това отношение ми се струва, че тоталитарните и диктаторските страни се възползват много повече от достъпа си до младежта, докато страни, които държат на демокрацията и свободата, неглижират (може би и от страх от изпадане в пропаганда) тези аспекти.
Имаш ред стихотворения за войната и насилието, като със сигурност поводът за тях идва именно от последния мащабен военен конфликт в Украйна…
Да. Огромна част от стихотворенията са написани в първите месеци след началото ѝ, с нетипична за мен честота. Почти всяка нощ пишех ново стихотворение. Така се събраха над 200 страници във файл, които впоследствие редуцирах и от които останаха включените в книгата. „Старите“ в нея са много малко.
Начинът, по който ми повлия тази война, беше с учудващ и за мен магнитуд. Смятам, че преживяваме особени години, които ще оформят среднодалечното бъдеще на света, и наследниците на днешния ден ще се връщат към тях дълго време. Такива периоди изискват участие и по примера от Втората световна война променят хода на много неща, включително на изкуството. Колкото и ужасно да звучи, то се мобилизира и се преоткрива най-добре по време на хуманитарни кризи и нечовешки събития, от което не бива да изпитваме задоволство, а просто да си свършим работата. Най-истинската е много черна.
„обесването на владимир владимирович путин“ е най-конкретният ти текст: стъпките към края на този съвременен кървав диктатор (един от всички други, които са споменати по-дискретно). Така ли – от собствената си ръка – приключват всички диктатори? Самотата ли е техният неизбежен край?
Самотата не е само краят им, самотата ги води към този край, който е напълно заслужен, и ако не бъдат съдени от по-висша от човешката инстанция, даже се разминават леко. Вова Путин вече виси на собствената си пъпна връв, обесен и отдавна приключен. Очевидно махалото на трупа му трябва да направи още няколко кръга, преди да бъде официално заменен от следващия противник на човешкото (в случай че властта не се смени коренно) или от някой, който може да изкара Русия от блатото, в което с известно самозадоволство се вкопава.
Душата на редовия путинист носи в себе си неуспешната болка, това е особен тип полудушевно състояние, което се опитва да достигне до болезненост, но от крайния резултат не може да извлече нито поука, нито позитив, нито градивен смисъл за така или иначе обмъглената представа за каквото и да било бъдеще, по-далечно от днес.
Стихотворението „мезозой“ е реплика на тринайсета глава от „Коринтяни“. Достоевски противопоставя абстрактната любов към „човечеството“ и хората въобще на тази към конкретния един ближен, която е много по-трудна и трудоемка… Ако оставим настрана интимността, способни ли сме днес на тази любов (питам и във връзка с раздвоените ни реакции към войната в Украйна и не само)?
Способни сме на същото, на което сме били и преди тази война, и преди този век, и преди каквото е в тефтерите ни. Както интимната, така и общочовешката любов са състояния – не можеш да поддържаш в пълен интензитет нито едно от двете. Шансът на човека е в това, че рядко трябва да се проявява като човек. Истинските работни часове са много малко в рамките на един секулум.
Ако „свободата ни не е спасение“, къде тогава го виждаш?
Свободата съблазнява по много начини, без да обещава нищо, освен своята абстрактна дашност. Няма как това да бъде крайната точка в търсенето на спасение. Не и в християнския смисъл. Интересно е, че със забързването на всички процеси в света и със забързването на самия свят, много подобни въпроси започват да получават повече моментен, отколкото окончателен отговор. Някак константата се превръща в променлива и вероятно това е, което трябва да срещне нашето поколение във философски план. Фрагментизиране на смисъла. Бърза храна, бърза любов, бързо спасение. Нощувка и после отново същото.
и може би всичко
вече е казано
но не
за последен път
Накратко, можем ли да приемем това като най-лаконичното определение за литературния двигател?
Да.
Ти самият си двигателят зад групата scribens/ARS, които издават едни от най-сериозните български гласове в поезията, докато твоите текстове излизат в друго издателство. Способен ли си да се отстраниш от самия себе си като поет, от собствената си стилистика, когато правиш подбор на новите ръкописи – или напротив, търсиш сродното, подобното?
Нямам проблем да се отстраня от собствената си поетика, за да оценя чуждата. Мисля, че „витрината“ ни го доказва и го доказва с всяка следваща публикувана книга. Аз самият имам четири книги с поезия и те са напълно различни една от друга, всеки път ми е интересно да търся нови подходи и концепции, мога да слушам бритпоп или рап, а в следващия момент – класическа музика. С поезията е същото.
3 сутринта е часът, който се споменава непрекъснато в книгата. Какво ще се случи тогава?
3 сутринта е символ на времето, когато не би трябвало нищо да се променя. Лично аз винаги съм го възприемал като момент, в който светът спи, хората спят – добри, лоши, всякакви, – просто спят, денят е свършил, новините са се изчерпали и няма нищо повече. Ето това изгубено спокойствие на 3 сутринта ми липсва от известно време насам. Вече нямаме „час на нищото“ и това е изнервящо.
Обичам да будувам в 3 сутринта, да пуша и да знам, че всички глупаци, всички изроди и нещастници хъркат в този момент, но също така и всички други обикновени и необикновени, великолепни и съвършени същества са се оттеглили за няколко часа в леглата си и няма нищо друго и никой друг, който да промени нещо, преди слънцето да поднови играта. Това обаче вече не съществува.
Post Syndicated from xkcd.com original https://xkcd.com/2850/
Post Syndicated from Technology Connextras original https://www.youtube.com/watch?v=HQtwULiTEmo
Post Syndicated from Patrick Kennedy original https://www.servethehome.com/touring-the-intel-ai-playground-inside-the-intel-developer-cloud/
We tour Intel’s AI playground as we get inside the Intel Developer Cloud’s Oregon location to show hardware being made available to developers
The post Touring the Intel AI Playground – Inside the Intel Developer Cloud appeared first on ServeTheHome.
Post Syndicated from Edward Sun original https://aws.amazon.com/blogs/security/approaches-for-migrating-users-to-amazon-cognito-user-pools/
Update: An earlier version of this post was published on September 14, 2017, on the Front-End Web and Mobile Blog.
Amazon Cognito user pools offer a fully managed OpenID Connect (OIDC) identity provider so you can quickly add authentication and control access to your mobile app or web application. User pools scale to millions of users and add layers of additional features for security, identity federation, app integration, and customization of the user experience. Amazon Cognito is available in regions around the globe, processing over 100 billion authentications each month. You can take advantage of security features when using user pools in Cognito, such as email and phone number verification, multi-factor authentication, and advanced security features, such as compromised credentials detection, and adaptive authentications.
Many customers ask about the best way to migrate their existing users to Amazon Cognito user pools. In this blog post, we describe several different recommended approaches and provide step-by-step instructions on how to implement them.
The main consideration when migrating users across identity providers is maintaining a consistent end-user experience. Ideally, users can continue to use their existing passwords so that their experience is seamless. However, security best practices dictate that passwords should never be stored directly as cleartext in a user store. Instead, passwords are used to compute cryptographic hashes and verifiers that can later be used to verify submitted passwords. This means that you cannot securely export passwords in cleartext form from an existing user store and import them into a Cognito user pool. You might ask your users to choose a new password during the migration. Or, if you want to retain the existing passwords, you need to retain access to the existing hashes and verifiers, at least during the migration period.
A secondary consideration is the migration timeline. For example, do you need a faster migration timeline because your current identity store’s license is expiring? Or do you prefer a slow and steady migration because you are modernizing your current application, and it takes time to connect your existing systems to the new identity provider?
The following two methods define our recommended approaches for migrating existing users into a user pool:
In the following sections, we describe the bulk user import and just-in-time user migration methods in more detail and then walk through the steps of each approach.
You perform bulk import of users into an Amazon Cognito user pool by uploading a .csv file that contains user profile data, including usernames, email addresses, phone numbers, and other attributes. You can download a template .csv file for your user pool from Cognito, with a user schema structured in the template header.
Following is an example of performing bulk user import.
To create an import job
Figure 1: Create import job
Figure 2: Configure import job
Depending on the size of the .csv file, the job can run for minutes or hours, and you can follow the status from that same page in the Amazon Cognito console.
Figure 3: Check import job status
Cognito runs through the import job and imports users with a RESET_REQUIRED state. When users attempt to sign in, Cognito will return PasswordResetRequiredException from the sign-in API, and the app should direct the user into the ForgotPassword flow.
Figure 4: View imported user
The bulk import approach can also be used continuously to incrementally import users. You can set up an Extract-Transform-Load (ETL) batch job process to extract incremental changes to your existing user directories, such as the new sign-ups on the existing systems before you switch over to a Cognito user pool. Your batch job will transform the changes into a .csv file to map user attribute schemas, and load the .csv file as a Cognito import job through the CreateUserImportJob CLI or SDK operation. Then start the import job through the StartUserImportJob CLI or SDK operation. For more information, see Importing users into user pools in the Amazon Cognito Developer Guide.
The just-in-time (JIT) user migration method involves first attempting to sign in the user through the Amazon Cognito user pool. Then, if the user doesn’t exist in the Cognito user pool, Cognito calls your Migrate User Lambda trigger and sends the username and password to the Lambda trigger to sign the user in through the existing user store. If successful, the Migrate User Lambda trigger will also fetch user attributes and return them to Cognito. Then Cognito silently creates the user in the user pool with user attributes, as well as salts and password verifiers from the user-provided password. With the Migrate User Lambda trigger, your client app can start to use the Cognito user pool to sign in users who have already been migrated, and continue migrating users who are signing in for the first time towards the user pool. This just-in-time migration approach helps to create a seamless authentication experience for your users.
Cognito, by default, uses the USER_SRP_AUTH authentication flow with the Secure Remote Password (SRP) protocol. This flow doesn’t involve sending the password across the network, but rather allows the client to exchange a cryptographic proof with the Cognito service to prove the client’s knowledge of the password. For JIT user migration, Cognito needs to verify the username and password against the existing user store. Therefore, you need to enable a different Cognito authentication flow. You can choose to use either the USER_PASSWORD_AUTH flow for client-side authentication or the ADMIN_USER_PASSWORD_AUTH flow for server-side authentication. This will allow the password to be sent to Cognito over an encrypted TLS connection, and allow Cognito to pass the information to the Lambda function to perform user authentication against the original user store.
This JIT approach might not be compatible with existing identity providers that have multi-factor authentication (MFA) enabled, because the Lambda function cannot support multiple rounds of challenges. If the existing identity provider requires MFA, you might consider the alternative JIT migration approach discussed later in this blog post.
Figure 5 illustrates the steps for the JIT sign-in flow. The mobile or web app first tries to sign in the user in the user pool. If the user isn’t already in the user pool, Cognito handles user authentication and invokes the Migrate User Lambda trigger to migrate the user. This flow keeps the logic in the app simple and allows the app to use the Amazon Cognito SDK to sign in users in the standard way. The migration logic takes place in the Lambda function in the backend.
Figure 5: JIT migration user authentication flow
The flow in Figure 5 starts in the mobile or web app, which attempts to sign in the user by using the AWS SDK. If the user doesn’t exist in the user pool, the migration attempt starts. Cognito calls the Migrate User Lambda trigger with triggerSource set to UserMigration_Authentication, and passes the user’s username and password in the request in order to attempt to migrate the user.
This approach also works in the forgot password flow shown in Figure 6, where the user has forgotten their password and hasn’t been migrated yet. In this case, once the user makes a “Forgot Password” request, your mobile or web app will send a forgot password request to Cognito. Cognito invokes your Migrate User Lambda trigger with triggerSource set to UserMigration_ForgotPassword, and passes the username in the request in order to attempt user lookup, migrate the user profile, and facilitate the password reset process.
Figure 6: JIT migration forgot password flow
In this section, we show sample source codes for a Migrate User Lambda trigger overall structure. We will fill in the commented sections with additional code, shown later in the section. When you set up your own Lambda function, configure a Lambda execution role to grant permissions for CloudWatch logs.
const handler = async (event) => {
if (event.triggerSource == "UserMigration_Authentication") {
//***********************************************************************
// Attempt to sign in the user or verify the password with existing identity store
// (shown in the Section A – Migrate User of this post)
//***********************************************************************
}
else if (event.triggerSource == "UserMigration_ForgotPassword") {
//***********************************************************************
// Attempt to look up the user in your existing identity store
// (shown in the section B – Forget Password of this post)
//***********************************************************************
}
return event;
};
export { handler };In the migration flow, the Lambda trigger will sign in the user and verify the user’s password in the existing user store. That may involve a sign-in attempt against your existing user store or a check of the password against a stored hash. You need to customize this step based on your existing setup. You can also create a function to fetch user attributes that you want to migrate. If your existing user store conforms to the OIDC specification, you can parse the ID Token claims to retrieve the user’s attributes. The following example shows how to set the username and attributes for the migrated user.
// Section A – Migrate User
if (event.triggerSource == "UserMigration_Authentication") {
// Attempt to sign in the user or verify the password with the existing user store.
// Add an authenticateUser() functionbased on your existing user store setup.
const user = await authenticateUser(event.userName, event.request.password);
if (user) {
// Migrating user attributes from the source user store. You can migrate additional attributes as needed.
event.response.userAttributes = {
// Setting username and email address
username: event.userName,
email: user.emailAddress,
email_verified: "true",
};
// Setting user status to CONFIRMED to autoconfirm users so they can sign in to the user pool
event.response.finalUserStatus = "CONFIRMED";
// Setting messageAction to SUPPRESS to decline to send the welcome message that Cognito usually sends to new users
event.response.messageAction = "SUPPRESS";
}
}The user is now migrated from the existing user store to the user pool, as well as the user’s attributes. Users will also be redirected to your application with the authorization code or JSON Web Tokens, depending on the OAuth 2.0 grant types you configured in the user pool.
Let’s look at the forgot password flow. Your Lambda function calls the existing user store and migrates other attributes in the user’s profile first, and then Lambda sets user attributes in the response to the Cognito user pool. Cognito initiates the ForgotPassword flow and sends a confirmation code to the user to confirm the password reset process. The user needs to have a verified email address or phone number migrated from the existing user store to receive the forgot password confirmation code. The following sample code demonstrates how to complete the ForgotPassword flow.
// Section B – Forgot Password
else if (event.triggerSource == "UserMigration_ForgotPassword") {
// Look up the user in your existing user store service.
// Add a lookupUser() function based on your existing user store setup.
const lookupResult = await lookupUser(event.userName);
if (lookupResult) {
// Setting user attributes from the source user store
event.response.userAttributes = {
username: event.userName,
// Required to set verified communication to receive password recovery code
email: lookupResult.emailAddress,
email_verified: "true",
};
event.response.finalUserStatus = "RESET_REQUIRED";
event.response.messageAction = "SUPPRESS";
}
}Using the Migrate User Lambda trigger, we showed the JIT migration approach where the app switches to use the Cognito user pool at the beginning of the migration period, to interface with the user for signing in and migrating them from the existing user store. An alternative JIT approach is to maintain the existing systems and user store, but to silently create each user in the Cognito user pool in a backend process as users sign in, then switch over to use Cognito after enough users have been migrated.
Figure 7: JIT migration alternative approach with backend process
Figure 7 shows this alternative approach in depth. When an end user signs in successfully in your mobile or web app, the backend migration process is initiated. This backend process first calls the Cognito admin API operation, AdminCreateUser, to create users and map user attributes in the destination user pool. The user will be created with a temporary password and be placed in FORCE_CHANGE_PASSWORD status. If you capture the user password during the sign-in process, you can also migrate the password by setting it permanently for the newly created user in the Cognito user pool using the AdminSetUserPassword API operation. This operation will also set the user status to CONFIRMED to allow the user to sign in to Cognito using the existing password.
Following is a code example for the AdminCreateUser function using the AWS SDK for JavaScript.
var params = {
MessageAction: "SUPPRESS",
UserAttributes: [{
Name: "name",
Value: "Nikki Wolf"
},
{
Name: "email",
Value: "[email protected]"
},
{
Name: "email_verified",
Value: "True"
}
],
UserPoolId: "us-east-1_EXAMPLE",
Username: "nikki_wolf"
};
const cognito = new CognitoIdentityProviderClient();
const createUserCommand = new AdminCreateUserCommand(params);
await cognito.send (createUserCommand);The following is a code example for the AdminSetUserPassword function.
var params = {
UserPoolId: 'us-east-1_EXAMPLE' ,
Username: 'nikki_wolf' ,
Password: 'ExamplePassword1$' ,
Permanent: true
};
const cognito = new CognitoIdentityProviderClient();
const setUserPasswordCommand = new AdminSetUserPasswordCommand(params);
await cognito.send(setUserPasswordCommand);This alternative approach does not require the app to update its authentication codebase until a majority of users are migrated, but you need to propagate user attribute changes and new user signups from the existing systems to Cognito. If you are capturing and migrating passwords, you should also build a similar logic to capture password changes in existing systems and set the new password in the user pool to keep it synchronized until you perform a full switchover from the existing identity store to the Cognito user pool.
In this post, we described our two recommended approaches for migrating users into an Amazon Cognito user pool. You can decide which approach is best suited for your use case. The bulk method is simpler to implement, but it doesn’t preserve user passwords like the just-in-time migration does. The just-in-time migration is transparent to users and mitigates the potential attrition of users that can occur when users need to reset their passwords.
You could also consider a hybrid approach, where you first apply JIT migration as users are actively signing in to your app, and perform bulk import for the remaining less-active users. This hybrid approach helps provide a good experience for your active user communities, while being able to decommission existing user stores in a manageable timeline because you don’t need to wait for every user to sign in and be migrated through JIT migration.
We hope you can use these explanations and code samples to set up the most suitable approach for your migration project.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Want more AWS Security news? Follow us on Twitter.
Post Syndicated from Benjamin Smith original https://aws.amazon.com/blogs/compute/orchestrating-dependent-file-uploads-with-aws-step-functions/
This post is written by Nelson Assis, Enterprise Support Lead, Serverless and Jevon Liburd, Technical Account Manager, Serverless
Amazon S3 is an object storage service that many customers use for file storage. With the use of Amazon S3 Event Notifications or Amazon EventBridge customers can create workloads with event-driven architecture (EDA). This architecture responds to events produced when changes occur to objects in S3 buckets.
EDA involves asynchronous communication between system components. This serves to decouple the components allowing each component to be autonomous.
Some scenarios may introduce coupling in the architecture due to dependency between events. This blog post presents a common example of this coupling and how it can be handled using AWS Step Functions.
In this example, an organization has two distributed autonomous teams, the Sales team and the Warehouse team. Each team is responsible for uploading a monthly data file to an S3 bucket so it can be processed.
The files generate events when they are uploaded, initiating downstream processes. The processing of the Warehouse file cleans the data and joins it with data from the Shipping team. The processing of the Sales file correlates the data with the combined Warehouse and Shipping data. This enables analysts to perform forecasting and gain other insights.
For this correlation to happen, the Warehouse file must be processed before the Sales file. As the two teams are autonomous, there is no coordination among the teams. This means that the files can be uploaded at any time with no assurance that the Warehouse file is processed before the Sales file.
For scenarios like these, the Aggregator pattern can be used. The pattern collects and stores the events, and triggers a new event based on the combined events. In the described scenario, the combined events are the processed Warehouse file and the uploaded Sales file.
The requirements of the aggregator pattern are:
The architecture uses the following AWS services:
You need the following prerequisites:
To deploy the example, follow the instructions in the GitHub repo.
This walkthrough shows what happens if the dependent file (Sales file) is uploaded before the independent one (Warehouse file).
{
"detail-type": ["Object Created"],
"source": ["aws.s3"],
"detail": {
"bucket": {
"name": ["sales-mfu-eda-09092023", "warehouse-mfu-eda-09092023"]
},
"reason": ["PutObject"]
}
}
When the status of the Warehouse file is changed to “Completed”, the Warehouse state machine checks DynamoDB for a pending Sales file. If there is one, it retrieves the task token and calls the SendTaskSuccess method. This triggers the Sales state machine, which is in a waiting state to continue. The Sales state machine is started and the processing status is updated.
This blog post shows how to handle file dependencies in event driven architectures. You can customize the sample provided in the code repository for your own use case.
This solution is specific to file dependencies in event driven architectures. For more information on solving event dependencies and aggregators read the blog post: Moving to event-driven architectures with serverless event aggregators.
To learn more about event driven architectures, visit the event driven architecture section on Serverless Land.
Post Syndicated from Йоанна Елми original https://www.toest.bg/ima-li-pravo-palestina-na-literatura/
„Литпром“: диалог през литературата“, четем на едноименния сайт на германската асоциация на професионалисти в сферата на издателския бизнес, журналистиката, литературните науки и критиката.
Следващо съобщение, малко по-долу:
Поради войната, започната от „Хамас“, причинила страдание на милиони израелци и палестинци, организаторът „Литпром“ реши да отмени церемонията по връчване на наградата „ЛиБературпрайс“ […]
Носителката на въпросната награда? Адания Шибли, палестинска писателка, чиято дискусия в рамките на Франкфуртския панаир на книгата също бе отменена („Литпром“ се финансира частично от германското правителство, Франкфуртския панаир на книгата и други организации).
Първото прессъобщение на „Литпром“ от 13 октомври гласеше, че авторката сама е изявила желание събитията да не се състоят. Но по-късно Шибли отрече и заяви, че ако възможността ѝ е била предоставена, е щяла да се възползва и да инициира разговор за ролята на литературата във време на жестокости и болка. Следват протестни писма от издателите на Шибли в САЩ и Великобритания, както и отворено писмо срещу решението, подписано от над 350 писатели, редактори, литературни агенти и издатели, сред които нобелистите Абдулразак Гурна, Ани Ерно и Олга Токарчук, авторите Колм Тойбин, Олга Равн и други.
For the entirety of Frankfurt @Book_Fair, we've made the eBook of Adania Shibli's MINOR DETAIL, tr. Elisabeth Jaquette, free to download: https://t.co/eD0dL6bx1e
Amazon: https://t.co/t6UVnHJXFP
Apple: https://t.co/r09qEM6lXS
Kobo: https://t.co/iZyTdbV0fq— Fitzcarraldo Editions (@FitzcarraldoEds) October 17, 2023
След отмяната на събитията британският издател на Адания Шибли предостави книгата за свободно теглене в рамките на дните на Франкфуртския панаир
„Същият панаир, който отмени церемонията на Шибли, беше критикуван за включването на крайнодясното издателство Antaios, както и за гостуването на членове на „Алтернатива за Германия“ (AfD), написа в есе босненската писателка Лана Басташич.
Докато артисти и писатели биват заглушавани заради предполагаем антисемитизъм, истинският неонацизъм се завръща с крайнодесните AfD, които печелят местни избори, a опитни политици обмислят варианти за сделки с тях.
Разговор за ролята на литературата и конфликта между Израел и Палестина нямаше. Но се появиха задължителните лагери „за“ и „против“, безпочвени обвинения в антисемитизъм, истински антисемитизъм, също толкова истинска омраза към палестинците… Решението на Франкфуртския панаир е още по-интересно в контекста на провелия се преди шест месеца Книжен панаир в Лайпциг, на който голямата награда получи руската писателка Мария Степанова (украинската общност, а и други протестираха това решение). Никой не сметна за нужно да „търси други формати“ за награждаването на Степанова, която не живее в Русия, но пише на руски и е рускиня. Необходима ли е отмяната на Шибли? И какви глобални тенденции биха могли да обяснят това решение?
Родена в Палестина през 1974 г., Шибли живее между Йерусалим и Берлин, говори шест езика и е авторка на романи, пиеси, разкази и есета. Преподава философия и културология в Бирзейтския университет в Палестина.
Награденият ѝ в Германия роман Minor Detail („Незначителен детайл“*) не е преведен на български. Действието в него се развива през лятото на 1949-та, година след т.нар. Накба, или Палестинската катастрофа, когато са унищожени около 500 палестински села, а над 700 000 палестинци са принудени да напуснат домовете си. Катастрофата е следствие от сложни събития в контекста на Плана на ООН за разделяне на териториите на Палестина.
„Незначителен детайл“ се основава на истински случай – историята на млада бедуинка, изнасилена от израелски военни. Читателят прекарва няколко горещи дни през 1949 г. с войниците, които „прочистват“ пустинята от арабите. Другата сюжетна линия е в настоящето, където героиня на име Рамала търси исторически сведения за престъплението. Чрез двете линии пред читателя се разкрива абсурдният свят на болка без начало и край, без смисъл, неизбежна. Всъщност болката е такава, каквато е и в живия живот.
Адания Шибли не е маргинален глас, не е пропагандаторка, не поддържа терористи. Във Великобритания романът ѝ се издава от независимото издателство „Фицкаралдо“, чиито автори печелят Нобеловата награда вече няколко поредни години. През 2020 г. книгата е финалист за престижната американска Национална литературна награда, а през 2021 г. е в дългия списък за Международния „Букър“. Получава признание от критиците на New York Review of Books, Guardian, New York Times, Words Without Borders и редица други издания.
Друг роман на Шибли разглежда събитията по време на Гражданската война в Ливан, свързани с убийствата на палестински бежанци и ливански шиити в Сабра и Шатила. Действието се развива през 1982 г. в Бейрут, тогава окупиран от Израел. Книгата We Are All Equally Far from Love („Всички сме еднакво далеч от любовта“) пък изследва ограниченията на живота под окупация, физическата и психическата клаустрофобия, емоционалната парализа. „Когато човек живее на място, което му се струва като наказание за неизвършено престъпление, от много ранна възраст започва да си задава трудни въпроси относно простички идеи като справедливост – или нейното отсъствие“, казва Шибли пред LitHub.
Спомням си как два пъти ме разпитваха членове на израелското разузнаване, които искаха да знаят за какво пиша. Когато казах, че са истории за нещастна любов, те изгубиха всякакъв интерес към мен.
Франкфуртският панаир на книгата е най-големият панаир по брой представени издатели. Смятан е за най-важният книжен панаир в света. Не е преувеличено да се каже, че това е литературен макет на света. Тази година „Литпром“ дава наградата на Шибли заради „безкомпромисно написаната ѝ творба, която разказва за силата на границите и за онова, което жестоките конфликти причиняват и правят с хората“. След 7 октомври обаче Израел, Палестина и светът осъмнаха различни. Адания Шибли ли е виновна за това? Справедливо ли е „наказанието“ нейният глас да бъде погълнат от взривовете на бомбите на „Хамас“ и Израел?
„Добрата литература ни показва сложността на живота, който не може да влезе в тесни идеологически рамки, било то леви или десни. И обратното – слабата литература следва идеологически схеми и не се различава особено от манифест“, коментира случая за „Тоест“ писателят и журналист Димитър Кенаров.
Точно тук е и трагедията в днешно време – може би в което и да било време. Хората, които мислят по-сложно за живота (независимо дали се занимават с писане, или с нещо друго), не са особено популярни.
В есето си „Крахът“ от февруари 1936 г. Франсис Скот Фицджералд пише, че „проверка за един първокласен ум е умението едновременно да държиш в съзнанието си две противостоящи идеи и въпреки това да не изгубиш способността си да действаш“ (превод от английски Рада Шарланджиева). Всъщност „Крахът“ се занимава с разпадите – както големите исторически, така и вътрешните разпади. Двата процеса, разбира се, са взаимносвързани.
А XXI в. е време на разпади: разпадат се обществата ни, демокрациите ни, способността ни да общуваме; пандемията разби на пух и прах увереността, че сме победили смъртта и че можем да предскажем бъдещето; разпадна се и идеята, че Студената война или която и да е война има еднозначен край… Разпада се и планетата. Какво друго във време на разпади, ако не литература, тоест разговор, съпреживяване? Пълната противоположност, разбира се – война.
„Циничното възползване от ужасите, причинени от насилието на „Хамас“, за да се обявят всички палестински гласове за нелегитимни, е част от кампания за ограничаване на пространството за емпатия, мисъл, дебат и истина“, коментира журналистката Урсула Линдзи, покриваща теми, свързани с Близкия изток, в свое есе за Washington Post. Но тенденцията за „отмяна“ на литературата не принадлежи на Франкфурт. Тя е естествен рефлекс, придобит след поне десетилетие публична реактивност.
В книгата си Professing Criticism: Essays on the Organization of Literary Study („Професия критик: есета върху организацията на литературната наука“) Джон Гилъри, американски литературен критик и професор в Нюйоркския университет, разглежда идеологическите борби и културните войни около литературния канон – например кои автори трябва да се четат и кои да се забранят, защото например от определена гледна точка са расисти, евгеници и т.н.
В западните метрополиси борбата за многообразие в учебния план се оказа много по-лесна от реалното осигуряване на многообразие сред учениците и още по-лесна от налагането на многообразие в университетските среди и администрации. Западната „висока култура“ стана лесната битка на движението за деколонизация.
Изливаме гнева си от неспособността да поправим несправедливостите и неравенствата в настоящето върху мъртвите автори, разсъждава Гилъри. Но ако литературата (на миналото), която не отговаря на нечии морални стандарти в настоящето, наистина бъде премахната, спряна от изучаване, забранена, заглушена – нима това няма да доведе до изкривена представа за историята, а оттам и за реалността? Не би ли се случило същото и с изтриването на палестинските, руските гласове? Не на онези, които насърчават насилието (тук не става въпрос за пропаганда, а за литература), а които изговарят травмите, довели до него, и то отвътре?
„Тези, които проблематизират черно-белите идеологически модели (свобода–робство, цивилизация–варварство, Европа–Азия, Украйна–Русия, Израел–Палестина), се оказват в доста сложна ситуация. Никой не обича сложните неща“, смята и Кенаров.
Към тази сложност се стреми Гилъри, който пише:
Искаме студентите ни да се интересуват от другостта, включително от хора, които са различни от тях, но и нещо повече – искаме да се интересуват от цели светове другост и непреодолими различия.
В американската среда, която влияе върху целия западен свят, амбицията на Гилъри и амбивалентността на Фицджералд са подложени на изпитание. Трудно е да се мисли сложно в свят на политика на идентичностите, където човек не е изграден от истории, а е еднолинеен сюжет, който се развива или не според определени критерии. И който може да бъде прекъснат, редактиран и дори изтрит от публичното пространство. Подобни тенденции се наблюдават както в левия, така и в десния политически спектър.
Това не е експертен анализ по въпроса Израел–Палестина. Социалните мрежи превръщат привилиегированите да живеят далеч от света на жестоките конфликти, в които реална смърт застига истински хора, в кризисни запалянковци, заемащи една или друга страна, викащи за една или друга смърт, понякога единствено в името на това да бъдат чути гласовете им. Про- или антиваксър? Консервативен или либерален? Комунист или фашист? Русофил или русофоб? Кой заслужава да умре повече – палестинец или израелец? Страшно е, когато светът се преживява в бинарности. Страшно е и другото – когато изберем моралния релативизъм: в него няма зло, което да заслужава осъждане.
Това е текст за литературата, която – когато е добра – помага да преодолеем всичко: политиката, хюбриса, пропагандата, говорещите глави, социалните мрежи и първосигналното, мненията, фоновия шум… За да се върнем към съществените, съвсем реални проблеми. Към човешкото. Защото ако сме способни да зачеркнем цели групи хора (а и тяхната литература, техния разговор), вече сме загубили частица от човечността си. Така се продължава и цикълът на жестокост. Литературата остава сред редките антидоти срещу тези отрови, както казва Милан Кундера.
Романът е пространство, в което моралното порицание временно се отменя. Тази отмяна не означава, че на романa му липсва морал; именно тя е неговата моралност. Моралността, която застава срещу неизкоренимия човешки навик да съдим светкавично, непрестанно и всички; да съдим, преди да сме разбрали, както и в отсъствието на разбиране. От гледната точка на мъдростта на романа тази трескава готовност да се съди е най-омразната глупост, най-гибелното зло. Не че романистът изцяло отрича, че моралната присъда е легитимна. Той просто отказва да я постави в романа.
А че романът на Шибли е литература, която приканва към разговор, доказват множеството международни признания. Включително от хората, които „отмениха“ писателката. Именно заради тази отмяна, заради страха от нещо неопределено, нямахме шанс да чуем разговора за Израел–Палестина през литературата. Но предстоят няколко участия на Шибли, които може би ще ни дадат другите истории на Палестина – не на терора и вендетата; не на западняците, за които това е поредната криза, която ще преживеят в риалити формата на социалните мрежи и с която ще смажат стрелките на моралния си компас в съответните посоки, разбира се, на всеослушание; а на хората, които живеят тази история. Които са направени от тази история. Които единствени могат да я разкажат. И единствени имат силата да я променят.
Независимо дали авторите избират да говорят за определени събития, или да стоят встрани от тях, добрата литература се занимава с много просто нещо: животът (човешки, но не само) като основна ценност, казва Димитър Кенаров. „Литературата може да бъде всякаква, дори в най-ужасните моменти от историята. Важното е изкуството да бъде смело и свободно, независимо какъв подход или тема ще избере. Адорно казва, че не може да има поезия след Аушвиц, но всъщност поезия е имало и ще има винаги.“
В интервю за New York Times, публикувано ден преди завършването на този текст, израелският писател Едгар Керет каза някои от нещата, които изредихме и тук: за бинарния свят, за хляба и зрелищата, за болката, която е захапала опашката си.
Преди доста време написах есе за New York Times, в което казах, че не харесвам етикетите „про-Израел“ или „про-Палестина“ […] Тоест ако си „про-Израел“, значи си за бомбардирането на деца в Газа? Идеята ми е, че реалността е сложна, и за мен най-важна е отговорността към човека. Когато виждам как хората гледат ужасната трагедия, разиграваща се тук, все едно е надпревара кой ще излезе по-голяма жертва, в която подкрепяш единия отбор и не ти пука за другия, емпатията става много, много избирателна. Виждаш само едната болка. Отказваш да видиш другата.
Превърнала ли се е реалността в арената на Колизея? А социалните мрежи – в скамейките, от които осъждаме чуждите борби и решаваме кой е достоен да говори, да живее и кой не? Отменянето на легитимни гласове не разплита възлите в реалността, дори напротив. Защото в тази реалност хората не са аватари – те кървят, умират, губят близки, мразят и убиват съвсем наистина. Когато откажем да проведем трудния разговор, оставаме само с насилието. Защото времената на криза не търпят вакуум. Думи винаги трябват. Въпросът е кой говори. На кого позволяваме? От чие име? А как слушаме? От това зависи най-малкото дали ще останем хора.
*Всички преводи в текста са на авторката Йоанна Елми, освен там, където е изрично посочено друго.
Post Syndicated from Talks at Google original https://www.youtube.com/watch?v=lDUDUjoK3SA
Post Syndicated from BeardedTinker original https://www.youtube.com/watch?v=ywPGzyZg9JU
Post Syndicated from Mukul Sharma original https://aws.amazon.com/blogs/big-data/godaddy-benchmarking-results-in-up-to-24-better-price-performance-for-their-spark-workloads-with-aws-graviton2-on-amazon-emr-serverless/
This is a guest post co-written with Mukul Sharma, Software Development Engineer, and Ozcan IIikhan, Director of Engineering from GoDaddy.
GoDaddy empowers everyday entrepreneurs by providing all the help and tools to succeed online. With more than 22 million customers worldwide, GoDaddy is the place people come to name their ideas, build a professional website, attract customers, and manage their work.
GoDaddy is a data-driven company, and getting meaningful insights from data helps us drive business decisions to delight our customers. At GoDaddy, we embarked on a journey to uncover the efficiency promises of AWS Graviton2 on Amazon EMR Serverless as part of our long-term vision for cost-effective intelligent computing.
In this post, we share the methodology and results of our benchmarking exercise comparing the cost-effectiveness of EMR Serverless on the arm64 (Graviton2) architecture against the traditional x86_64 architecture. EMR Serverless on Graviton2 demonstrated an advantage in cost-effectiveness, resulting in significant savings in total run costs. We achieved 23.85% improvement in price-performance for sample production Spark workloads—an outcome that holds tremendous potential for businesses striving to maximize their computing efficiency.
GoDaddy’s intelligent compute platform envisions simplification of compute operations for all personas, without limiting power users, to ensure out-of-box cost and performance optimization for data and ML workloads. As a part of this vision, GoDaddy’s Data & ML Platform team plans to use EMR Serverless as one of the compute solutions under the hood.
The following diagram shows a high-level illustration of the intelligent compute platform vision.
EMR Serverless is a serverless option in Amazon EMR that eliminates the complexities of configuring, managing, and scaling clusters when running big data frameworks like Apache Spark and Apache Hive. With EMR Serverless, businesses can enjoy numerous benefits, including cost-effectiveness, faster provisioning, simplified developer experience, and improved resilience to Availability Zone failures.
At GoDaddy, we embarked on a comprehensive study to benchmark EMR Serverless using real production workflows at GoDaddy. The purpose of the study was to evaluate the performance and efficiency of EMR Serverless and develop a well-informed adoption plan. The results of the study have been extremely promising, showcasing the potential of EMR Serverless for our workloads.
Having achieved compelling results in favor of EMR Serverless for our workloads, our attention turned to evaluating the utilization of the Graviton2 (arm64) architecture on EMR Serverless. In this post, we focus on comparing the performance of Graviton2 (arm64) with the x86_64 architecture on EMR Serverless. By conducting this apples-to-apples comparative analysis, we aim to gain valuable insights into the benefits and considerations of using Graviton2 for our big data workloads.
By using EMR Serverless and exploring the performance of Graviton2, GoDaddy aims to optimize their big data workflows and make informed decisions regarding the most suitable architecture for their specific needs. The combination of EMR Serverless and Graviton2 presents an exciting opportunity to enhance the data processing capabilities and drive efficiency in our operations.
The Graviton2 processors are specifically designed by AWS, utilizing powerful 64-bit Arm Neoverse cores. This custom-built architecture provides a remarkable boost in price-performance for various cloud workloads.
In terms of cost, Graviton2 offers an appealing advantage. As indicated in the following table, the pricing for Graviton2 is 20% lower compared to the x86 architecture option.
| x86_64 | arm64 (Graviton2) | |
| per vCPU per hour | $0.052624 | $0.042094 |
| per GB per hour | $0.0057785 | $0.004628 |
| per storage GB per hour* | $0.000111 | |
*Ephemeral storage: 20 GB of ephemeral storage is available for all workers by default—you pay only for any additional storage that you configure per worker.
For specific pricing details and current information, refer to Amazon EMR pricing.
The AWS team performed benchmark tests on Spark workloads with Graviton2 on EMR Serverless using the TPC-DS 3 TB scale performance benchmarks. The summary of their analysis are as follows:
These findings highlight the significant benefits of using Graviton2 on EMR Serverless for Spark workloads, with improved performance and cost-efficiency. It showcases the potential of Graviton2 in delivering enhanced price-performance ratios, making it an attractive choice for organizations seeking to optimize their big data workloads.
During our initial experimentation, we observed that arm64 on EMR Serverless consistently outperformed or performed on par with x86_64. One of the jobs showed a 7.51% increase in resource usage on arm64 compared to x86_64, but due to the lower price of arm64, it still resulted in a 13.48% cost reduction. In another instance, we achieved an impressive 43.7% reduction in run cost, attributed to both the lower price and reduced resource utilization. Overall, our initial tests indicated that arm64 on EMR Serverless delivered superior price-performance compared to x86_64. These promising findings motivated us to conduct a more comprehensive and rigorous study.
To gain a deeper understanding of the value of Graviton2 on EMR Serverless, we conducted our study using real-life production workloads from GoDaddy, which are scheduled to run at a daily cadence. Without any exceptions, EMR Serverless on arm64 (Graviton2) is significantly more cost-effective compared to the same jobs run on EMR Serverless on the x86_64 architecture. In fact, we recorded an impressive 23.85% improvement in price-performance across the sample GoDaddy jobs using Graviton2.
Like the AWS benchmarks, we observed slight regressions of less than 5% in the total runtime of some jobs. However, given that these jobs will be migrated from Amazon EMR on EC2 to EMR Serverless, the overall total runtime will still be shorter due to the minimal provisioning time in EMR Serverless. Additionally, across all jobs, we observed an average speed up of 2.1% in addition to the cost savings achieved.
These benchmarking results provide compelling evidence of the value and effectiveness of Graviton2 on EMR Serverless. The combination of improved price-performance, shorter runtimes, and overall cost savings makes Graviton2 a highly attractive option for optimizing big data workloads.
As an extension of a larger benchmarking EMR Serverless for GoDaddy study, where we divided Spark jobs into brackets based on total runtime (quick-run, medium-run, long-run), we measured effect of architecture (arm64 vs. x86_64) on total cost and total runtime. All other parameters were kept the same to achieve an apples-to-apples comparison.
The team followed these steps:
The following table shows the summary of an example Spark job.
| Metric | EMR Serverless (Average) – X86_64 | EMR Serverless (Average) – Graviton | X86_64 vs Graviton (% Difference) |
| Total Run Cost | $2.76 | $1.85 | 32.97% |
|
Total Runtime (hh:mm:ss) |
00:41:31 | 00:34:32 | 16.82% |
| EMR Release Label | emr-6.9.0 | ||
| Job Type | Spark | ||
| Spark Version | Spark 3.3.0 | ||
| Hadoop Distribution | Amazon 3.3.3 | ||
| Hive/HCatalog Version | Hive 3.1.3, HCatalog 3.1.3 | ||
The following table presents a comparison of job performance between EMR Serverless on arm64 (Graviton2) and EMR Serverless on x86_64. For each architecture, every job was run at least three times to obtain the accurate average cost and runtime.
| Job | Average x86_64 Cost | Average arm64 Cost | Average x86_64 Runtime (hh:mm:ss) | Average arm64 Runtime (hh:mm:ss) | Average Cost Savings % | Average Performance Gain % |
| 1 | $1.64 | $1.25 | 00:08:43 | 00:09:01 | 23.89% | -3.24% |
| 2 | $10.00 | $8.69 | 00:27:55 | 00:28:25 | 13.07% | -1.79% |
| 3 | $29.66 | $24.15 | 00:50:49 | 00:53:17 | 18.56% | -4.85% |
| 4 | $34.42 | $25.80 | 01:20:02 | 01:24:54 | 25.04% | -6.08% |
| 5 | $2.76 | $1.85 | 00:41:31 | 00:34:32 | 32.97% | 16.82% |
| 6 | $34.07 | $24.00 | 00:57:58 | 00:51:09 | 29.57% | 11.76% |
| Average | 23.85% | 2.10% | ||||
Note that the improvement calculations are based on higher-precision results for more accuracy.
Based on this study, GoDaddy observed a significant 23.85% improvement in price-performance for sample production Spark jobs utilizing the arm64 architecture compared to the x86_64 architecture. These compelling results have led us to strongly recommend internal teams to use arm64 (Graviton2) on EMR Serverless, except in cases where there are compatibility issues with third-party packages and libraries. By adopting an arm64 architecture, organizations can achieve enhanced cost-effectiveness and performance for their workloads, contributing to more efficient data processing and analytics.
Mukul Sharma is a Software Development Engineer on Data & Analytics (DnA) organization at GoDaddy. He is a polyglot programmer with experience in a wide array of technologies to rapidly deliver scalable solutions. He enjoys singing karaoke, playing various board games, and working on personal programming projects in his spare time.
Ozcan Ilikhan is a Director of Engineering on Data & Analytics (DnA) organization at GoDaddy. He is passionate about solving customer problems and increasing efficiency using data and ML/AI. In his spare time, he loves reading, hiking, gardening, and working on DIY projects.
Harsh Vardhan Singh Gaur is an AWS Solutions Architect, specializing in analytics. He has over 6 years of experience working in the field of big data and data science. He is passionate about helping customers adopt best practices and discover insights from their data.
Ramesh Kumar Venkatraman is a Senior Solutions Architect at AWS who is passionate about containers and databases. He works with AWS customers to design, deploy, and manage their AWS workloads and architectures. In his spare time, he loves to play with his two kids and follows cricket.
Post Syndicated from corbet original https://lwn.net/Articles/949277/
One of the core objectives of any confidential-computing implementation is
to protect a guest system’s memory from access by actors outside of the
guest itself. The host computer and hypervisor are part of the group that
is to be excluded from such access; indeed, they are often seen as
threat in their own right. Hardware vendors have added features like memory
encryption to make memory inaccessible to the host, but such features can
be difficult to use and are not available on all CPUs, so there is ongoing
interest in software-only solutions that can improve confidentiality. The
guest-first
memory patch set, posted by Sean Christopherson and containing work by
several developers, looks poised to bring some software-based protection to
an upcoming kernel release.
Post Syndicated from corbet original https://lwn.net/Articles/949833/
Julia Evans has posted a list of
confusing Git terms and behavior along with explanations of what is
actually going on.
“Your branch is up to date with ‘origin/main’”
This message seems straightforward – it’s saying that your main branch is
up to date with the origin!But it’s actually a little misleading. You might think that this means that
your main branch is up to date. It doesn’t. What it actually means is – if
you last ran git fetch or git pull 5 days ago, then your main branch is up
to date with all the changes as of 5 days ago.So if you don’t realize that, it can give you a false sense of security.
Post Syndicated from corbet original https://lwn.net/Articles/949831/
Home
Assistant 2023.11 is available. New features include a to-do list
manager, Matter
1.2 support, customizable tile cards, new integrations, and more. (LWN
looked at Home Assistant last month).
Post Syndicated from jake original https://lwn.net/Articles/949829/
The GNU awk text-processing utility, gawk has released version
5.3.0. The main new features add compatibility with “The One True Awk” (also known
as “BWK awk”); version 5.3.0 adds CSV (comma-separated values) parsing and
the ability to use \u escape sequences for Unicode code points.
Read on for other changes in the release.
