Вече имаме програма (която може да се види и в pretalx). Има забавни неща за всички, или поне се надявам – три пъти удължавахме срока за подаване на предложения 🙂
За тази година имаме малко по-различна система за запазване на тениски – заедно с init Lab (така де, то е тяхна инициатива) правим online магазин за merchandise на всякакви добри хора, като хакерспейсове, отворени събития и т.н.. За момента сме пуснали само запазването, но финалната цел е да си работи като истински магазин, с плащания и т.н..
(също така, има още малко време ако някой желае да доброволства или да спонсорира, пишете ми 🙂 )
The Free Software Foundation has announced
the selection of Ian Kelling as the organization’s president.
Kelling, age forty-three, has held the role of a board member and a
voting member since March 2021. The board said of Kelling’s
confirmation: “His hands-on technical experience resulting from his
position as the organization’s senior systems administrator proved
invaluable for his work on the board of directors. The board is
confident Kelling is the right person to help the organization
achieve its long-term goals. His commitment to free software comes
from a life of exploring ways to exert user control. He has the
technical knowledge to speak with authority on most free software
issues, and he has a strong connection with the community as an
active speaker and blogger.”
превод от английски Ангел Игов, Бистра Андреева, Владимир Молев, Мария Змийчарова, Рада Ганкова, Златко Енев, Мария П. Василева, Владимир Полеганов, Пловдив: изд. „Жанет 45“, 2025
Димитър Кенаров знае какво прави – неговите статии са добре проучени, без да се разливат в детайли; добре структурирани, но с усещане за спонтанност; в тях има страст и лична позиция, но без претенция за нейната универсалност. „Диктатори, трактори и други приключения“ впечатляваше със скоростта, с която те въвежда в темата и ти дава купища важен контекст, без да губи нишката на повествованието, на личния разказ: какво например представлява туристическа обиколка по стъпките на военнопрестъпника Радован Караджич, какво е да си имаш проблеми с властите в Беларус и т.н. Личното преживяване прави темата секси, като анекдот от пътуване; информацията е толкова, колкото да се ориентира интелигентен, но забързан читател. С други думи, статиите следват формàта на прочутите медии, в които са публикувани, и го следват добре. За българския читател, който също има нужда от „увод“ в наследството на войната в Югославия или в ситуацията в Беларус, това също е идеално.
Какво обаче става, когато бързият поглед „отвън“ е към ситуацията в самата България? Доста смело е от страна на автора да издаде в книга точно тези статии. В много страни писателите будят негодувание, ако описват родината за чужда публика – и много ясно защо. Във всяка страна съществува някакъв самоласкателен вътрешен наратив, някаква версия на патриотичните клишета, които в умерена степен имат полезната функция да създават и възпроизвеждат чувство на принадлежност. Дали са добра, или лоша литература, зависи от ситуацията, но едва ли бих рискувала много, като кажа, че кичът създава по-здрава спойка между хората не само у нас. Никой добър писател обаче не може да възпроизведе клишетата, без да се откаже от задачата си и просто да отговори на търсенето. Разбира се, родната публика често може да възрази, че различното описание отговаря на търсенето на някоя друга, чужда публика и създава анекдотичен стереотип.
Димитър Кенаров дава умен отговор на този предусетен упрек, като говори за „очудняването“ на света по идея на Виктор Шкловски – онази функция на изкуството да опреснява ума и да му помага да види света отвъд готовите щампи на съзнанието: подразбира се, един свят на по-силни багри, по-ясни звуци, по-дълбоко чувстване.
Кенаров подсказва, че може би имаме нужда от такъв „очуднен“ поглед към отечеството, за да го видим наистина, вместо постоянно да се срещаме с някаква фикция за него.
Този поглед за автора минава през историите на Георги Марков и Георги Стоев, през мавзолея и некролозите, представя на американския читател Георги Господинов и Иво Димчев и завършва с идеята за хоризонта граница и неговата роля в съвременната българска история.
Статиите са разнородни, доколкото не са писани с оглед на бъдещото им събиране в книга. Статията за Георги Марков е особено ефектна заради скрития в нея паралел – също като автора, Марков говори отвън на хората в родината си. Разбира се, за Георги Марков залогът е самият живот, както впрочем и за Георги Стоев, героя на втората статия. Той не говори извън страната, но говори извън мафиотските среди и това също се оказва фатално. Приликата няма общо с литературните качества на текстовете, а е по-скоро социолитературна и разкрива механизма на омертата – както в тоталитарната, така и в мафиотската държава.
Следващите две статии разказват истории за живота след смъртта в България, по-точно за социалния живот след смъртта. Историята на мавзолея на Георги Димитров е позната (не и на младите поколения), но тъкмо поради близостта не виждаме нейната куриозност. Как бихме се впечатлили, ако ставаше въпрос за гробница на узбекистански сатрап, превърната впоследствие в оперна сцена и място за скейтъри, преди да бъде разрушена?
Некролозите стоят малко по-различно. Необичайни за външния поглед, те са нещо сакрално за вътрешния, така че историческият факт на тяхната поява като външна мода успява да изненада българския читател. Аз бих спестила финалния извод – трябва ли да отмира една традиция само защото не се среща другаде? Освен това традиция, свързана с преработката на скръбта, винаги има и частична терапевтична роля. Но така или иначе, завършекът е ясно обозначен като лично мнение вместо като сериозна препоръка.
Най-спорна ми се струва статията, представяща Георги Господинов пред американския читател. Тя е похвална и тъй като би могла да се схване като реклама на сънародник, авторът се застрахова с дълъг увод, в който обяснява как всъщност не обича особено българска литература и Господинов е изключение. Ето тук представянето на контекста се превръща в неговото заличаване. Старата литература е видяна през опушеното стъкло на образованието, а новата е напълно удавена със сравнението с хладка вана, която изглежда ободряваща, но никой не би стоял дълго в нея. Е, с личен вкус не може да се спори, но все пак ми се струва, че това посивяване на фона е било необходимо, за да изпъкне повече разказаната поредица сюжети от Господинов. Контрастът е подвеждащ; и „Естествен роман“, и много от темите и похватите на Господинов са вплетени в литературните разговори, теми, спорове и стилове на 90-те, както в Софийския университет, така и в „Литературен вестник“, „Култура“, „Витамин Б“ и „Ах, Мария“, в експерименталната литература на Прехода. Разбира се, те не бяха по същия начин разбираеми за по-широката публика, защото по това време елитарността и авангардът бяха желани, а не отбягвани; но като цяло бяха движени от сходен литературен тласък. Темата заслужава анализ.
Така или иначе, не знам каква роля е изиграла статията за външния читател; за тукашния ми се струва ценно припомнянето, че обичта към родната литература не се ражда в клишето, наложено с власт и повтаряно до припадък. И че много потенциални читатели (у нас и в емиграция) са били отблъснати именно от това, което е трябвало да ги привлече.
Затова пък доста жив и забавен е разказът за Иво Димчев, и по-специално за неговите домашни концерти по време на пандемията. Може би защото е и повече в духа на другите статии – разказ за поместването на конкретен творец в една ситуация, в преодоляването на забрани – в случая не тематични, а забраната на самото общуване чрез музиката, на провеждането на концерт. Тази история е любопитна, защото тук бягството не е навън (няма как да бъде, пандемията е глобална), а навътре – от общественото към частното пространство.
Книгата завършва с размишление за хоризонта граница, за символичното завладяване на непознати територии и свързаната с това обединителна енергия. Образът отпраща към преместването на границата на САЩ все повече на запад, в предполагаемо дивите индиански територии, и е общоприета метафора за общото усещане за посока, което в един момент отпада (заселниците стигат океана). Авторът казва нещо подобно за целия западно-либерален проект: че е достигнал момента, в който няма накъде да се развива, и затова в него се появяват различни фиктивни „граници“ като Тръмп и пр., които да върнат на хората чувството, че се движат нанякъде. Проблемът с тази метафора е, че заселниците не напредват в празни територии, а ги отнемат от индианците, чиято територия се свива. В съвременния свят е доста видимо, че разделителните линии, пределите не са между нас и нищото, а между нас и други като нас, които обаче настъпват в обратна посока.
Ето конкретен пример за живия, провокативен, експериментаторски дух в литературата на 90-те, за който стана въпрос по-горе. Тази книга припомня какви ни се искаше да бъдем след падането на съветската империя и нейните поддържащи режими: свободни, ерудирани, способни на лекота и игра, но и на изненадваща дълбочина, на поглед отвъд времето, към голямата картина. „Избрани епитафии от залеза на Римската империя“ на Кирил Мерджански излиза в първия си вариант през 1992 г. и е всичко това.
На първо място, самата концепция е игра, предизвиква смях – да пишеш от името на разнообразните автори на епитафии (надгробни текстове) в Древния Рим!
Какъв жанр само, колко необичаен за днешното литературно ветрило! (Ако не броим сборниците със стихчета за некролози, за които говори Кенаров – за тях също си струва да се направи мистификация.) В интервю за „Култура.бг“ Мерджански споменава, че е започнал тренд с мистификации – и действително беше така. Гаустин у Господинов е част от това „разрояване на автора“. У Мерджански авторовите аватари са много – защото всеки надгробен надпис е от името било на починалия, било на неговите близки.
За разлика от много съвременни книги обаче, Избраните епитафии не се заключават в концепцията си, те стъпват върху реално познаване на античния контекст, на митологичните препратки и пластове, на ежедневието и на детайлите, които обичайно изпадат извън масовата представа за Древния Рим – примерно, гладиаторските борби, в които са участвали траките, обичайно са включвали съвсем леко въоръжение и затова се е предполагало гладиаторите да си помагат взаимно. Освен когато това не е ставало.
Разбира се, Мерджански е историк, специалист по антична история, знае добре за какво говори; книгата е обилно снабдена с бележки под линия, които пренасят читателя в Древния Рим чак до миризмата на пергамента, направен от животинска кожа, и може би затова твърде изкусителен за кучешкия нос. А дали можем да се доверим на новата роля на автора – този път като съвременен учен, уж анализиращ древните епитафии? Той също е измислен, той също може да си измисля – точно като уж научните обяснения и цитати у Борхес (един от всеобщите любимци на младите писатели от 90-те). Едно е безспорно – и за да излъжеш, ти трябва ерудиция.
Епизодът с кучето, излапало пергамента, впрочем не е от 90-те. Той е от втората част, написана сега, по време на ковид. И в нея са събрани епитафии на животни – реално съществуващ в Римската империя жанр. Тук като че ли още по-ясно се вижда как се преплитат смешното и съдбовното. Смъртта, естествено, е тема висока и трагична – вероятно най-високата и трагична възможна тема, самата причина човекът да търси нещо отвъд нетрайността на плътта. Обаче всяка конкретна смърт е и обръщане към живота на конкретния човек, а конкретният човек (или животно) има плът, тази плът има щения, сетивност, слабости, тя се движи в неочаквани посоки и предизвиква всякакви ситуации. Като кучето, което си отишло заради преяждане със Сенека! Е, добре де, с пергамента, върху който били записани неговите думи.
Всяка сакралност носи табута, забрани и живият живот непрестанно ги престъпва. Весталката, прегрешила с роба си, е умъртвена; на надгробния ѝ камък има забрана да се стъпва… точно там, където трябва да стъпиш, за да прочетеш забраната. Разбира се, по надгробните камъни не се и драска, но ето че по-долу има нещо надраскано… и още нещо… А оттатък? Ако животът е пълен с отбивки, не е ли отвъдното предначертано? Кой смъртен може да е сигурен. Весталката се надява в отвъдното да се събере със своя любим, да тичат заедно сред високи треви. Той обаче се е покръстил и неговият задгробен живот е различен от нейния. Стопанинът на преялото със Сенека куче е направил изискуемото, тъй щото неговият любимец на оня свят да води добър живот; с други думи, представя си как кучето му ще разкъсва грешници. Но пък не е много сигурен дали той самият няма да се окаже между тях… Ето как под смеха и играта надзъртат големи въпроси – като идеята за морален живот като залог за бъдещето на душата. И Сенека надзърта, естествено.
Любопитно ми е какъв отзвук ще има тази книга сега. През 90-те нейната жизнена среда беше университетът, по-точно хуманитаристиката и още по-точно пишещите, спорещи, воюващи къде на шега, къде сериозно преподаватели, обзети от онова оживление, което ги предизвикваше да се събират за семинари и дискусии по всеки актуален културен или културно-политически въпрос – от явлението Христо Калчев до Хайдегер – и което се отливаше в литературни медии, а те от своя страна се стремяха към сходна комбинация от ерудиция и хъс (и понякога се подозираха в мистификации). Дали днес, когато все по-малко личи хората да ценят свободата, а ерудицията изглежда на няколко линка разстояние, ще има кой да се зарадва на тези стихотворения? Боя се, че не само Римската империя залязва, но поне се надявам епитафиите ни да са смешни.
В емблематичната си колонка „Ходене по буквите“, започната още през 2008 г. във в-к „Култура“, Марин Бодаков ни представяше нови литературни заглавия и питаше с какво точно тези книги ни променят. В началото на 2020 г. той я пренесе в „Тоест“. Вярваме, че е важно тази рубрика да продължи. От човек до човек, с нова книга в ръка. От края на 2021 г. по буквите тръгна Зорница Христова.
Активните дарители на „Тоест“ получават 20% отстъпка от коричната цена на всички книги на над 15 български издателства. Кои са те – вижте в условията на Читателски клуб „Тоест“.
Емоционалното напрежение от постоянните негативни новини и безграничният достъп до т.нар. doomscrolling (безкрайно скролване) водят до рекордни нива на избягване на новини,
За журналистите това е двойно предизвикателство: не само защото добрата журналистика не може да се съревновава нито с бързите новини, нито с дезинформацията, но и защото самите журналисти са хора, които не са изключение от горната тенденция.
Случващото се в Америка е апотеозът на дигиталната ера: президентът туит; партията му, която управлява през манипулация и угодно изкривени факти; и всичко това в лайв, риалити формат, в който вдовиците излизат да оплачат съпрузите си с хореография със заря пред многомилионна публика. Както и самите републиканци са го казвали неведнъж, партията на президентът Тръмп владее шоуто, пропагандата и комуникацията много по-добре от опонентите си – а във времена, в които електоратът изисква ентъртейнмънт, това ги прави печелившите и по-добрите политици.
Тръмп, разбира се, не е конник на апокалипсиса, а само продукт на неговото продължително, унищожително бавно (и тъпо) разгръщане. Хората, които все още следят новините и избират да прекарват повече време в социалните мрежи, живеят в паралелен свят, където винаги навсякъде нещо или някой е на ръба на пропастта. В първите по-хладни дни дълго мислих как точно този бюлетин да избяга от подобна тенденция.
Апокалипсисът има много сценарии. Един от най-интересните е картата на бъдещето, в която десетки настоящи тенденции се преплитат и пресичат, за да нарисуват всички версии накрая. Сред тенденциите на настоящето – ръст в проблемите с психичното здраве, хегемонията на глобалния капитал и растящата геополитическа нестабилност например – тук-там са разпръснати и контратенденции: „възраждане на рисуването на ръка“, „автомати за кратки разкази“, „бавни новини“. Всичко това може да звучи смешно, но се оказва, че антидотът за апокалипсиса е повторното свързване с човешкото, най-вече през изкуството. Затова вместо поредна брънка във веригата от апокалиптични новини, коментари, контракоментари, анализи, контраанализи, доклади и т.н., в този брой ще си говорим за страшния свят през
Пет парчета, които ни казват нещо за историята на Америка (за слушане преди и след края на света)
Neil Diamond – America (1980)
Песента е посветена на имигрантите, които избират САЩ за свой дом. Даймънд, който по това време вече е един от най-успешните изпълнители на американската – а и световната – сцена, е вдъхновен от пътешествието на предците си, имигранти от Източна Европа, към Ню Йорк. „Това е историята на баба ми и дядо ми, които бягат от преследване в Русия и идват в Америка в търсене на свобода“, казва Даймънд за парчето.
По някакъв начин песента говори на имигранта във всеки от нас. И затова според мен е толкова лесно човек да я хареса. Надявах се да разкажа историята на имигранта, който идва в Америка с големи очаквания, със самата идея за Америка, вплетена в мечтите му.
Ако попитате някой американец, много малко песни, освен националния химн, въплъщават толкова силно идеалите, върху които е основана държавата – или поне една част от тях. Историята обаче не свършва дотук. След атаките на 11 септември 2001 г. песента на Нийл Даймънд попада в списък от парчета, които не е препоръчително да се пускат в радиоефир. Скоро след това Даймънд променя част от текста по време на своите концерти. Вместо „Те идват в Америка“ (They're comin' to America) той пее „Станете за/Застъпете се за/Защитете Америка“ (Stand up for America).
През изминалата седмица 120 иранци бяха депортирани в Иран в рамките на двустранно споразумение между двете държави. Съдия, назначен по времето на Рейгън, излезе със силно критично мнение за администрацията на Тръмп, в което се казва, че държавата използва имиграционни механизми за натиск и цензура над гражданите си. И още: че никога досега в историята си САЩ не са имали маскирана анонимна полиция, камо ли с правомощия да задържа и измъчва. Папа Лъв XIV разкритикува Щатите за „нехуманно“ отношение спрямо имигрантите, а журналист бе атакуван и блъскан от федералните власти в Ню Йорк.
Метафората на песента, както и на нейната история ни казват предостатъчно за двете страни на монетата – двата гласа, на които Америка пее и които, изглежда, ще се редуват безкрайно във времето.
N.W.A. – Fuk the Police (1988)
Полицейският тормоз над цветнокожи и хора от малцинствата е факт както днес, така и през 80-те, когато излиза хип-хоп класиката на N.W.A.(Niggaz Wit Attitudes) – група, включваща в различни периоди Arabian Prince, Dr. Dre, Eazy-E, Ice Cube, DJ Yella и MC Ren. В рамките на мащабна операция, започнала пред 1987 г., полицията в Лос Анджелис обявява война на уличното насилие. Обвинения са повдигнати на по-малко от процент от полицаите, разследвани във връзка с множеството сигнали за използване на прекомерна сила.
Просто не можеше да се търпи да бъдеш под властта на този окупатор [полицията – б.а.], който тормозеше. Казахме си: „Стига толкова!“ Музиката ни беше единственото оръжие. Мирен протест.
Това заявява рапърът Ice Cube в интервю. Парчето е забранено в ефира на някои радиостанции, което го прави още по-популярно.
През лятото на 1989-та, по време на концерт в Детройт, Мичиган, N.W.A. успяват да изпеят около трийсетина секунди от песента, преди отнякъде да се чуят изстрели. Изпълняват я едва за втори път по време на лайв. Групата бяга към бекстейджа, а там ги чакат полицаи, които ги приковават към земята, закопчават ги с белезници и ги затварят в някаква стаичка. След това полицаите искат автографи от изпълнителите. Заместник-директорът на ФБР пък изпраща писмо до лейбъла на N.W.A., в който се оплаква от песента.
Парчето преживява ренесанс през 2014 и 2015 г. в контекста на множество инциденти с участие на полицията, при които загиват невъоръжени чернокожи мъже – Майкъл Браун във Фъргюсън, Мисури; Ерик Гарнър в Статън Айлънд, Ню Йорк; Фреди Грей в Балтимор, Мериленд.
Войната срещу бандите е политкоректният начин да кажем, че водим война срещу всеки, когото считаме за престъпник. Това означаваше война срещу всяко черно хлапе, което носи бейзболна шапка или тениска, джинси или кецове,
През 2025 г. Fuk da Police бе обявена за една от стоте най-добри протестни песни в историята. Пародията на съдебен процес, около която е изграден текстът, е особено релевантна не само в контекста на продължаващите преследвания на малцинствата – понастоящем латиноамериканци или мюсюлмани – но и с оглед на превръщането на правосъдната система в лично оръжие за разчистване на сметките на президента.
Buffalo Springfield – For What It’s Worth
Стивън Стилс пише песента през 1966-та, във вихъра на контракултурата и силните обществени реакции, които предизвиква тя. Въпреки че стандартно For What It’s Worth се смята за протест срещу войната във Виетнам, Стилс всъщност се вдъхновява от хипи протестите (Sunset Strip curfew riots) и сблъсъците между младите и полицията в Лос Анджелис.
Парчето бързо се превръща в протестна песен, а по-късно става част и от саундтрака на „Форест Гъмп“, което я бетонира като разпознаваем акомпанимент на всичко, свързано с периода на 60-те и контракултурата. Както предходната песен, така и For What It’s Worth е част от протестите след убийството на Джордж Флойд в САЩ през 2020-та. Тези протести все още се използват като политическа дъвка и от двете страни на идеологическия спектър.
В песента се преплитат четири различни линии, включително войната и абсурдите, които се случваха в Лос Анджелис. Написах я за около петнайсет минути. За мен всъщност тогава нямаше протест. Имаше нещо като танц с ченгетата… Да го определяме като бунт е абсурдно. Беше погребение на кутията на Пандора. Но тогава ни изглеждаше като революция,
Във времената на погребаните революции – от Великата Америка, която така и не става по-велика, през сякаш забравените вече протести в полза на човешките права, белязали първите две десетилетия на XXI век, чак до несбъднатите обещания на българските протести от 2013 г. и 2020 г. – какво ни остава освен да си припяваме: „Никой не е прав, ако всички грешат.“
Joni Mitchell – Big Yellow Taxi
„Бетонираха рая и сложиха паркинг с розов хотел, магазин… Не ти ли се струва, че не знаеш какво имаш, преди да го изгубиш?“, пише Джони Мичъл през 1970 г.
Написах парчето, когато бях на Хаваите за пръв път. Хванах такси до хотела и когато се събудих на следващата сутрин, дръпнах пердетата и видях прекрасни зелени планини в далечината. После погледнах надолу и имаше паркинги – докъдето ти стигат очите – и това ме съсипа… тази зараза в рая. Седнах и написах песента.
„Отсякоха дърветата и ги сложиха в музей за дървета, / вземат на хората долар и половина, за да ги гледат“, продължава Мичъл, описвайки ботаническата градина в Хонолулу, която е жив музей за тропически растения, много от които редки и застрашени. Песента се превръща в химн на движението за опазване на околната среда, а през 1995 г. става част от саундтрака на хитовия сериал „Приятели“. В синхрон с епизода е пусната отново като максисингъл с различни ремикси.
Песента разказва за унищожаването на природата, която се превръща във вещ за продан, в атракция, в реликва. Според проучване, публикувано през септември тази година, употребата на думи, свързани с природата, е спаднала с 60% между 1800 и 2019 г. Учените разглеждат 28 ежедневно използвани лексеми, свързани с природата, като „поляна“ и „клюн“ например, чрез база данни на Google, която следи за честотата на употреба на различни думи в английския език.
„Думите отразяват онова, което хората забелязват, ценят и за което пишат“, казват авторите на проучването. Те изграждат компютърен модел, който показва как с разрастването на градовете и с изчезването на зелените пространства се губи досегът с природата в рамките на няколко поколения.
От началото на втория мандат на президента Тръмп тече пълномащабна кампания за премахване на важни закони и регулации, свързани със замърсяването, застрояването и опазването на околната среда. Една от ключовите акции е за премахването на регулациите на т.нар. вечни химикали, пагубни за здравето на хората и за цялата планета.
Green Day – American Idiot
Песента, която дава и името на вероятно най-известния албум на бандата от 2004 г., е директно възпяване на гнева и отвращението от американската политика по време на президентството на Джордж Буш-младши и ерата след атаките на 11 септември – може би истинското историческо начало на това, което наричаме „съвремие“.
Фронтменът Били Джо Армстронг нарича парчето „пречистване“. Корицата на сингъла изобразява мъж и жена, които държат детето си за ръце и го повдигат за скок право в отворен капан (изображението е далеч по-непознато от обложката на албума – на нея ръка държи сърце граната, от което тече кръв).
Обвиненията, че масовите медии затъпяват и произвеждат параноя, която води до политическо и социално изглупяване, не са нови за американската култура и контракултура. В публикувания през 1996 г. роман „Безкрайна шега“ на Дейвид Фостър Уолъс корпорациите могат да наддават за това различните години да носят имената на продуктите им, а президентът на САЩ е поп звезда, хипохондрик и микробофоб, който печели изборите с обещанието да изчисти държавата, без да причини дискомфорт на когото и да било в хода на „почистването“. Дон ДеЛило публикува своя „Бял шум“ през 1986 г. и в него описва вездесъщото присъствие на медиите, на камерите, на белия шум на безкрайната комуникация, която всъщност не само че не ни казва нищо, а и ни отдалечава от близките ни и от нас самите.
Oще през 1988 г. Нийл Йънг казва:
Няма да пея за „Пепси“, няма да пея за „Кока-кола“ няма да пея за никого, иначе изглеждам нелепо.
А във видеото към парчето This Note’s For Youпародира бавното уеднаквяване на културата и изкуството и пълненето им с клишета, рекламни сюжети и поп звезди, които се продават на корпоративно-медийната машина. Видеото на Йънг е забранено за пускане по MTV, поради което Йънг ги нарича „безгръбначни“ и ги пита какво означава първата буква от името им – пари (money) или музика.
Видиотяването на Америка, а оттам и видиотяването на света, се усеща като идваща буря в самото начало на нашия век. Две години след American Idiot излиза филмът „Идиокрация“. За времето си той изглежда абсурдно, а днес е пророчески – точно както и обувките Crocs, които са избрани от сценаристите заради абсурдния им грозен вид, подходящ за такъв свят, и се превръщат в абсолютен хит, какъвто остават и до днес.
Хубавото на всичко това е, че все още има хора с гръбнак. Оставям ви с клипа на актьора Джоузеф Гордън-Левит, който разказва какви мръсотии може да говори чатботът на Facebook на децата ви – одобрено от Meta/Facebook и неподлежащо на санкции.
Още една причина да прекарваме повече време офлайн, слушайки хубава музика.
Абонирайте се, за да получавате този бюлетин на електронната си поща в момента, в който излезе!
Вече сте регистриран потребител на Toest.bg? Може директно от настройките на бюлетините в своя профил да изберете „Гласовете на Америка“ или да натиснете бутона по-долу:
Organizations manage content across multiple languages as they expand globally. Ecommerce platforms, customer support systems, and knowledge bases require efficient multilingual search capabilities to serve diverse user bases effectively. This unified search approach helps multinational organizations maintain centralized content repositories while making sure users, regardless of their preferred language, can effectively find and access relevant information.
Building multi-language applications using language analyzers with OpenSearch commonly involves a significant challenge: multi-language documents require manual preprocessing. This means that in your application, for every document, you must first identify each field’s language, then categorize and label it, storing content in separate, pre-defined language fields (for example, name_en, name_es, and so on) in order to use language analyzers in search to improve search relevancy. This client-side effort is complex, adding workload for language detection, potentially slowing data ingestion, and risking accuracy issues if languages are misidentified. It’s a labor-intensive approach. However, Amazon OpenSearch Service 2.15+ introduces an AI-based ML inference processor. This new feature automatically identifies and tags document languages during ingestion, streamlining the process and removing the burden from your application.
By harnessing the power of AI and using context-aware data modeling and intelligent analyzer selection, this automated solution streamlines document processing by minimizing manual language tagging, and enables automatic language detection during ingestion, providing organizations sophisticated multilingual search capabilities.
Using language identification in OpenSearch Service offers the following benefits:
Enhanced user experience – Users can now find relevant content regardless of the language they search in
Increased content discovery – The service can surface valuable content across language silos
Improved search accuracy – Language-specific analyzers provide better search relevance
Automated processing – You can reduce manual language tagging and classification
In this post, we share how to implement a scalable multilingual search solution using OpenSearch Service.
Solution overview
The solution eliminates manual language preprocessing by automatically detecting and handling multilingual content during document ingestion. Instead of manually creating separate language fields (en_notes, es_notes, and so on) or implementing custom language detection systems, the ML inference processor identifies languages and creates appropriate field mappings.
This automated approach improves accuracy compared to traditional manual methods and reduces development complexity and processing overhead, allowing organizations to focus on delivering better search experiences to their global users.
The solution comprises the following key components:
ML inference processor – Invokes ML models during document ingestion to enrich content with language metadata
Amazon SageMaker integration – Hosts pre-trained language identification models that analyze text fields and return language predictions
Language-specific indexing – Applies appropriate analyzers based on detected languages, providing proper handling of stemming, stop words, and character normalization
In the following sections, we walk through the steps to deploy the solution. For detailed implementation instructions, including code examples and configuration templates, refer to the comprehensive tutorial in the OpenSearch ML Commons GitHub repository.
Deploy a pre-trained language identification model on Amazon SageMaker. The XLM-RoBERTa model provides robust multilingual language detection capabilities suitable for most use cases.
Configure the connector
Create an ML connector to establish a secure connection between OpenSearch Service and Amazon SageMaker endpoints, primarily for language detection tasks. The process begins with setting up authentication through IAM roles and policies, applying proper permissions for both services to communicate securely.
After you configure the connector with the appropriate endpoint URLs and credentials, the model is registered and deployed in OpenSearch Service and its modelID is used in subsequent steps.
POST /_plugins/_ml/models/_register
{
"name": "sagemaker-language-identification",
"version": "1",
"function_name": "remote",
"description": "Remote model for language identification",
"connector_id": "your_connector_id"
}
After you configure the connector, you can test is by sending text to the model through OpenSearch Service, and it will return the detected language (for example, sending “Say this is a test” returns en for English).
POST /_plugins/_ml/models/your_model_id/_predict
{
"parameters": {
"inputs": "Say this is a test"
}
}
{
"inference_results": [
{
"output": [
{
"name": "response",
"dataAsMap": {
"response": [
{
"label": "en",
"score": 0.9411176443099976
}
]
}
}
]
}
]
}
Set up the ingest pipeline
Configure the ingest pipeline, which uses ML inference processors to automatically detect the language of the content in the name and notes fields of incoming documents. After language detection, the pipeline creates new language-specific fields by copying the original content to new fields with language suffixes (for example, name_en for English content).
The pipeline uses an ml_inference processor to perform the language detection and copy processors to create the new language-specific fields, making it straightforward to handle multilingual content in your OpenSearch Service index.
Create an index with the ingest pipeline that automatically detects the language of incoming documents and applies appropriate language-specific analysis. When documents are ingested, the system identifies the language of key fields, creates language-specific versions of those fields, and indexes them using the correct language analyzer. This allows for efficient and accurate searching across documents in multiple languages without requiring manual language specification for each document.
Here’s a sample index creation API call demonstrating different language mappings.
{
"name": "Kaufen Sie Katzenminze",
"notes": "Mittens mag die Sachen von Humboldt wirklich."
}
The German text used in the preceding code will be processed using a German-specific analyzer, supporting proper handling of language-specific characteristics such as compound words and special characters.
After successful ingestion into OpenSearch Service, the resulting document appears as follows:
{
"_source": {
"predicted_notes_language": "en",
"name_en": "Buy catnip",
"notes": "Mittens really likes the stuff from Humboldt.",
"predicted_name_language": "en",
"name": "Buy catnip",
"notes_en": "Mittens really likes the stuff from Humboldt."
}
}
Search documents
This step demonstrates the search capability after the multilingual setup. By using a multi_match query with name_* fields, it searches across all language-specific name fields (name_en, name_es, name_de) and successfully finds the Spanish document when searching for “comprar” because the content was properly analyzed using the Spanish analyzer. This example shows how the language-specific indexing enables accurate search results in the correct language without needing to specify which language you’re searching in.
Implementing multilingual search with OpenSearch Service can help organizations break down language barriers and unlock the full value of their global content. The ML inference processor provides a scalable, automated approach to language detection that improves search accuracy and user experience.
This solution addresses the growing need for multilingual content management as organizations expand globally. By automatically detecting document languages and applying appropriate linguistic processing, businesses can deliver comprehensive search experiences that serve diverse user bases effectively.
AWS Lambda provides an event-driven programming model, scale-to-zero capability, and integrations with over 200 AWS services. This can make it a good fit for CPU-based inference applications that use customized, lightweight models and complete within 15 minutes.
Users usually package their function code as container images when using machine learning (ML) models that are larger than 250 MB, which is the Lambda deployment package size limit for zip files. In this post, we demonstrate an approach that downloads ML models directly from Amazon S3 into your function’s memory so that you can continue packaging your function code using zip files. To optimize startup latency without implementing application-level performance optimizations, we use Lambda SnapStart. SnapStart is an opt-in capability available for Java, Python, and .NET functions that optimizes startup latency—from 16.5s down to 1.6s for the application used in this post.
Application architecture
In this post, we demonstrate how to build a chatbot, using a 4-bit quantized version of the DeepSeek-R1-Distill-Qwen-1.5B-GGUF model for inference along with Lambda Function URL (FURL) and Lambda Web Adapter (LWA) to stream text responses. A FURL is a dedicated HTTP(s) endpoint for your Lambda function, and you can use LWA, an open-source project available on AWS Labs, for familiar web application frameworks (such as FastAPI, Next.JS, or Spring Boot) with Lambda. For a detailed explanation of how this response streaming architecture works, refer to this AWS Compute post.
Today, Lambda functions are run on CPU-based Amazon Elastic Compute Cloud (Amazon EC2) instances that use x86 and ARM64 architectures. For this reason, you must use SDKs that enable large language model (LLM) inference on CPUs. In this post, we also demonstrate how to use the llama.cpp project (through the llama-cpp-python library) and the FastAPI web framework to handle web requests. To use models that exceed the 250 MB zip package size limit of Lambda, you can download them from an S3 bucket during function initialization. The following figure describes this architecture in detail.
Figure 1: Application architecture
You can refer to this GitHub repository for the application code used in this example.
Downloading ML models during function initialization
As an alternative to packaging ML models using OCI container images, you can download them from durable storage, such as Amazon S3, during initialization. Initialization (or INIT) refers to the phase when Lambda downloads your function code, starts the language runtime and runs your function initialization code, which is code outside the handler. Loading large files directly into memory can be faster than first downloading them to disk and then loading them into memory. To do so, you can use a Linux capability called memfd, to directly download the ML model from Amazon S3 directly into memory, while referencing it using a standard file descriptor. Referencing the model using a file descriptor is necessary for llama.cpp to successfully import the model. This is comprised of two steps.
Then, download the model into the memory-mapped file referenced by the previously created file descriptor.
def download_model_to_memfd(bucket, key, chunk_size=100*1024*1024): # 100MB chunks
s3 = boto3.client('s3')
# Get file size
response = s3.head_object(Bucket=bucket, Key=key)
file_size = response['ContentLength']
# Create memory file
fd = create_memfd()
# Pre-allocate the full file size
try:
os.ftruncate(fd, file_size)
except OSError as e:
logger.error(f"Failed to allocate {file_size/1024/1024:.2f}MB in memory: {e}")
cleanup_fd(fd)
raise RuntimeError(f"Not enough memory to load model of size {file_size/1024/1024:.2f}MB")
# Calculate parts
parts = []
for start in range(0, file_size, chunk_size):
end = min(start + chunk_size - 1, file_size - 1)
parts.append({'start': start, 'end': end})
logger.info(f"Downloading {file_size/1024/1024:.2f}MB in {len(parts)} parts")
# Download parts concurrently
download_func = partial(download_part, s3, bucket, key, fd)
with ThreadPoolExecutor(max_workers=multiprocessing.cpu_count()) as executor:
executor.map(download_func, parts)
fd_path = f"/proc/self/fd/{fd}"
return fd, fd_path
Querying the chatbot
After deploying our sample chatbot application, we begin interacting with it.
The first query to the chatbot results in a new execution environment being initialized. When Lambda runs the initialization code described in the previous section, your ML model is directly downloaded from Amazon S3 into the function’s memory. After this, Lambda runs the function’s handler method. Looking at the X-Ray trace segment in the following figure, we observe that the first Init times out after 10 s. The second Init completes in 16.68 s. Furthermore, the first Init times out because Lambda limits the duration of this phase to 10s. If Init takes longer than this, then Lambda retries it during function invocation applying the function’s configured execution duration timeout.
Figure 2: Init duration, indicated by AWS X-Ray trace segment
Optimizing startup performance with SnapStart
To optimize function startup latency, you can use Lambda SnapStart. SnapStart is designed to optimize startup latency stemming from long-running function initialization code. Lambda uses SnapStart to initialize your function when you publish a function version, as shown in the following figure. Then, Lambda takes a Firecracker microVM snapshot of the memory and disk state of the initialized execution environment, encrypts the snapshot, and intelligently caches it to optimize retrieval latency.
Figure 3: Enabling SnapStart
Querying the chatbot again shows a significant speed-up in initialization latency. You can verify this by viewing your function’s Amazon CloudWatch Logs, and searching for the “RESTORE_REPORT” log line, as shown in the following figure. For the sample application used, restore duration is 1.39 s. This is a considerable improvement over the Init duration of 16.68 s. Performance results may vary. But best of all, you don’t need to change a single line of code to achieve this improvement!
Figure 4: Achieving faster startup latency with SnapStart
Tuning inference performance
Inference performance depends on the CPU resources allocated to your function. Lambda allocates CPU power in proportion to the amount of memory configured for your function. Allocating more memory results in faster inference results, measured by the rate at which prompt tokens are evaluated (tokens evaluated per second), and the rate at which output tokens are produced (tokens generated per second). For this example, we allocate the maximum—in other words 10 GB memory—to maximize performance. Performance results obtained at other memory size configurations are included in the following table. As the table shows, doubling the memory allocated from 5 GB to 10 GB results in an 83% improvement in tokens evaluated and generated (per second), with only a 24% increase in billed GB-seconds. Performance results may vary. Refer to the sample code to instrument performance at different memory sizes.
Memory Size (MB)
Tokens evaluated per second
Tokens generated
per second
Billed Duration (ms)
Billed
GB-seconds
10240
44.68
29.53
36,660
366.60
9216
41.67
26.77
37,690
339.21
8192
37.17
22.05
44,298
354.38
7168
33.67
21.78
44,818
313.73
6144
28.89
18.43
52,579
315.47
5120
24.41
16.07
59,036
295.18
4096
19.07
12.94
72,648
290.59
3072
13.39
9.20
101,468
304.40
2048
10.01
6.77
135,862
271.72
Table 1: Inference performance at different memory sizes
Understanding how application costs scale with usage
To estimate the cost of running this workload, we begin by making some assumptions about our traffic patterns. We estimate about 30,000 inference calls per month to our Lambda function, with each inference call averaging 10s in duration. We set function memory to 10 GB, because it represents the ideal price-performance for our use case. We deploy our application in the US-West-2 (Oregon) AWS Region. Initially, because our number of invokes is low, we assume a 5% cold-start rate. In other words, 5% of invokes result in a cold-start when a new execution environment is created. When using SnapStart with the Lambda managed Python runtime, you are charged for caching your function’s snapshot and for restoring execution from your function’s snapshot.
With these parameters, the monthly Lambda bill is $91.1, calculated as shown in the following table. The monthly costs shown in the table are only illustrative.
Charge
Calculation
Monthly Cost
Compute
30,000 inferences * 10 seconds per inference * 10 GB (configured memory) * $0.00001667 per GB-second
$50.01
Requests
$0.2 per million requests * 30,000 inferences
$0.006
SnapStart – Cache
10 GB function memory * 2.59M GB-seconds per month * $0.0000015046 per GB-second
$38.99
SnapStart – Restore
10 GB function memory * $0.0001397998 per GB restore * 1500 cold-starts
At low invocation volume, the added charges for the SnapStart account for approximately 50% of total monthly cost. For this added charge, cold-start latency reduces from 16.68 s to1.39 s, without having to implement complex optimizations ourselves. We can demonstrate how these costs scale with usage. We assume that our chatbot grows in popularity with traffic increasing 10 times to 300,000 monthly inference calls. Although cold-start rates for individual Lambda functions can vary due to several factors, Lambda’s re-use of execution environments generally results in cold-start rates decreasing with higher traffic volume. For the purposes of this example, we assume that our cold-start rate drops to 1% of all invokes with the 10 times growth in traffic.With these assumptions, our monthly Lambda bill at 10 times higher traffic volume is $543.3. Added charges for SnapStart now constitute less than 10% of our total bill, as shown in the following table. Monthly costs shown in this table are only illustrative.
Charge
Calculation
Monthly Cost
Compute
300,000 inferences * 10 seconds per inference * 10 GB (configured memory) * $0.00001667 per GB-second
$500.01
Requests
$0.2 per million requests * 300,000 inferences
$0.06
SnapStart – Cache
10 GB function memory * 2.59M GB-seconds per month * $0.0000015046 per GB-second
$38.99
SnapStart – Restore
10 GB function memory * $0.0001397998 per GB restore * 3000 cold-starts
Lambda functions are run on CPU-based EC2 instances. If your ML models need GPU-based inference, foundational LLMs, or exceed the Lambda limits on execution duration (15 minutes) and function memory (10 GB), then you can use AWS Machine Learning, AWS Generative AI, or AWS Compute services.
Moreover, you should know the following things about Lambda SnapStart:
Handling uniqueness: If your initialization code generates unique content that is included in the snapshot, then the content isn’t unique when it’s reused across execution environments. To maintain uniqueness when using SnapStart, you must generate unique content after initialization, such as if your code uses custom random number generation that doesn’t rely on built-in-libraries or caches any information such as DNS entries that might expire during initialization. To learn how to restore uniqueness, visit Handling uniqueness with Lambda SnapStart in the Lambda Developer Guide.
Performance tuning: To maximize performance, we recommend that you preload dependencies and initialize resources that contribute to startup latency in your initialization code instead of in the function handler. This moves the latency associated with these operations during version publish, rather than during function invocation and can yield faster startup performance. To learn more, visit Performance tuning for Lambda SnapStart in the Lambda Developer Guide.
Networking best practices: The state of connections that your function establishes during the initialization phase isn’t guaranteed when Lambda resumes your function from a snapshot. In most cases, network connections that an AWS SDK establishes automatically resume. For other connections, review the Networking best practices for Lambda SnapStart in the Lambda Developer Guide.
Conclusion
In this post, we demonstrated how you can download ML models directly from Amazon S3 into your function’s memory, enabling you to deploy your AWS Lambda functions using zip packages. To optimize startup latency without implementing application-level performance optimizations, we also demonstrated the use of Lambda SnapStart, an opt-in capability available for Java, Python, and .NET. For the application used in this post, SnapStart reduced startup latency from 16.68 s down to 1.39 s.
Building on top of open source packages can help accelerate development. By using common libraries and modules from npm, PyPI, Maven Central, NuGet, and others, teams can focus on writing code that is unique to their situation. These open source package registries host millions of packages that are integrated into thousands of programs daily.
Unfortunately, these key services are prime targets for threat actors looking to distribute their code at scale. If they can compromise a package in one of these services, that one action can automatically affect thousands of other systems.
September 8: Chalk and Debug compromise
It started with compromised credentials for a trusted maintainer for npm. After social engineering the credentials, 18 popular packages (including Chalk, Debug, ansi-styles, supports-color, and more) were updated with an injected payload.
This payload was designed to silently intercept cryptocurrency activity and manipulate transactions to the bad actor’s benefit.
Together these packages are downloaded an estimated two billion times each week. That means even with the rapid response from the maintainer and npm, the couple of hours that the compromised versions were available could have led to significant exposures. Any build systems that downloaded the packages during this window or sites that loaded them remotely were potentially vulnerable.
This sophisticated malware used intelligent reconnaissance techniques and adapted its behavior to find the most effective attack vector for its current context.
September 15: Shai-Hulud worm
The very next week, the Shai-Hulud worm started to spread autonomously through the npm trust chain. This malware uses its initial foothold in a developer’s environment to harvest a variety of credentials, such as npm tokens, GitHub personal access tokens, and cloud credentials.
When possible, the malware would expose the harvested credentials publicly. When npm tokens are available, it publishes updated packages that now contain the worm as an additional payload. The now compromised packages will execute the worm as a postinstall script to continue propagating the infection.
In addition to this self-propagation method, the worm also attempts to manipulate GitHub repositories it gains access to. Shai-Hulud sets up malicious workflows that run on every repository activity, creating a resilient and continuous exfiltration of code.
This exploit showed technical sophistication and a deep understanding of the developer workflows and the trust relationships that power the community. By using the standard npm installation processes, the worm makes detection more challenging because it operates within the behavioral patterns expected of developers.
Within the first 24 hours of this exploit, over 180 npm packages had been compromised, again potentially affecting millions of systems. Both incidents show the potential scale of supply chain compromises.
How to respond to these types of events
If a compromised package has made it into production, you should follow your standard incident response process for active incidents to resolve the issue. To sweep your development environment, we recommend the following steps:
Audit dependencies: Remove or upgrade to clean versions of Chalk and Debug packages and check for Shai-Hulud-infected packages.
Rotate secrets: Assume npm tokens, GitHub PATs, and API keys might be compromised. Rotate and reissue credentials immediately.
Audit build pipelines: Check for unauthorized GitHub Actions workflows or unexpected script insertions.
Use Amazon Inspector: Review Amazon Inspector findings for exposure to the Chalk/Debug exploit or Shai-Hulud worm and follow recommended remediation.
Harden supply chains: Enforce SBOMs, pin package versions, adopt scoped tokens, and isolate continuous integration and delivery (CI/CD) environments.
How Amazon Inspector strengthens open source security with OpenSSF
We regularly share the findings from the malicious package detection system in Amazon Inspector with the community through our partnership with the Open Source Security Foundation (OpenSSF). Amazon Inspector uses an automated process to share this type of threat intelligence using the Open Source Vulnerability (OSV) format.
Amazon Inspector employs a multi-layered detection approach that combines complementary analysis techniques to identify malicious packages. This approach provides robust protection against both known attack patterns and novel threats.
Starting with static analysis using an extensive library of YARA rules, Amazon Inspector can identify suspicious code patterns, obfuscation techniques, and known malicious signatures within package contents. Building on that, the system uses dynamic analysis and behavioral monitoring to identify threats, despite their use of evasion techniques. The final set of analysis is conducted using AI and machine learning models to analyze code semantics and determine the intended purpose versus suspicious functionality within packages.
This multi-stage approach enables Amazon Inspector to maintain high detection accuracy while minimizing false positives, helping to make sure that legitimate packages are not incorrectly flagged and sophisticated threats are reliably identified and mitigated.
When these threats are detected in open source packages, the system starts the automated workflows to share this threat intelligence with the OpenSSF. This workflow sends the validated threat intelligence to the OpenSSF where the contributions are rigorously reviewed by the OpenSSF maintainers before being merged in the community database. That is where they receive an official MAL-ID or malicious package identifier.
This process helps verify and share these types of discoveries as quickly as possible with the community, so that other security tools and researchers benefit from the detection capabilities of Amazon Inspector.
What’s next?
Chalk/Debug and the Shai-Hulud worm are not novel exploits. These are—unfortunately—the most recent incidents using this vector. Open source repositories are a fantastic resource for developers and help many teams to innovate more quickly. The open source community is working hard to reduce the impact of these types of incidents.
That is why we have partnered with the OpenSSF and have contributed reports that highlight over 40,000 npm packages that were compromised or created with malicious intent. We believe that Amazon Inspector is an excellent tool to help you build safely and securely, and while we would love everyone to use it, we are proud that our work and contributions to efforts like OpenSSF are helping improve the security of everyone in the community.
Developer operations (DevOps) engineers sit at the intersection of development and operations. Their job is to keep pipelines humming, environments consistent, and deployments on schedule, all while juggling uptime, costs, and compliance.
This balancing act leaves little tolerance for surprises. Unfortunately, storage from major cloud providers often delivers exactly that. Built to cover every use case from backups to analytics to streaming, general-purpose storage prioritizes breadth over focus. The result is complexity:
Tiering rules that shift data unexpectedly
Pricing models that change with every access pattern
Dependencies that ripple across services
For DevOps, this type of one-size-fits-all system means hidden costs, shifting performance, and integration headaches right when predictability matters most.
The good news: you don’t need to overhaul your entire stack to regain control. Adding a specialized, always-hot storage layer can resolve DevOps engineers’ biggest storage headaches without forcing major workflow changes.
This post is the second in our three-part series on how specialized storage helps every member of a cloud-native team, including developers, DevOps engineers, and site reliability engineers (SREs). Today, we’ll focus on the payoffs for DevOps engineers.
Storage that works the way DevOps does
For DevOps engineers, storage issues often show up in the middle of critical workflows. A change meant to speed deployments triggers cascading adjustments. A spike in access patterns turns into sprawling invoices and finance tickets. A misaligned rule blocks data right when pipelines need it most.
In the sections below, we’ll dig into how these problems derail day-to-day operations, and how purpose-built cloud storage removes the friction so DevOps teams can stay focused on building and delivering.
Free ebook: Why object storage is essential for AI workloads
Unlock faster development and simpler workflows—without surprise costs. Get our free ebook “Cloud Storage for the Cloud-Native Era.”
Migration without migraines
Swapping a storage layer usually comes with the fear of broken pipelines, incompatible APIs, or weeks of retraining. And the big three cloud providers compound this by tying services together so tightly that even small changes can ripple through deployments.
That means a tweak meant to improve storage can unexpectedly force adjustments in compute, networking, or identity and access management (IAM). Now, you’re slowing down releases instead of speeding them up.
Specialized storage avoids this trap. With drop-in S3 compatibility and no tier juggling, adding it to your stack requires little more than updating an endpoint and credentials. Pipelines keep running, Terraform and Kubernetes scripts stay intact, and deployments continue smoothly, so storage upgrades feel like routine maintenance, not full migrations.
Invoices without inquisitions
Engineers shouldn’t have to be accountants. But with major cloud providers, storage costs often spike without warning when charges are tied to shifting access patterns, such as frequent reads, writes, or transfers.
The result is sprawling invoices packed with egress fees, API surcharges, and delete penalties. Finance teams see the bill and demand answers. DevOps teams could spend hours untangling storage math instead of improving automation or hardening pipelines. Every unexplained charge turns into a ticket, and every ticket drags engineers away from engineering.
Specialized storage removes this ordeal. Flat, transparent pricing and no hidden penalties make costs easy to predict and explain. That clarity keeps tickets low and escalations rare. DevOps teams can walk into finance reviews with confidence, backed by numbers that are simple to explain.
Engineering without entanglements
Major cloud provider environments come with a maze of tiers, lifecycle policies, IAM rules, and cross-service dependencies. Managing these isn’t a one-time task; it’s a cycle of effort that eats into engineering time:
Writing: Defining lifecycle policies and IAM rules to control when data moves between tiers or who can access it.
Testing: Validating every rule to make sure it doesn’t archive active data, block critical access, or violate compliance requirements.
Maintaining: Updating policies as workloads evolve, with new buckets, new services, or shifting security mandates.
Troubleshooting: Debugging typos, misaligned automations, or unexpected interactions that can lead to outages, delays, or surprise costs.
For DevOps, every new policy is another layer of overhead and another chance for something to break.
Specialized storage ends this cycle. With no lifecycle rules to script or tiers to monitor, you don’t have to spend hours debugging brittle policies. That reclaimed time goes back into what matters: strengthening automation, refining observability, and improving the pipelines your developers depend on.
Growth without gridlock
DevOps isn’t just about keeping today’s pipelines running; it’s also about ensuring infrastructure won’t collapse under tomorrow’s demands.
As organizations layer on AI/ML pipelines, streaming services, or analytics workloads, data volumes surge and access patterns become less predictable. General-purpose storage often struggles under these conditions, throttling performance and forcing DevOps engineers into troubleshooting slowdowns and capacity crunches whenever workloads outpace storage.
Specialized storage meets these challenges. Its high throughput and penalty-free design scale with demand, so performance holds steady even as workloads expand. Whether supporting AI training jobs or streaming analytics, your infrastructure grows without bottlenecks—and without turning DevOps into crisis management.
Rethink your storage, not your stack
The demands on DevOps engineers aren’t slowing down. They’re expected to deliver speed, reliability, and cost control, all at once. The wrong storage layer makes that harder; the right one makes it easier.
Backblaze B2 was built to make DevOps engineers’ lives easier:
Minimal changes: S3-compatible APIs work with Terraform, Kubernetes, ArgoCD, and more.
Predictable costs: Transparent pricing and little-to-no egress fees.
Simplified operations: Always-hot access, no tier juggling, no lifecycle headaches.
You don’t have to rebuild your stack to gain these benefits. Just swap the storage endpoint, redeploy, and get back to engineering.
Tired of troubleshooting tiers or decoding invoices? There’s a simpler path forward. Explore how Backblaze B2 fits into your DevOps workflows, and how much smoother things run when storage isn’t slowing you down.
Basically whoever can see the most about the target, and can hold that picture in their mind the best, will be best at finding the vulnerabilities the fastest and taking advantage of them. Or, as the defender, applying patches or mitigations the fastest.
And if you’re on the inside you know what the applications do. You know what’s important and what isn’t. And you can use all that internal knowledge to fix things—hopefully before the baddies take advantage.
Summary and prediction
Attackers will have the advantage for 3-5 years. For less-advanced defender teams, this will take much longer.
After that point, AI/SPQA will have the additional internal context to give Defenders the advantage.
LLM tech is nowhere near ready to handle the context of an entire company right now. That’s why this will take 3-5 years for true AI-enabled Blue to become a thing.
And in the meantime, Red will be able to use publicly-available context from OSINT, Recon, etc. to power their attacks.
The GNU Tools Cauldron is almost entirely focused on user-space tools, but
kernel developers need a solid toolchain too. In what appears to be a
developing tradition (started in 2024),
some kernel developers attended the 2025 Cauldron for the
second year in a row to discuss their needs with the assembled toolchain
developers. Topics covered in this year’s gathering include Rust, better BPF type
format (BTF) support, SFrame, and more.
Greg Kroah-Hartman has announced the release of the 6.16.10, 6.12.50, 6.6.109, 6.1.155, 5.15.194, 5.10.245, and 5.4.300 stable kernels. All of these kernels
have lots of important fixes throughout the kernel tree.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
