Post Syndicated from The Atlantic original https://www.youtube.com/shorts/bOGKKDhYYjs
Piper Alpha: Nightmare on the North Sea #sponsored
Post Syndicated from Geographics original https://www.youtube.com/watch?v=bImwwJ94WaQ
Amazon Q Developer end-of-support announcement
Post Syndicated from Ankit Sharma original https://aws.amazon.com/blogs/devops/amazon-q-developer-end-of-support-announcement/
When we launched Amazon Q Developer, our goal was to bring AI assistance directly into the developer workflow. Customers adopted Q Developer across VS Code, JetBrains, Eclipse, and Visual Studio, using it for code generation, debugging, and chat-based guidance. Q Developer proved that AI belongs in the inner loop of software development.
Over the past year, we’ve learned that the most impactful AI developer experiences go far beyond code generation and completion. Developers need AI that understands their entire project: the architecture, the requirements, the tests, and the intent behind the code. It requires a purpose-built environment. That’s why we built Kiro.
What is Kiro? Kiro is an agentic development environment (IDE, CLI) built from the ground up for spec-driven development. Instead of reacting to individual prompts, Kiro works from structured specifications to plan, implement, and verify changes across your entire codebase. Key capabilities include:
- Specs — Define what you want to build in structured, natural-language requirements that Kiro uses to drive implementation end to end.
- Hooks — Automated triggers that run on file save, commit, or other events to enforce standards, run tests, or update documentation without manual intervention.
- Steering files — Project-level configuration that gives Kiro persistent context about your architecture, conventions, and constraints.
- Custom subagents — Specialized AI agents you define for domain-specific tasks like security review, API contract validation, or infrastructure provisioning.
- Powers — Composable capability modules that extend Kiro’s agentic behavior for your specific workflows.
Kiro also includes everything developers rely on in Q Developer today: agentic coding, inline chat, terminal integration, and MCP support.
What’s changing Amazon Q Developer IDE plugins and paid Subscriptions will reach end of support on April 30, 2027, giving customers 12 months to transition to Kiro.
- New signups will no longer available starting May 15, 2026. New Q Developer Free Tier account creation (via Builder ID in IDE plugins) and new Q Developer subscription creation (via the AWS Console) will be blocked.
- Model changes: starting May 29, 2026, Opus 4.6 will no longer be available on Q Developer Pro. Opus 4.5 and all other existing models remain available. The latest coding models, including Opus 4.7, are available exclusively on Kiro.
- Existing customers retain access. If you access Q Developer via a Q Developer Pro subscription or Kiro subscription, you will continue to have access to the Q Developer IDE plugins until April 30, 2027. The May 15, 2026 change affects new signups for Q Developer accounts and subscriptions.
- IDE plugin listings remain live. Q Developer plugins will remain published on all four IDE marketplaces with a deprecation notice directing users to Kiro. Critical bugfixes will continue to be pushed to existing users through the transition window.
What’s not changing Amazon Q Developer in the AWS Management Console and first-party AWS experiences (AWS Marketing Website, AWS Documentation Website, AWS Console Mobile App, and Amazon Q Developer for Chat Apps – Slack & Microsoft Teams) are not impacted by this sunset and will continue to be available to AWS customers. Customers using Q Developer in these products will retain access to their current subscription benefits and capabilities.
What you should do
- Explore Kiro today. Download Kiro at kiro.dev and try spec-driven development on your next project.
- Review the migration guide for your specific IDE.
- If you have questions about migrating, contact your AWS account team.
We’re excited about the future of AI-powered development and we’re committed to making this transition as smooth as possible for every customer.
Промените, които носи AI
Post Syndicated from Григор original http://www.gatchev.info/blog/?p=2695
Писал съм и преди за тях. Отначало колебливо – чувствах се неадекватен фантазьор. Но напоследък все повече хора пишат същото или части от него. Ето поредната статия по темата:
https://shumer.dev/something-big-is-happening
И реших, че е добре да напиша нещо полезно за който има акъл. Който не чете дълги неща – за него си е, мога да му кусна в устата, но не и да глътна вместо него. И да не ми циври после, че не е знаел навреме.
—-
1. Технологичните революции
AI не е първата технологична революция на човечеството. Преди него бяха компютрите. Преди тях – атомът. Електричеството. Парата. Индустрията… Та чак до стиснатия в питекантропския юмрук камък.
Не, всъщност преди това – слизането от дърветата. Не, всъщност още преди това – качването на тях… До първата жива клетка. Всяка еволюционна промяна е по същество технологична революция, и обратното. Много различно ли е за един хомо хабилис умението да издяла каменен нож от еволюцията да му поникнат страшни зъби?
А технологичните революции не са милостиви. При индустриалната по света са измрели от глад и мизерия милиони селяни, ненаучили се да са работници. Десетки милиони са потънали в мизерия, когато електричеството е изместило парата. Световна атомна война ни се размина, но знаем какво би причинила атомна бомба дори на могъща и добре подготвена армия от 1940-те, за милионен град да не говорим. Компютрите оставиха без работа стотици милиони „сини якички“… Винаги по една и съща причина – неподготвените за новото остават излишни.
В по-нови времена – все повече по свой избор. Крепостните селяни не се учеха да четат, понеже книгата хляб не раждала. „Сините якички“ не учеха компютри, за да не си развалят очите. И едните, и другите разбраха грешката си по трудния начин и платиха за нея с късен и лош старт. С тези, които днес не учат AI, ще е същото.
Много от тях са убедени, че работа за фермери, зидари и готвачи ще има винаги. Същото мислеха орачите преди тракторите, преписвачите на книги – преди печатарската преса, каруцарите – преди колите… А колко професии го мислеха преди компютрите – да изброявам ли?
Новото не само унищожава работни места. Обикновено и създава нови, често напълно неочаквани, и често още повече от унищожените. Но каймака го обират първите пренаучили се. За другите остава утайката, ако изобщо я има. Изберете си от кои искате да бъдете.
2. Този път е различно!
Точно така са мислели и орачите преди тракторите, преписвачите преди печатарската преса и т.н. Всеки път е било същото, просто те не са искали да го разберат, защото не са били на кеф. И са си плащали после.
Само че този път наистина е различно. Проблемът е, че не по добрия начин.
Един трактор заменя десетки орачи, но не оре без тракторист. Първите орачи, които се научат да го карат, живеят по-охолно отпреди. Печатарските преси също не могат без работници. Камионите без шофьори. Компютрите – без работещи на тях… Често много по-малко от заменените, особено отначало, но все пак хора.
Тук е разликата. AI все повече нямат нужда от оператор – вършат все по-добре работата му и сами. Вече сме не просто на ръба AI да може да изпълни задача или да отговори на въпрос по-добре от всеки човек. На ръба сме той да може да формулира задачата или да зададе въпроса по-добре от всеки човек.
Ама и AI имат нужда някой да пише софтуера им? Също вече не. Последните версии на почти всички големи AI са написани предимно от предишните им версии. Скокът във възможностите им се дължи предимно на това. И тези много по-добри последни версии в момента пишат следващите, още по-добри от тях, с още по-голяма разлика. Последният модел на Anthropic – Mythos – вече е далеч по-добър и от най-добрите програмисти в софтуерните задачи. Толкова по-добър, че засега е непубличен, за да не откриват чрез него хакери екплойти в дори смятани сега за непробиваеми софтуери… Познайте дали не е също толкова по-добър от сегашните модели и в други отношения. Подобренията, влезли в него, няма как да са само в един вид умения, LLM-ите не работят така – ще са във всички.
В софтуера нещата са най-напред. Не толкова защото ударението по създаване на AI беше там – по-скоро защото програмните езици са силно формализирани, простички и детерминистични, с тях AI се справя по-добре с едни и същи ресурси. Но и във всичко друго нещата не са много по-назад – да кажем, едно-две поколения модели. Сега актуалният публичен модел на Anthropic – Opus – е в софтуера на нивото на приличен, макар и не блестящ програмист, а примерно в разбирането на човешките чувства – където предишният им модел, Sonnet, е в програмирането. Mythos надмина дори отличните програмисти в софтуера, по-добри от него са само гениите – логично е в разбирането на човешките чувства да е на нивото на Opus в програмирането. Все още не блестящ, но вече добър, на нивото на Opus в софтуера.
Конкуренцията между големите AI фирми е безмилостна – която изостане и с месец, почва да трупа изоставане и потегля към фалита. Така че Mythos с гаранция вече пише на максимални обороти следващия модел. Който ще има програмистки умения, много по-добри от това на написалия го, надминаващи тези и на гениите програмисти. (Терминът за такова ниво е “transhuman”.) Познайте и в колко други неща ще надмине повечето хора този следващ модел. По-следващият вероятно ще надмине във всичко или почти всичко всеки човек, освен може би гениите в най-трудните за AI области. Този след него ще надмине хората в абсолютно всичко… А следващият след него? А по-следващият?…
Преди ново поколение AI модел се създаваше от нула до зрялост за към две години, първите версии на ChatGPT отнемаха към толкова. При Sonnet това отне дори мъничко по-малко от година, 11 месеца и половина. Opus измина този път само за около 9 месеца – Sonnet вече що-годе ставаше за програмиране и помагаше, към една трета от Opus е написана от него или с негова помощ. Mythos (по непублична информация) вече е почти зрял, по-малко от 5 месеца след започването му – вероятно ще измине този път за около 6 месеца, и разликата от него до Opus е доста по-сериозна от тази от Opus до Sonnet. Благодарение основно на това, че Opus вече е приличен програмист, твърди се, че към две трети от Mythos са написани от него… Следващият модел, да го наречем условно Legend (Антропик, безплатна идея за вас!
), като се има предвид колко добър е Mythos, вероятно ще е написан почти изцяло от него, вероятно ще има още по-голямо предимство пред предшественика си, и вероятно ще е вече зрял след 3-4 месеца. (Дотогава нищо чудно Mythos да е още непубличен.) По-следващият, да го наречем условно Superman, вероятно ще е с още по-голяма разлика от Legend, и ще е готов може би за 3 месеца или дори малко по-малко. А моделът след него вероятно ще е богоподобен на фона дори на Superman, ще стане готов за вероятно не повече от 2-2.5 месеца и вероятно ще е най-подходящо да го наречем God… Quo vadis – накъде отиваме? Може би до не повече от година?
2027 година е. Шеф сте на софтуерна фирма. Legend програмира много по-добре от кой да е реално привлекаем жив програмист. Конкурентите му от OpenAI, Google и прочее – също. Достъп до AI, който върши работата на 100 програмисти – с перфектно качество, винаги в срок, никога не боледува, няма проблеми, не взима отпуски, работи 24/7 – ще към 1000 долара месечно, стандартна корпоративна цена сега. Ще държите ли на работа 100 програмисти, или ще купите един такъв достъп? Глупав въпрос, нали?
Три до шест месеца след това. Актуалният модел на Antropic вече е Superman. Шеф сте на компания за какъв ще да е интелектуален труд. Дизайн, инженерство, архитектура, песни, книги, филми, наука, право, счетоводство, медицина, обучение… добавете пропуснатото. Достъп до AI, който върши работата на 100 служители… глупав въпрос, нали?
Още три до шест месеца по-късно. Актуалният модел на Antropic вече е God. Шеф сте на компания за какъвто и да е физически труд. Строителни услуги, хамаллък, садене на марули, бране на ябълки, продаване в магазин, гледане на болни, планинско спасяване, развличане на деца, метене на улици… добавете пропуснатото. Вече има машини – някои от тях човекоподобни роботи, други специализирани – проектирани, произведени и управлявани от God или конкурентите му. Достъп до машина или набор машини, които вършат работата на 100 бачкатори… глупав въпрос, нали?
Да, досега проектирането, изпитването и производството на толкова нови и много машини е отнемало десетки години. Познайте обаче колко време ще отнеме на God, или на следващия след него модел, или на по-следващия, готов след година – година и половина. Вероятно след броени години ще има достатъчно такива машини, за да изместят всеки човек.
Тази екстраполация е базирана на Sonet, Opus и Mythos. Sonnet и Opus ги познавам добре. Възможно ли е да са ми прехвалили Mythos, както не мога да се уверя лично? Да – но надали с много. Че е достъпен засега само за 12 големи, предимно софтуерни организации, точно заради брилянтността му в софтуера, е потвърден факт. (Намира с лекота купища експлойти и в най-сигурните сегашни софтуер – докопат ли го хакерите, в света ще настане хаос.) Така че темпото на развитие би могло да е малко по-бавно, може би чак двукратно, но не повече. А двукратно по-бавно означава масовите уволнения заради изместване от AI да се случат след 2 години вместо след 1. Ако това ви успокоява, сте герои от виц. Недейте, скоро и с палячовство няма да може да се изкарва доход, смешни наоколо ще има в излишък.
И да, публикуването на нов модел очевидно може да бъде забавено по едни или други причини. Но засега няма механизъм, който ще забави разработката на нови модели, дори ако старите още не са публикувани. Не само заради конкуренцията между AI фирмите. Коя агенция за сигурност на държавата ще позволи развитието на нейните AI да бъде спряно, докато в това време потенциалните ѝ врагове развиват AI като бесни?… И когато поредният модел стане способен да създаде лекарство против рак и да забави или дори спре стареенето, надали ще бъде скрит за дълго, примерно за цяла година – който го скрие, ще е заслужил каквото всички извършители на геноцид в историята заедно не са. Така че забавяния може да има, но надали ще са много големи.
Мислите иначе ли? За такива неща мислят глупавите, умните смятат. Ако можете да смятате, направете си и вие сметките колко бързо пътува този влак и им вярвайте. Ако не, вярвайте на който може да смята. Иначе ще сте урок за по-умните.
Ще станат ли хората непотребни? Надали. Нищо чудно добри решения по въпроса да дойдат именно от AI-та. Но се пригответе да живеете скоро в свят, различен от сегашния.
3. Икономическите последствия
2027-8-9 година е. Шеф сте на фирма. Конкуренцията ви е подменила част от служителите си с AI. Спестила е разходи за заплати, надконкурира ви. Какъв е изборът ви? Оставате шеф на фирма само ако направите същото. Иначе фалирате.
Правите го. Отново сте в бизнеса. Но там винаги има и най-неконкурентен, влак без последен вагон няма как. Какъв е изборът му? Подменя още служители с AI, иначе фалира. Последният вагон е откачен и изоставен или преместен напред – последен става този преди него…
Скоро всички служители във фирми са подменени с AI. Малко по-късно и всички работници. Където преди са работели хиляди, сега има само шепичка шефове. За кратко – кой шеф може да бъде по-кадърен и лоялен от от поколението Superman, да не говорим за God?… Много скоро след това фирмите имат вече само собственици. А конкуренцията между тях не спира – най-неуспешните фалират, други ги изкупуват, агрегацията тече с AI скорост. Докато се огледате, наоколо са останали един файтон свръхбогаташи, всички други са разорени.
Харесва ли ви идеята? „Ако съм свръхбогаташ – да!“ Да, ама не – спали сте в час по икономика. Нека наваксаме проспаното.
Заводите „Форд“ в САЩ са ваши. Произвеждате и продавате по 10 милиона коли годишно. Марджинът ви е 5%, при 400 милиарда годишен оборот печелите 20 милиарда годишно. Но подменяте всичките си работници с AI и марджинът ви става заради спестените заплати 50%. Годишната ви печалба ще е 200 милиарда, десетократно по-голяма. Шампанско, моля! И нови яхти!
Но месец по-късно от почти милион коли месечно продажбите ви са спаднали на към 2000. Годишно ще са 24 000, и годишната ви печалба е станала вместо 200 милиарда годишно към 500 милиона. Вместо да скочи 10 пъти, е паднала 40 пъти. Защото всеки фирмаджия в САЩ е постъпил като вас – подменил е с AI всичките си работници или служители. И те, останали без заплати, вече не могат да си позволят да купуват коли. Правят го само малкото все още работещи, заради връзки или по милост, в държавната и общински администрации.
Докато се опомните от вестта, AI-шефът на заводите ви предупреждава и че обемът на покупките ви на материали, ток и всичко друго е спаднал драстично. Така че вече пазарувате на доста по-дребно и доставните ви цени са скочили с 20%. Поемете ли вие разликата, марджинът ви слиза на 30%, печалбата – на 300 милиона годишно, вече почти сто пъти по-малка отпреди подмяната. Качите ли цените си с 20%, продажбите ще спаднат и още, обемът на покупките ви на материали също, цените им ще скочат още – бизнесът ви влиза в свредел.
Нямате избор. Орязвате печалбата си. Все пак 300 милиона годишно пак са много в такава ужасна криза. (Че тая криза я създаде подмяната на работници с AI, в която участвахте и вие, предпочитате да не си спомняте.) Но много скоро иде нов удар – продажбите на практика спират. Заради 100 пъти намалената ви печалба сте платили 100 пъти по-малко данък и държавната и общински администрации, които живеят от данъците, вече не могат да плащат заплати. Подменили са служителите си с AI и те също вече не могат да купуват коли… Дори да спрете производството напълно, вече не можете да плащате дори на фирмата за роботи-охранители с AI. Налага се да продадете заводите си, докато крадците не са ги опоскали и времето не ги е съсипало.
А на кого? Всички други големи фирми са също във фалит. Даже фирмите зад големите AI – могат да устискат на сериозно намаление на приходите си, но не и на спадане до 1%, а вече няма кой да може да им плати и толкова. Банките са фалирали до една заради трилионите заеми за жилища и прочее, които са станали необслужваеми – останалите без заплати заемополучатели нямат с какво да плащат вноските си. А ликвидността на една банка рядко е над 20% – ако над такъв процент заеми гръмнат, гръмва тя цялата… Чудо ще е, ако за заводите ви, стрували стотици милиарди, сега някой ви даде и милион. Вече не сте мултимилиардер – надали сте и милионер даже.
Да кажем, чудото се е случило, успели сте да намерите такъв. Все пак сте взели един милион. Но какво ще си купите с него? Магазините са затворени – кой има пари, че да купи каквото и да е?! Бившите свръхбогаташи сте единици, а останалите нямат пукнат цент. Същото важи за всички услуги – транспорт, бензиностанции, ток… Фермерите, които още имат земя и машини, вече искат да произвеждат храна само за себе си – но откъде части и гориво дори за това?!… И вече се чудите не на коя от яхтите си да празнувате, а как да се нахраните.
Икономиката е кръговрат. Произвеждате стоки или услуги, продавате, плащате на работниците, те с тези пари си купуват стоки и услуги. Не е перпетуум мобиле, защото етапът на производството в този кръг създава повече стойност, отколкото консумира. Така че върти ли се кръгът, производството непрекъснато създава принадена стойност, плюс над разходите, и тя се разпределя навсякъде в кръга. Има и за покриване на неизбежните загуби, и за данъци, и за вашата и на работниците издръжка, и за тях да спестяват, и за вас да богатеете – тоест, за да расте икономиката като цяло… Но спре ли да се върти кръгът, примерно защото работниците вече нямат пари да купуват, спира и производството, а оттам и създаването на принадена стойност. Приходите стават нулеви. Вчерашните мултимилиардери почват да умират от глад. А някои от неизбежните разходи продължават и унищожават и останалото от спрялата икономика.
(Този механизъм, в много по-лек вариант, е причината за Великата депресия от 1929 г. Вярването в trickle-down теорията и дерегулацията, неглижирането на антитръстовските закони и на опасността от растящото икономическо неравенство създават условия много от парите в обществото да бъдат изтеглени „горе“, при най-богатите. Те обаче са нищожен процент, техните потребителски нужди са нищожни на фона на тези на хиляди пъти по-многобройните средна класа и по-бедни. Създава се ситуация, в която който има нужда от стоки и услуги няма достатъчно пари да купува, а който има достатъчно пари, няма достатъчно нужда от покупки. Потреблението спада с около 30%, производството – БВП на САЩ – също. Резултатът е незапомнена безработица и мизерия. От 30% спад в потреблението. А спадът в потреблението заради AI революцията вероятно ще е много по-голям, теоретично може да доближи 100%…)
4. Справяне с икономическите последствия
Ще бъдат ли взети мерки да се избегне катастрофата? Вероятно да – както виждаме, дори свръхбогаташите имат нужда от тях, и то повече от клошарите или даже работниците. Не е сигурно обаче дали ще са взети достатъчно и с достатъчно ефект.
Ефективните срещу такъв проблем мерки са видове преразпределяне на парите откъдето са се концентрирали силно към където има капацитет за масово потребление. Ляво правителство е по-вероятно да предприеме достатъчни, за да не рухне икономиката. (Въпреки че и тези правителства обикновено имат задкулисни връзки с големите пари, които ще ги спират.) Дясно може да прояви разум и да се жертва, но може и да не вземе достатъчно и/или ефективни. А реакционери и/или политически измамници с мераци за корони и тронове вероятно дори ще се възползват от ситуацията, за да се сдобият с абсолютна власт. (Великата депресия е основна причина за мизерията в Германия през 1930-те, която докарва Хитлер на власт.) Ако сред тях има и собственици на големи AI, изкушението те да бъдат използвани за установяване на технототалитарен абсолютен контрол е много силно, и рискът за това общество е огромен.
Какви общества имат най-голям шанс да се справят добре с такава икономическа ситуация? Няма как да се предскаже с гаранция. Но при равни други условия най-добри шансове имат социални общества със силна либерална демокрация, кадърна регулация на AI бизнеса, ниска корупция, високо грамотен народ и към този момент с кадърно и не-популистко лявоцентристко правителство.
Ще има ли не само на теория, а и в реалността необходимото осъзнаване сред ключовите играчи на необходимостта да бъде запазена покупателната способност на масовите потребители? Някои дори вече го заявяват открито – примерно съм срещал подобни твърдения на Илон Мъск. Много други засега не са го казвали, но е малко вероятно да не го разбират. Някои обаче вероятно не го разбират и ще противодействат на адекватните мерки, особено твърде обвързаните с десни идеологии. (Идеологията на мозъка е тежък вид лудост. Не я подценявайте.)
Какви механизми могат да реализират нужното? Най-често обсъжданата и най-проста идея е безусловен базов доход за всички. Тя обаче има сериозен недостатък – би създала уравновиловка в обществото, а изравненото икономически общество не е добро за развитието. За него е нужен спектър на богатството – не прекалено широк и маргинализиран, но не и прекалено тесен. (Едно по-сериозно отърсване на икономиката от идеологиите и създаване в нея на нетърпимост към тях вероятно би позволило на кадърни учени и/или мощни AI да изведат формулите за определяне на оптималното за всяка икономическа ситуация разпределение на богатството в обществото. Но ще е трудно да се постигне, през последните няколко години икономиката се идеологизира до екстремна степен.) Така че вероятно ще е нужно да се помисли за подходящи механизми, способни да разпределят богатството в обществото по определен спектър, и да променят този спектър при икономическа необходимост.
Какви биха били ключовите проблеми пред това реализиране? Икономиката е ентропийна отворена система, подчиняваща се на статистическата механика. В такава система негентропията проявява тенденция към концентриране към „входящата зона“. Казано икономически, парите проявяват тенденция към концентриране в зоната, където принадената стойност навлиза в системата. По начало това е зоната, в която тя се създава – производството. Законодателни или икономически мерки могат да я изместят другаде, примерно в зоната на управление на потока на парите (банковата система). Силна мафия може да я измести в зоната на върхушката си, чрез грабителство. (Или ако контролира държавата – дори чрез подходящо законодателство.) Но където и да е тази зона, парите ще се опитват да се концентрират там. А концентрирането им ще се стреми да намали зоната до малка част от икономическата система.
На теория мерки, които поддържат зоната на навлизане на принадената стойност разпределена на много широка площ (включваща всичкия или почти всичкия капацитет за консумиране в икономиката), биха били оптимални в такава ситуация. Такива мерки обаче засега не са известни. Вероятно достатъчно мощен AI би могъл да предложи подходящи. Поддържането на тази зона много широка обаче е противостоене на естествената ѝ тенденция за свиване – възможно е да се окаже, че няма как да се направи достатъчно стабилно, за да издържа силни сътресения. А технологичните революции са именно такива, и при такава скорост на развитието ще са много чести.
На практика по-лесно се оказва парите в икономиката да бъдат преразпределяни от зоната, където се концентрират, към зоните с максимален потребителски капацитет. (Примерно богатите биват облагани с високи данъци, от които печелят всички – така икономическото неравенство продължава да съществува, но намалява като размер.) Известни са ни приличен брой такива механизми. Много от тях обаче имат сериозни недостатъци, например данъчното облагане често може да бъде изкривявано чрез заобикаляне на закона или вратички в него. Други начини, например разчитащите на фиксирана номенклатура, е възможно да стагнират развитието на икономиката, а може би и на технологиите и прогреса…
Като цяло, идеални мерки вероятно няма, дори за конкретно тази специфична ситуация. Но е напълно реално да има мерки, които при достатъчно широко и сериозно прилагане са достатъчно добри, за да намалят размера на икономическите проблеми до приемлив. Въпросът е дали ще бъдат приложени, и ако да – дали ще е достатъчно широко и сериозно.
5. Социалните последствия
Слагал ли е ваш колега гордо пред шефа 20 страници красив доклад, пълен с графики и прочее, как върви строежът, за който отговаря във фирмата той? Написан за една нощ с помощта на AI? Докато вие подсмърчате и се червите, понеже не умеете да се справяте с AI и докладът ви за вашия строеж е пет изречения? И разбирате отлично как изглежда в очите и на шефа, и на всички околни той, а как – вие? Не е малка разлика, нали?
(Да, докладът му вероятно хич не е идеален, съвременните AI не са още истински добри в това. Но шефът надали ще го разбере – вероятно ще накара някое AI да му го синтезира в пет изречения. Колкото е и вашият – но впечатлението от разликата ще остане… А и да забележак проблемите в доклада му, впечатлението е важното в тази история само за плиткоумните. Истински важното е, че той се е потил много часове, но се е научил как се правят хубави доклади с AI, а вие не сте. И занапред той ще посвещава още много часове за учене и трупане на нови знания и умения, често на цената на лишения и недоспиване. Докато вие най-много да научите как да правите с AI смешни картинки и какви са връзките между чакрите и предсказанията на баба Ванга. Защото толкова зор ще си дадете.)
Разликата изглежда голяма, но е микроскопична. След година-две този колега ще сложи пред шефа 20 000 страници (вероятно в електронен вид) проект за бъдещия ви строеж, подробен до последното кабарче по мебелите, перфектен във всяко отношение. Също направен за една нощ с AI, от актуалното след година поколение, преди вие да сте прочели докрай 20-те страници спецификация. След още година той за седмица не само ще направи проекта, но и ще построи сградата сам, с управлявани от AI ресурси, наети за една трета от стойността на работници. А след още година ще реализира сам със същата скорост и икономичност цели подводни или орбитални градове, Фулърови куполи или аркологии, мостове през морета или тунели под тях… Докато вие тепърва ще учите как се правят с някое чатджипити презентации и други подобни, от които вече никой не се интересува. Колко голяма на този фон е разликата с 20-страничния доклад?
Не бързайте да се депресирате, ей сега ще имате по-добър повод. Срещате тогава колегата и в разговора с него откривате, че той знае как точно се настройват резонансните струни на виола д’аморе. Може да нарисува по-добре от Леонардо изглед към Матерхорн от ледника Теодул. Да каже как точно ще се сгънат белтъчните молекули в хемоцианиновия комплекс в кръвта на краб-пътешественик, ако му инжектирате еди-кой си хемотоксин. Да докаже конектурата на Поанкаре по-елегантно от Перелман, за само няколко минути. Да разгроми на шах най-добрите сто шахматисти хора на света, в сеанс на едновременна игра срещу всичките. Да напише поезия, по-добра от тази на Верлен, на ведически санскрит или инупиак. И че е по-добър психолог и от гениите – може да разбере по едно ваше движение всичко, което ви безпокои, да ви предскаже перфектно, да ви манипулира за ваше добро или зло, по негов избор… Защото си е присадил имплант за връзка с AI, или се е научил да може всичко това по някакъв друг, дошъл от AI начин. А вие не сте.
Депресирахте ли се вече? Пак бързате. Той не само изглежда подмладен, отслабнал и с по-правилно лице. Наистина е – вече може да управлява просто с мисъл не само външността, а и възрастта си, старее само ако му се иска, подмладява се обратно когато му кефне, реално е безсмъртен. Вече никакви болести не го плашат не защото има лечения за тях, а защото организмът му вече не е податлив на тях. Може да вдигне тонове с една ръка и да улови с два пръста летяща муха със затворени очи, само по слух. Може да се гмурне до дъното на океана без да диша няколко часа и без да му пречат налягането, студът и тъмнината там. Ако изпразнят в него няколко картечни ленти, не само няма да умре на място, а след седмица-две дори без лечение ще е пак идеално здрав. И това е само началото на възможностите му. А всички те заедно са само началото на това, което ще може утре… Докато вие въздишате заради бръчките и белите си косми.
Ще стане ли всичко това за само две години? Може би не, дори въпреки скоростта на развитие на AI. Но и двайсет да отнеме, ще стане. И познайте колко ще ви утеши тогава, че е отнело по-дълго. Колегата ще пътува във влака към бъдещето, към нови и все по-невероятни чудеса. А вие ще сте останали на спирка, която за него ще е дори не Средновековие, а Питекантропие – и много скоро може да стане и Динозаврие…
Обществото ще се раздели на две групи. Група, която смогва да е актуална с развитието на технологиите, може би на цената на огромен труд и много жертви, но хората в нея сами определят съдбата си и са боговете на този свят на бъдещето. И група, която не смогва или се е отказала да е актуална, която просто се вози докъдето я закарат, и съдбата на хората в нея я определя първата група – реално те са неин добитък. Да, първата група може и да са добри към втората. Но дали ще го правят според интересите на тези във втората група, или според своите, е въпрос който е добре да си зададете.
В коя от двете групи ще сте, зависи от вас. Правите този избор в момента, с колко усилия ще посветите на учене на AI. Предупредени сте – не се оплаквайте, когато се окажете не в която група искате. Направите ли от мързел и/или глупост грешния избор, се сърдете на себе си. И ако собствените ви деца ви заплюят утре в очите, знайте, че сте го заслужили.
6. Добре, а какво да правим?
Въпросът за много повече от един милион долара.
Вече има сума ти статии по въпроса, и повечето казват едно и също. Можете да им вярвате, ако не идват от пропагандна радиоточка. Бих добавил и от мен:
– Стегнете си финансите. Веднага, не догодина. Нищо, че вече е трудно – то е, защото нещата вече се движат по нанадолнището, не ги чакайте и да наберат скорост, тогава хич няма да можете. Колко сериозни сътресения ни чакат не е ясно. Може почти да ги няма. Може да са зловещи. Когато има приличен шанс да завали пороен дъжд, е разумно да си вземеш чадър. Пък нека дъждът се размине.
– Въпросът „Какво да науча, че да ме храни следващите 10 години“ вече е индикатор за идиот. Учете каквото ще ви храни веднага, или почти веднага – ще остарее още преди да го научите. Свикнете непрекъснато да учите и непрекъснато да сменяте каквото учите, често драстично, изоставяйки плода на огромни усилия. Могъщите динозаври са измрели, защото не са се адаптирали достатъчно. Мишеподобните бозайници са оцелели, защото са.
– Днес AI не е съвършен – халюцинира, дава грешни съвети. Утре ще е много по-умен, и от днес, и от вас. Не го съдете по спомените си от днес или особено пък от вчера. Да мислите зрял юначага за бебето, което е бил, е неразумно подценяване.
– До 10-15 години, ако не се случи някакво ужасяващо бедствие, ще са възможни неща които днес изглеждат фантазия. Но ще са за който може да си ги позволи, а отначало това няма да е всеки. По-добре да можете, с пари или знания. И двете се постигат днес със здраво учене на AI.
– Учете не само как да работите с AI, а и как работи самият той. Да можете да се возите в кола не е ценност за никой, който би ви плащал. Ценност е да можете да карате кола по-добре от 99% от хората или да можете да ремонтирате или сглобите кола.
– Учете не по два часа седмично – по четири часа дневно, поне 6 дни седмично. Не от след месец – от днес, след месец вече хубавите вагони в този влака ще са заминали, а може би и лошите.
– Непрекъснато се напъвайте да научите и още, да пробвате и каквото не сте. Денят, в който си кажете „Научих достатъчно за днес“, е денят в който сте слезли от влака. Ако си казвате за нещо „Много зор ще е, но мога да го науча“, значи е важно за учене, но не е най-важното. Най-важното за учене е това, за което си казвате: „Това посмъртно не мога да го науча“ – подхващайте го веднага и без колебание.
– Каквото сте научили днес, утре вече няма да е същото, познанията ви ще са остарели до безполезност. Нормално е, възприемайте го като нещо естествено. Пренаучавайте се моментално, оставяйте днешното учене за утре само ако искате то вече да няма смисъл.
– Колкото по-напред отиват нещата, толкова повече и по-здраво учене ще ви трябва, за да не слезете от влака. Където слезете там ще останете, друг влак напред няма да има. А влакът е все по-бърз, малко допълнителен престой в него ви откарва доста по-напред, по-нататък – повече. Струва си да се напънете докрай.
– Колкото по-дълго се задържите на влака, толкова повече възможности ще имате. Ако нещата вървят с този темп, до максимум 10 години хората ще се разделят на „магьосници“ и „добитък“. В първата ще са задържалите се във влака достатъчно дълго. Във втората – останалите над 99%. Сетете се каква ще е разликата между двете, примерно в какво ще могат тези в едната и тези в другата група, и защо е добре да сте в първата.
– Вероятно с времето ще почне да има и AI с „открити познания“ (а и код на софтуера, който ги движи). Предпочитайте ги пред „закритите“ – точно както разумният човек предпочита софтуера с отворен код пред този със затворен, и откритите хора пред потайните. (Ако някой мисли иначе, не спорете с него. Умствените ресурси са ви нужни за учене на AI, не ги пилейте. Идиотите са за игнориране, не за спорене с тях.)
– Ако от някой момент нататък стане невъзможно да сте във влака без неща като мозъчни импланти и подобни, бъдете внимателни. Не ги ли вземете, изпадате. Вземете ли ги безразсъдно, ще ви се иска да бяхте изпаднали. Преценете как да го направите без риск за автокефалността си. Главата ви е за да носите шапка само ако сте плашило – на хората им е за мислене. И е полезно да я товарите здраво, и за нея, и за вас. Вид тренировка е.
– Същото важи изобщо за използването на AI. Дори да сте реалист и факт-чекър, мощта на днешен добър AI вече може да ви обамбузи здраво, ако му вярвате безпрекословно. Примерно ако сте се чули някога да кажете „Ама аз питах чатджипити!“. (И дори ако зад това не стои нечие намерение, а просто усилените през неговото богатство ваши си деформации.) Утрешните AI ще са несравнимо по-мощни – не ставайте нечии зомбита, не е живот.
Could Anti-gravity Really be Possible?
Post Syndicated from Curious Droid original https://www.youtube.com/watch?v=bZELRhrzaOg
Enhancing network observability with new AWS Outposts racks LAG metrics
Post Syndicated from Adam Duffield original https://aws.amazon.com/blogs/compute/enhancing-network-observability-with-new-aws-outposts-racks-lag-metrics/
When you deploy AWS Outposts racks, you can run AWS infrastructure and services in on-premises locations. Maintaining seamless connectivity, both to the AWS Region and your on-premises network, is fundamental to delivering consistent, uninterrupted service to your applications. Implementing an observability strategy that uses available network metrics is key to understanding the health of this connectivity.
In August 2025, we launched two new Amazon CloudWatch metrics, VifConnectionStatus and VifBgpSessionState, that helped provide greater visibility into these Layer 3 networking constructs. However, insight into Layer 2 networking was still missing. AWS has released a new metric LagStatus, that provides greater visibility into the hybrid infrastructure connectivity for both first-generation and second-generation Outpost racks.
Link aggregation group overview
Link aggregation combines multiple physical Ethernet connections into one logical link, referred to as a link aggregation group (LAG). This consolidation delivers benefits such as increased aggregate bandwidth and built-in redundancy through fault-tolerant connections between network devices. AWS Outposts uses LAG connections between Outpost network devices (ONDs) and customer network devices (CNDs). The links from each Outpost network device are aggregated into an Ethernet LAG to represent a single network connection.
Figure : Second-Generation Outposts Rack network connections
Each LAG between an Outpost network device and a customer local network device is configured as an IEEE 802.1q Ethernet trunk. This enables the use of multiple VLANs for network segmentation between data paths. Each Outpost has the following VLANs to communicate with local network devices:
- Service link VLAN – Enables communication between the Outpost and customer network devices to establish a service link path to the AWS Region.
- Local gateway VLAN(s) – (If exists, and as single or multiple LGW routing domains), enables communication between Outpost and the customer network devices to establish a local gateway path to connect your Outpost subnets to the local area network.
Figure : Second-Generation Outposts Rack VLAN layout
Using the LagStatus metric
The new LagStatus metric in CloudWatch provides visibility into the operational status of LAG connections between Outposts networking devices and on-premises infrastructure. The metric reports a binary status (1 for the LAG being UP, 0 for the LAG being down) and includes the OutpostId and LagId as dimensions to quickly identify non-operational resources.
You can view this metric on the CloudWatch console. As with all operational telemetry, access to these metrics should be appropriately restricted to authorized principals. The metric data points are published at 5-minute intervals, and like all CloudWatch metrics, there might be a time lag in the metric data being published. In the navigation pane, choose All metrics, followed by Outposts under the AWS namespaces section. The Outposts namespace can only be viewed by the Outposts owner account, unless CloudWatch cross-account observability is configured.
Figure : CloudWatch Metrics view of the LagStatus metric
While the LagStatus metric alone provides insight into the Outposts network connectivity, combining it with VifConnectionStatus and VifBgpSessionState delivers more immediate, actionable insights that expedite troubleshooting. In addition, to improve the clarity of the existing metrics, the related LagID is added as a new Outposts metric dimension. By observing the values of all three metrics, you can narrow down the potential cause of any issues. The following table gives some possible connectivity issue scenarios and how they can be identified using these metrics:
| LagStatus | LGW BGP | ServiceLink BGP | Potential issue |
| UP | UP | UP | Recommended state – all components working |
| UP | UP | DOWN | ServiceLink BGP issue – configuration issue |
| UP | DOWN | UP | LGW BGP issue – configuration issue |
| UP | DOWN | DOWN | Both BGP sessions down – configuration issue |
| DOWN | DOWN | DOWN | Lag configuration issue or Physical failure |
With these metrics, you can use CloudWatch Composite Alarms to alert operational teams when any of the components aren’t running as expected.
To create a composite alarm, alarms must first be defined for all three of the individual metrics. This can be done from the console, CLI, or AWS CloudFormation. Following the principle of least privilege, ensure that IAM permissions are restricted to the minimum actions required for CloudWatch alarm creation. For more information, see the CloudWatch documentation. If you prefer, you can configure these individual alarms without notification actions enabled to reduce potential notification noise. Each virtual interface (VIF) has its own set of metrics, so you would need to configure alarms for all VIFs used with your Outpost. The number of total VIFs will vary depending on the Outpost generation that’s deployed because of the different networking architectures.
First-generation Outposts racks use four VIFs per rack (two for Service Link, two for Local Gateway). Second-generation racks require a minimum of eight VIFs (four for Service Link, four for Local Gateway), because they support multiple local gateway routing domains, each with its own VIFs.
An example alarm configuration as seen in the console for a single VIF is shown in the following figure 4.
Figure : Individual CloudWatch alarms for VIF status
After these individual alarms are created, a composite alarm can be created that monitors for any of the component metrics going into an alarm status. In the following example, the AWS Command Line Interface (AWS CLI) is used to create the composite alarm called composite-alarm-lag1 and send a notification using an Amazon Simple Notification Service (Amazon SNS) topic called outpost-network-alarms. As this topic carries infrastructure health data, it’s recommended to encrypt it using an AWS Key Management Service key and restrict the subscription policy to authorized principals.
You can use this granular monitoring to quickly identify and troubleshoot connectivity issues, particularly in scenarios where LAG status is up but VIF BGP status is down.
Conclusion
This post provides details about the newly released LagStatus CloudWatch metric, and how this metric can be used with existing metrics such as VifConnectionStatus and VifBgpSessionState to build a comprehensive network connectivity observability solution. The LagStatus metric is now available in all commercial AWS Regions and the AWS GovCloud (US-East) and AWS GovCloud (US-West) Regions where Outposts racks are available, for both first-generation and second-generation racks at no additional cost.
For more information about Outposts rack networking patterns, see the Networking section of the Outposts High Availability Design and Architecture Considerations whitepaper.
Reach out to your AWS account team, or fill out this form to learn more about observability for Outposts.
GL.iNet GL-RM10 Comet Pro Remote 4K KVM Review A Higher-End Tailscale Option
Post Syndicated from Patrick Kennedy original https://www.servethehome.com/gl-inet-gl-rm10-comet-pro-remote-kvm-review-a-higher-end-tailscale-option/
In our GL.iNet GL-RM10 review, we see why this upgraded model is perhaps the best remote KVM box on the market today
The post GL.iNet GL-RM10 Comet Pro Remote 4K KVM Review A Higher-End Tailscale Option appeared first on ServeTheHome.
You shouldn’t have to fear for your data. #shorts #SmartHome #HomeAutomation #privacy
Post Syndicated from Home Assistant original https://www.youtube.com/shorts/50kNgt9wx0g
AI Chatbots & Safeguards #lastweektonight
Post Syndicated from LastWeekTonight original https://www.youtube.com/shorts/2iEtkkja34Q
Bolivian Traffic Zebras: Last Week Tonight with John Oliver (Bonus Segments)
Post Syndicated from LastWeekTonight original https://www.youtube.com/watch?v=uZyKlCjpRmI
Serverless ICYMI Q1 2026
Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/serverless-icymi-q1-2026/
Stay current with the latest serverless innovations that can improve your applications. In this 32nd quarterly recap, discover the most impactful AWS serverless launches, features, and resources from Q1 2026 that you might have missed.
In case you missed our last ICYMI, check out what happened in Q4 2025.
Serverless with Mama J
Serverless with Mama J
If you really want to know whether you understand something, try explaining it to your mom!
That’s exactly what Eric Johnson did. His mom, everyone calls her Mama J, wanted to know what serverless actually means and why it matters. So he walked her through it: what servers do, why they’re a headache to manage, and how AWS Lambda lets you skip all that by running code only when it’s needed, scaling automatically, and charging you nothing when nobody’s using it.
Watch the video on the AWS Developers YouTube channel.
Build serverless apps faster with AI
AWS is providing a growing set of AI-powered tools to bring serverless expertise directly into your coding assistants. From Model Context Protocol (MCP) servers and Anthropic Claude plugins to Kiro Powers. These tools provide contextual guidance for architecture decisions, implementation patterns, and deployment automation across the full serverless development lifecycle.
For more information on the tools available, see the resources page.
Serverless Patterns Collection
The open source Serverless Patterns Collection on Serverless Land now provides a direct link to download pattern .zip files. You can also clone the whole repo and explore more patterns.
AWS Lambda
Build fault-tolerant, long-running applications using familiar programming patterns using AWS Lambda durable functions. You can use Lambda durable functions to write multi-step workflows in your preferred programming language, using built-in methods that automatically handle progress checkpointing and error recovery. This can improve your architecture so that you can focus on your business logic and optimize costs by charging only for active compute time.
You can build durable functions in Python and TypeScript and there is a durable execution SDK for Java in preview with the code available on GitHub.
Eric Johnson has a new video deep dive showing how to upload videos and scan them with AI. Learn how to coordinate multiple AWS services like Amazon Rekognition and Amazon Transcribe, implement human-in-the-loop approval workflows, and crate a live dashboard for real-time updates.
To find out how durable functions work, see the blog post which also provides testing and best practices guidance. You can also watch the re:Invent Breakout Session video: Deep Dive on AWS Lambda durable functions (CNS380)
Lambda now supports the .NET 10 runtime, including support for file-based apps. Developers can take advantage of the latest .NET 10 performance improvements, new language features, and improved startup times for Lambda functions.
You can now see Availability Zone (AZ) metadata in function execution environments. This allows you to determine the AZ ID (e.g., use1-az1) of the AZ your function is running in. This helps build functions that can make AZ-aware routing decisions, such as preferring same-AZ endpoints for downstream services to reduce cross-AZ latency. Operators can also implement AZ-aware resilience patterns like AZ-specific fault injection testing.
Payload size increase
AWS has increased the maximum payload size from 256 KB to 1 MB for a number of services such as asynchronous Lambda invocations, Amazon SQS, and Amazon EventBridge. This gives you more room to build and maintain context-rich event-driven systems and reduce the need for complex workarounds such as data chunking or external large object storage.
This blog post explores a real-world example using rich event context in agentic event-driven architectures
Amazon Bedrock
Amazon Bedrock expanded its model availability with a new set of fully managed open-weight models spanning frontier reasoning and agentic coding. Other model releases include Anthropic Claude Opus 4.6 and Claude Sonnet 4.6, and NVIDIA Nemotron 3 Super. You can invoke them through the unified Amazon Bedrock API without managing any underlying infrastructure, making it straightforward to experiment and swap models as your workload evolves.
Amazon Bedrock AgentCore is the infrastructure layer for securely deploying and operating AI agents. It works with popular open source frameworks, including Strands Agents, LangGraph and CrewAI, giving you the flexibility to build with your preferred tools without vendor lock-in.
AgentCore Gateway now includes semantic tool search, so you can discover the right tool for a task using natural language queries instead of manually browsing a catalogue. It also adds custom KMS encryption, debugging messages, and resource tagging to give you stronger governance over tool integrations.
Policy in Bedrock AgentCore allows you to define precise boundaries on agent actions and run continuous quality monitoring. This helps you maintain predictable, auditable agent behavior in production without embedding guardrail logic inside each individual agent.
AgentCore Runtime now supports stateful MCP server features, allowing agents to maintain session context across tool calls for richer, more coherent multi-step interactions.
Strands Agents
Strands Agents is an open source SDK for building and running AI agents in just a few lines of code, working with models available in Amazon Bedrock. Strands Labs is a new dedicated GitHub organization for experimental agent projects, including robotics and code agents. This gives you early access to cutting-edge agentic techniques before they reach production frameworks. See the introduction blog post for more information.
AWS Step Functions
AWS Step Functions introduces an enhanced TestState API that enables API-based testing for validating workflows before deployment. The new API supports testing individual states in isolation or complete workflows end-to-end, making it easier to verify state machine logic without incurring runtime costs.
By integrating TestState API testing into CI/CD pipelines, you can validate workflow logic before deployment, reducing the risk of production issues. Find complete code examples and testing framework in the GitHub repository.
Amazon EventBridge
Amazon EventBridge Scheduler now provides resource count metrics to help you monitor quota usage. These new metrics make it easier to track the number of schedules and schedule groups in your account and proactively manage service quotas.
Amazon DynamoDB
You can replicate Amazon DynamoDB table data across multiple AWS accounts and Regions. This enhances resiliency through account-level isolation, supports tailored security and data-perimeter controls. You can align workloads by business unit or environment and simplify governance requirements.
Amazon ECS
Amazon ECS Managed Instances can now integrate with Amazon EC2 Capacity Reservations. This allows you to make sure there is capacity availability for your container workloads while benefiting from the management automation of ECS Managed Instances.
ECS also now supports Network Load Balancer (NLB) for linear and canary deployment strategies. This helps you perform gradual traffic shifting using NLBs, providing more flexibility in deployment pipelines for latency-sensitive applications.
Serverless blog posts
January
- .NET 10 runtime now available in AWS Lambda
- Serverless ICYMI Q4 2025
- More room to build: serverless services now support payloads up to 1 MB
February
- Building fault-tolerant applications with AWS Lambda durable functions
- Optimizing Compute-Intensive Serverless Workloads with Multi-threaded Rust on AWS Lambda
March
- Enabling high availability of Amazon EC2 instances on AWS Outposts servers (Part 3)
- Testing Step Functions workflows: a guide to the enhanced TestState API
Serverless Office Hours
Join our livestream every Tuesday at 11 AM PT for live discussions, Q&A sessions, and deep dives into serverless technologies. Watch episodes on-demand at serverlessland.com/office-hours.
January
- Jan 7 – New: Amazon API Gateway response streaming
- Jan 14 – What’s New: AWS Lambda event source mappings
- Jan 21 – New: AWS Lambda tenant isolation
- Jan 28 – AWS Step Functions Local Testing
February
- Feb 4 – App Modernization with CDK Blueprints
- Feb 11 – Observability for Distributed Systems
- Feb 18 – AI & Java
- Feb 25 – AI for content creators
March
- Mar 11 – Serverless resilience: A practitioner’s guide
- Mar 18 – Analytics for Modern Data Lakes & AI
- Mar 24 – AWS MCP server
Still looking for more?
The Serverless landing page has overall information about building serverless applications. The Lambda resources page contains case studies, webinars, whitepapers, customer stories, reference architectures, and even more Getting Started tutorials.
You can also follow the Developer Advocacy team to see the latest news, follow conversations, and interact with the team.
- Julian Wood: @julian_wood, https://www.linkedin.com/in/julianrwood/
- Eric Johnson: @edjgeek, https://www.linkedin.com/in/singledigit/
- Erik Hanchet: @ErikCH, https://www.linkedin.com/in/erikhanchett/
- Salih Gueler: @salihgueler, https://www.linkedin.com/in/salihgueler/
- Marcia Villalba: @mavi888uy, https://www.linkedin.com/in/marciavillalba
And finally, visit Serverless Land for your serverless needs.
[$] Restartable sequences, TCMalloc, and Hyrum’s Law
Post Syndicated from corbet original https://lwn.net/Articles/1070072/
Hyrum’s Law states that any
observable behavior of a system will eventually be depended upon by
somebody. The kernel community is currently contending with a clear
demonstration of that principle. The recent work to address some restartable-sequences
performance problems in the 6.19 release maintained the documented API
in all respects, but that was not enough; Google’s TCMalloc
library, as it turns out, violates the documented API, prevents other code
from using restartable features, and breaks with 6.19. But the kernel’s
no-regressions rule is forcing developers to find a way to accommodate
TCMalloc’s behavior.
Post-quantum encryption for Cloudflare IPsec is generally available
Post Syndicated from Sharon Goldberg original https://blog.cloudflare.com/post-quantum-ipsec/
While more than two-thirds of human-generated TLS traffic to Cloudflare is already protected by post-quantum cryptography, the world of site-to-site networking has been a different story. For years, the IPsec community remained caught between the high bar of Internet-scale interoperability and the niche requirements of specialized hardware. That gap is now closing.
Earlier this month, we announced that Cloudflare has moved its target for full post-quantum security forward to 2029, spurred by several recent advances in quantum computing. To advance that goal, we’ve made post-quantum encryption in Cloudflare IPsec generally available.
Using the new IETF draft for hybrid ML-KEM (FIPS 203), we’ve successfully tested interoperability with branch connectors from Fortinet and Cisco — meaning you can start protecting your wide-area network (WAN) against harvest-now-decrypt-later attacks today using hardware you already have.
This post explains how we implemented the new hybrid IPsec handshake, why it took four years longer to land than its TLS counterpart, and how the industry is finally consolidating around a standard that works at Internet scale.
Cloudflare IPsec is a WAN Network-as-a-Service that replaces legacy network architectures by connecting data centers, branch offices, and cloud VPCs to Cloudflare’s global IP Anycast network. Customers get simplified configuration, high availability (if a data center becomes unavailable, traffic is automatically rerouted to the nearest healthy one), and the scale of Cloudflare’s global network. This is done through encrypted IPsec tunnels that support both site-to-site WAN, outbound Internet connections, and connectivity to the Cloudflare One SASE platform.

Cloudflare IPsec now uses post-quantum encryption with hybrid ML-KEM (FIPS 203) to stop harvest-now-decrypt-later attacks. These are attacks where an adversary harvests data today and then decrypts later, after Q-Day, when there are powerful quantum computers that can break the classical public key cryptography used across the Internet. Harvest-now-decrypt-later attacks are becoming a concern for more organizations as Q-Day approaches faster than expected.
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is a post-quantum cryptography algorithm that is based on mathematical assumptions that are not known to be vulnerable to attacks by quantum computers. It does not require special hardware or a dedicated physical link between sender and receiver. ML-KEM is intentionally designed to be implemented in software across standard processors to provide post-quantum encryption of network traffic.
Draft-ietf-ipsecme-ikev2-mlkem specifies post-quantum encryption for IPsec using hybrid ML-KEM, which combines the well-understood security of classical Diffie-Hellman and the post-quantum security of ML-KEM in a single, standards-compliant handshake. Specifically, a classical Diffie-Hellman exchange runs first, its derived key encrypts a second exchange that runs ML-KEM, and the outputs of both are mixed into the session keys that secure IPsec data plane traffic sent using the Encapsulating Security Payload (ESP) protocol.
Earlier we announced the closed beta of our implementation of draft-ietf-ipsecme-ikev2-mlkem in production in our Cloudflare IPsec product and tested it against a reference implementation (strongswan). Now that we have made this implementation generally available, we have also confirmed interoperability with several other vendors, including Cisco and Fortinet, which is a big win for this new standard.
Cisco: Customers using Cisco 8000 Series Secure Routers after version 26.1.1 as their branch connector can also now establish post-quantum Cloudflare IPsec tunnels per draft-ietf-ipsecme-ikev2-mlkem.
Fortinet: Customers using Fortinet FortiOS 7.6.6 and later as their branch connector can now establish post-quantum Cloudflare IPsec tunnels to Cloudflare’s global network per draft-ietf-ipsecme-ikev2-mlkem.
Given that upgrading cryptography is hard and can take years, our 2029 target date for a full update to post-quantum cryptography is going to require concentrated effort. That’s why we hope the IPsec community continues to focus on the development of interoperable standards like draft-ietf-ipsecme-ikev2-mlkem.
Let us explain why these standards are vitally important. A full specification for hybrid ML-KEM in IPsec, draft-ietf-ipsecme-ikev2-mlkem, became available only in late 2025. That’s roughly four years after support for hybrid ML-KEM landed in TLS. (In fact, Cloudflare turned on hybrid post-quantum key agreement with TLS in 2022, even before NIST finalized the standardization of ML-KEM, because the TLS community quickly converged on a single, interoperable approach and pushed it into production. Today more than two-thirds of the human-generated TLS traffic to Cloudflare’s network is protected with hybrid ML-KEM.)
The four-year delay is likely due in part to the IPsec community’s continued interest in Quantum Key Distribution (QKD), as codified in RFC 8784, published in 2020. We’ve written before about why QKD is not part of our post-quantum strategy: QKD requires specialized hardware and a dedicated physical link between the two parties, which fundamentally means it will not operate at Internet scale. Also, QKD does not provide authentication, so you still need post-quantum cryptography anyway to stop active attackers. It’s difficult to find implementations of QKD that interoperate across vendors.
The U.S. NSA, Germany’s BSI, and the UK’s NCSC have all warned against solely relying on QKD. Post-quantum cryptography, by contrast, runs on the hardware you already have, authenticates the parties at both ends, and works end-to-end across the Internet.
RFC 9370, published in 2023, opened the door to post-quantum cryptography in IPsec, allowing up to seven key exchanges to be run in parallel with classical Diffie-Hellman. However, RFC 9370 did not specify which ciphersuites should be used in these parallel key exchanges. In the absence of that specification, some vendors shipped early implementations under RFC 9370 before the hybrid ML-KEM draft was available, defining their own ciphersuites including some which are not NIST-standardized. This is exactly the kind of “ciphersuite bloat” NIST SP 800 52r2 warned against. And the risks to interoperability have played out in practice: Cloudflare IPsec does not yet interoperate with Palo Alto Networks’ RFC 9370–based implementation, because it was launched before draft-ietf-ipsecme-ikev2-mlkem was available.
Fortunately, we now have draft-ietf-ipsecme-ikev2-mlkem that fills in the gaps in RFC 9370, specifying hybrid ML-KEM as one of the key exchange mechanisms that can be operated in parallel with classical Diffie-Hellman. We hope to add Palo Alto Networks to the list of interoperable post-quantum branch connectors as the industry continues to consolidate around draft-ietf-ipsecme-ikev2-mlkem.
But the journey towards interoperable post-quantum IPsec standards is not over yet. While draft-ietf-ipsecme-ikev2-mlkem supports post-quantum encryption, we still need IPsec standards for post-quantum authentication, so that we can stop attacks by quantum adversaries on live systems after Q-Day. Given the shortened timeline for full post-quantum readiness, we hope the IPsec community will continue to focus on interoperable PQC implementations, rather than diverting focus to niche use cases with QKD.
At Cloudflare, we’re helping make a secure and post-quantum Internet accessible to everyone, without specialized hardware and at no extra cost to our customers. Post-quantum Cloudflare IPsec is one more step on our path to full post-quantum security by 2029, and we’re doing it in a way that ensures that the Internet remains open and interoperable for years to come.
GCC 16.1 released
Post Syndicated from jzb original https://lwn.net/Articles/1070649/
Version
16.1 of the GNU Compiler Collection (GCC) has been
released.
The C++ frontend now defaults to the GNU C++20 dialect and the corresponding
parts of the standard library are no longer experimental. Several
C++26 features receive experimental support, including Reflection
(-freflection), Contracts, expansion statements and std::simd.
Other changes include the introduction of an experimental compiler
frontend for the Algol68 language,
ability to output GCC diagnostics in HTML form, and more.
Seven new stable kernels for Thursday
Post Syndicated from jzb original https://lwn.net/Articles/1070641/
Greg Kroah-Hartman has released the 7.0.3, 6.18.26, 6.12.85, 6.6.137, 6.1.170, 5.15.204, and 5.10.254 stable kernels. The 7.0.3 and
6.18.26 kernels only contain fixes needed for Xen users; he advises
that all users of the other kernel series must upgrade.
Security updates for Thursday
Post Syndicated from jzb original https://lwn.net/Articles/1070640/
Security updates have been issued by AlmaLinux (buildah, firefox, gdk-pixbuf2, giflib, grafana, java-1.8.0-openjdk, java-21-openjdk, LibRaw, OpenEXR, PackageKit, pcs, python3.11, python3.12, python3.9, sudo, tigervnc, vim, xorg-x11-server, xorg-x11-server-Xwayland, yggdrasil, and yggdrasil-worker-package-manager), Debian (calibre, firefox-esr, and openjdk-17), Fedora (asterisk, binaryen, buildah, dokuwiki, lemonldap-ng, libexif, libgcrypt, miniupnpd, openvpn, podman, python3.9, rust-rpm-sequoia, skopeo, and xdg-dbus-proxy), Red Hat (buildah, gdk-pixbuf2, and nodejs:20), SUSE (dnsdist, libheif, openCryptoki, polkit, sed, and xen), and Ubuntu (linux-bluefield, python-marshmallow, and roundcube).
Agents can now create Cloudflare accounts, buy domains, and deploy
Post Syndicated from Sid Chatterjee original https://blog.cloudflare.com/agents-stripe-projects/
Coding agents are great at building software. But to deploy to production they need three things from the cloud they want to host their app — an account, a way to pay, and an API token. Until now these have been tasks that humans handle directly. Increasingly, agents handle them on the user’s behalf. The agent needs to perform all the tasks a human customer can. They’re given higher-order problems to solve and choose to use Cloudflare and call Cloudflare APIs.
Starting today, agents can provision Cloudflare on behalf of their users. They can create a Cloudflare account, start a paid subscription, register a domain, and get back an API token to deploy code right away. Humans can be in the loop to grant permission, but no human steps are required from start to finish. There’s no need to go to the dashboard, copy and paste API tokens, or enter credit card details. Without any extra setup, agents have everything they need to deploy a new production application in one shot. And with Cloudflare’s Code Mode MCP server and Agent Skills, they’re even better at it.
This all works via a new protocol that we’ve co-designed with Stripe as part of the launch of Stripe Projects.
We’re excited to launch this new partnership with Stripe, and also to offer $100,000 in Cloudflare credits to all new startups who incorporate using Stripe Atlas. But this new protocol also makes it possible for any platform with signed-in users to integrate with Cloudflare in the same way Stripe does, with zero friction for the end user.
Install the Stripe CLI with the Stripe Projects plugin, login to Stripe, and then start a new project:
stripe projects init
Then prompt your agent to build something new and deploy it to a new domain. You can watch a condensed two-minute video of this entire flow below:
If the email you’re logged into Stripe with already has a Cloudflare account, you’ll be prompted with a typical OAuth flow to grant the agent access. If there is no existing Cloudflare account for the email you’re logged in with, Cloudflare will provision an account automatically for you and your agent, without a human in the loop:

You will see the agent build and deploy a site to a new Cloudflare account, and then use the Stripe Projects CLI to register the domain:

The agent will prompt for input and approval when necessary. For example, if your Stripe account doesn’t yet have a linked payment method, the agent will prompt you to add one:

At the end, the agent has deployed to production, and the app runs on the newly registered domain:

The agent has gone from literal zero, no Cloudflare account at all, without any preconfigured Agent Skills or MCP server, to having:
-
Provisioned a new Cloudflare account
-
Obtained an API token
-
Purchased a domain
-
Deployed an app to production
But wait — how did the agent discover that it could do all of this? How did it know what services it could provision, and how to purchase a domain? How did it gain the context it needed to understand how to deploy to Cloudflare? Let’s dig in.
There are three components to the interaction between the agent, Stripe, and Cloudflare shown above:
-
Discovery — the agent can call a command to query the catalog of available services.
-
Authorization — the platform attests to the identity of the user, allowing providers to provision accounts or link existing ones, and securely issue credentials back to the agent.
-
Payment — the platform provides a payment token that providers can use to bill the customer, allowing the agent to start subscriptions, make purchases and be billed on a usage basis.
These build on prior art and existing standards like OAuth, OIDC and payment tokenization — but are used together to remove steps that might otherwise require a human in the loop.
In the agent session above, before the agent ran the CLI command stripe projects add cloudflare/registrar:domain, it first had to discover the Cloudflare Registrar service. It did this by calling the stripe projects catalog command, which returns available services:

The full set of Cloudflare products and services from other providers is long and growing — arguably overwhelming to humans. But for agents, this catalog of services is exactly the context they need. The agent chooses services to use from this catalog based on what the user has asked them to do and the user’s preferences — but the user needs no prior knowledge of what services are offered by which providers, and does not need to provide any input. Providers like Cloudflare make this catalog available via a simple REST API that returns JSON, and that gives agents everything they need.
When the agent chooses a service and provisions it (ex: stripe projects add cloudflare/registrar:domain), it provisions the resource within a Cloudflare account. But how is it able to create one on demand, without sending a human to a signup page?
Remember how at the start, the user signed in to their Stripe account? Stripe acts as the identity provider, attesting to the user’s identity. Cloudflare automatically provisions a new account for the user if no account already exists, and returns credentials back to the Stripe Projects CLI, which are securely stored, but available to the agent to use to make authenticated requests to Cloudflare. This means if someone is brand new to Cloudflare or other services, they can start building right away with their agent, without extra steps.
If the user already has a Cloudflare account, they’re sent through a standard OAuth flow to grant access to the Stripe Projects CLI, allowing them to provision resources on their existing Cloudflare account.
You might rightly worry, “What if my agent goes a bit overboard and starts buying dozens of domains? Will I end up on the hook for a massive bill? Can I really trust my agent with my credit card?”
The protocol accounts for this in two ways. When an agent provisions a paid service, Stripe includes a payment token in the request to the Provider (Cloudflare). Raw payment details like credit card numbers aren’t ever shared with the agent. Stripe then sets a default limit of $100.00 USD/month as the maximum the agent can spend on any one provider. When you’re ready to raise this limit, you can then set Budget Alerts on your Cloudflare account.
Any platform with signed-in users can act as the “Orchestrator”, playing the same role Stripe does with Stripe Projects, and integrate with Cloudflare.
Let’s say your product is a coding agent. You’d love for people to be able to take what they’ve built and get it deployed to production, using Cloudflare and other services. But the last thing you want is to send people down a maze of authorization flows and decision trees of where and how to deploy it. You just want to let people ship.
Your platform acts as the Orchestrator, with the already signed-in user. When your user needs a domain, a storage bucket, a sandbox to give their agent, or anything else, you make one API call to Cloudflare to provision a new Cloudflare account to them, and get back a token to make authenticated requests on their behalf.
Or let’s say you want Cloudflare customers to be able to easily provision your service, similar to how Cloudflare is partnering with Planetscale to make it possible to create Planetscale Postgres databases directly from Cloudflare. We started working with Planetscale on this well before this new protocol got off the ground, but the flow here is quite similar. Cloudflare acts as the Orchestrator, letting you connect to your PlanetScale account, create databases, and use the user’s existing payment method for billing.
This new protocol starts to standardize the types of cross-product integrations that many platforms have been doing for years, often in ways that were one off or bespoke to a particular platform. Without a standard, each integration required engineering work that often couldn’t be leveraged for future integrations. Similar to how the OAuth standard made it possible to delegate access to your account to other platforms, the protocol uses OAuth and extends further into payments and account creation, doing so in a way that treats agents as a first-class concern.
We’re excited to continue evolving the standard, and to work with Stripe on sharing a more official specification soon. We’re also excited to integrate with more platforms — email us at [email protected], and tell us how you want your platform to integrate with Cloudflare.
Stripe Projects is in open beta, and you can get started even if you don’t yet have a Cloudflare account. Just install the Stripe CLI, log in to Stripe, and then start a new project:
stripe projects init
Prompt your agent to build something new on Cloudflare, and show us what you’ve built!
По буквите в Болоня
Post Syndicated from Зорница Христова original https://www.toest.bg/po-bukvite-v-bolonya/

Един човек е отворена книга.
Човечеството е разхвърляна библиотека.
Така пише в „Там е разликата“ от Джасинто Лукас Пирес: уж игрива, уж детска книга, която си купих от Международния панаир на детската книга в Болоня.
Превеждам си я непохватно и изпитвам облекчение. Най-после някой да каже, че не е все едно,
че разликата по същество е нещо важно, че качеството невинаги губи служебно от количеството.

През последните години е точно обратното; свръхпроизводство на стоки, свръхпроизводство на информация, свръхпроизводство на мнения, на думи, мултиплицирани до безкрайност. Дори самият панаир на детската книга в Болоня при цялата си изумителност може да остави такова чувство: една книга е свят, милиарди книги са туптящи стъпала, парещи очи и глава, която се е замаяла здраво, загубила фокуса си. Книгоиздаването е и индустрия – индустрия, в която има големи и малки, пазарни дялове, права, екранизации, лиценз на стоки, има бестселъри и нишови издания, сигурен мейнстрийм и рискови стъпки встрани. Думата „количество“ витае около всяка нова книга. В какъв тираж ще се отпечата? Колко души ще искат да я прочетат? На колко езика ще се преведе?

Вървим сред множеството книги със Свобода Цекова. Измежду павилионите мярвам Лорънс Шимел, автора на „Късмет“ – книга, издадена на над 30 езика, включително и от мен на български. Освен писател Лорънс е преводач, идва тук от сто години и познава всички. Вярно ли е, пита го Свобода, че тази година панаирът е по-малък? Мда, потвърждава Лорънс. Заради войните няколко страни не дойдоха, Филипините, Индонезия, Австралия също се отказаха. Очевидно и Иран. Тези с лицензите завзеха част от това хале, преди не бяха тук, отбелязва Свобода. Лорънс кимва.
Войните се отразяват и на такива неща като детското книгоиздаване, да. Войната в Украйна – съвсем видимо, може би защото „Старият лъв“ и преди това печелеше много награди със своите ултраконцептуални заглавия. После войните също станаха много, а детските книги – повече обърнати към темата за войната въобще, за нейната цена, за нуждата да изплетеш дома си отново, от нищото, от събрани по пътя нишки.
Такава е темата на Thread by Thread от Алис Бриер-Хакет, илюстрирана с дорисувани снимки на действително плетиво на един миши дом, който внезапно започва да се разплита, мишките бягат с една кука и десетина бримки на нея, преди да започнат отново да сплитат свой пристан – този път по-шарен. (Впрочем другата забележителна „плетена книга“ видях на полския щанд, там преждата беше пъпна връв. Преди три-четири години пък прежда имаше в книга за Луис Буржоа.) Такава беше темата и на ред други книги, включително нашата „Колелото на Кинан“ от Петя Кокудева. Но съзнанието за световния контекст се формираше и по други начини.

Чудех се дали селекцията на иранската художничка Нушин Садегян за визуалната идентичност на фестивала (и изложбата на 45 нейни творби в самото начало на илюстраторската изложба) не е също подобен жест. От друга страна, Нушин действително рисува великолепно, печелила е много други награди и при всякакви обстоятелства би заслужила признание. И все пак…
Но всъщност има ли реално значение какво прави светът на детското книгоиздаване във времена, когато количеството (силата) очевидно беснее над международните правила, над опитите за позоваване на ценности като справедливост, човеколюбие, равенство, уважение към различието – ценности, които тези хиляди детски книги съдържат, но новините след тях опровергават? Не е немислимо и да си представим как дори този свят може да бъде превзет от едни други послания… Не е да не помним такива времена. И не е да не виждаме какви политически реакции будят у нас образованието и културата за деца.

И все пак срещата между човека и книгата е качествена, не количествена. Не само заради наградите и селекциите, които се опитват да балансират пазара. Естеството на четенето е такова. Един човек, една книга, една история. И „малко и голямо“ значат нещо друго в детската литература, където това е магичното съотношение между детето и възрастния – съотношение, което се обръща с времето, но може да запази своята съкровеност, своето връщане към същността. Като в „Голяма и малка“ от Ариана Скилони и Ракел Каталина, където една деветдесетгодишна жена се смалява, смалява, смалява, докато вятърът не я подхваща и тя трябва да се хваща за тревите, докато не почне да се обърква и да губи пътя към дома си, докато не се затваря в него и не подгонва натрапниците с хитроумни способи, като камъчета от прашка и гигантски сенки. Мъничка-мъничка, накрая Наталия се покатерва до ухото на влязъл да си почине странник… и му пее люлчината песен от детството си, с която му припомня кой е.

Изящно, нежно и топло нарисувана книга… която може би ни подсказва какво може детската литература и защо е важно възрастните да я четат на децата: освен всичко друго – заради самите себе си, за да чуят на глас кои са и какво точно ценят.
Един маршируващ е луд, пише в „Там е разликата“ от Джасинто Лукас Пирес.
Много маршируващи са армия.
Тълпата прави от символите политика.
Отделният човек прави от символите поезия.
Един играч, който нарушава правилата, е измамник.
Много играчи, които нарушават правилата, създават нова игра.
Една точка е край.
Три точки са…
В емблематичната си колонка „Ходене по буквите“, започната още през 2008 г. във в-к „Култура“, Марин Бодаков ни представяше нови литературни заглавия и питаше с какво точно тези книги ни променят. В началото на 2020 г. той я пренесе в „Тоест“. Вярваме, че е важно тази рубрика да продължи. От човек до човек, с нова книга в ръка. От края на 2021 г. по буквите тръгна Зорница Христова.
Активните дарители на „Тоест“ получават 20% отстъпка от коричната цена на всички книги на над 15 български издателства. Кои са те – вижте в условията на Читателски клуб „Тоест“.
Гюров спира финта на Желязков с държавните имоти и парламента
Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/4400-pausa/
Вчера служебният кабинет на Гюров взе решение да оттегли искането до Народното събрание за одобряване на Програмата за упражняване правата върху имоти – държавна собственост. Припомням, че след като темата нашумя, ГЕРБ и кабинета Желязков твърдяха, че спират продажбите докато парламента не потвърди приетата програма. В действителност се възползваха от отпуската на народните представители, за да потушат скандала. Преди това бяха казали, че само анализират и няма течащи продажби. В през август показах, че това не е вярно и че само дни след изказването на Желязков има насрочени търгове. В края на август спряха платформата за търгове на АППК. През декември показах, че след пик на активните търгове през юни до август има голяма пауза на активните търгове.
Решението на служебния кабинет гласи:
Правителството оттегли предложението до Народното събрание на Република България за одобряване на Програмата за упражняване правата върху имоти – държавна собственост, и върху имоти – собственост на държавни публични предприятия, и отмени решения на Министерския съвет.
Към Програмата е проявен значителен обществен и медиен интерес. По тази причина с Решение № 536 от 7 август 2025 г. Министерският съвет предлага на Народното събрание да разгледа и одобри Програмата, както и да приеме решение, с което до одобряването й да не се извършват разпоредителни действия с държавни недвижими имоти в полза на трети лица, освен за нуждите на държавни органи, агенции и комисии, общини и публични предприятия.
Към настоящия момент предложението не е разгледано и прието от 51-то Народно събрание.
Целта на проекта е да се осигури възможност за бъдещото редовно правителство да направи анализ на предложението до 52-то Народно събрание и при преценка да се предложат промени, съобразно провежданата държавна политика и програмата на правителството за управление на страната в областта на държавната собственост.
Това не значи, че програмата е спряна или има повече яснота или прозрачност какво се случва. Означава, че оставят за следващия кабинет да реши какво ще прави с плана, дали ще го прекроява, ще пита отново НС или ще търси други решение. Най-важното в случая е да променят практиката на ГЕРБ и ДПС НН за пълна липса на прозрачност и да вземат пример от служебния кабинет, който сякаш отвори повече данни за няколко месеца, отколкото всички кабинети за много години назад.
Какво се случи с онези 4400 имота всъщност?
През изминалата година от решението на кабинета Желязков няма обновен списък с „ненужни“ имоти, няма отговори как е съставен първият, последващи действа или каквото и да е свързано с темата. Дори оригиналният списък изчезна и повече не е публикуван.
Реших да обновя статистиката на търговете на АППК от декември и да видим какво се случило до сега. Виждаме ясно, че след спирането на портала през септември броят на активните търгове силно намалява и остава нисък. Към началото на март е имало 6 активни търга, а към днешна дата само един – имот на ББР в Разград, с който се надяват да получат поне 1.3 млн. евро.

Равносметката за тази година е, че от регистъра на електронните търгове в АППК, където и както са длъжни да продават всички дружества, научаваме за 92 обявени търгове. От тях 27 са прекратени предварително, а 22 са изтрити. Последното според отговор на агенцията е, защото са оттеглени. Най-много търгове за последната година е провела Земинвест ЕАД – 21, следвани от ББР и „БДЖ-Товарни превози“ ЕООД по 16.
16 от търговете са успешни, т.е. някой ги е спечелил. От тях 6 се отнасят до имоти от списъка на Желязков. Общата сума предполагаемо спечелена така за държавата е не повече от 730 хиляди евро. Казвам предполагаемо, защото това, че е спечелен търг не значи, че сделката е била финализирана, имота прехвърлен и цената платена. Попадал съм на няколко търга за идентични имоти след като за същото е имало успешен търг по-рано.
Продадените имоти са в Тръстеник, с. Голяма Железна, Пловдив и Драгоево. Търговете в Трявна и Бургас се отнасят до повече от един обект от списъка на Желязков и са имало поне два неуспешни търга преди някой да бъде спечелен. Две от тези успешни продажби са направени през юли 2025-та, когато осветлих списъка. Една през септември, една през октомври и още две през ноември. Т.е. поне четири имота от списъка са имали успешни търгове след като кабинета на ГЕРБ и ДПС НН обявиха, че спират с продажбите. За нито един от тези имоти няма публична аргументация защо са ненужни, струват ли пари на държавата или нещо от останалото обещано лично от Желязков.

Всички търгове на АППК, както и данните от оригиналния списък на Желязков и ГЕРБ ще намерите на картата, която пуснах миналата година. Под първата ми статия следяща темата ще намерите списък с всички текстове от поредицата.
Добре скритите публични търгове
Проблемът с тези данни е, че изглежда не обхващат всички търгове с държавни имоти. Както казах, държавните предприятия са длъжни да използват само АППК за прозрачни и електронни търгове. Единствено Министерството на отбраната имаше специален режим и изключения, но и това беше променено. Въпреки това, откриваме, че е имало доста такива продажби.
Пример за това е Национална компания Железопътна инфраструктура (НКЖИ). Директна собственост е на министерството на транспорта. Няма нито един търг в АППК и такива липсват на страницата с търгове на собственият им сайт. Проверка в интернет архива или търсене по ключови думи на страницата им обаче показват, че е имало поне 15 търга за продажба на държавни имоти в последните 12 месеца. Липсва всякаква прозрачност дали тези търгове са спечелени, от кого и за каква сума. Скриват се от страницата за продажби или наеми след като приключат. НКЖИ има 448 имота в списъка на Желязков и не е известно колко са продали междувременно. Същото важи за стотиците други държавни компании.
Затова засегнах в началото колко важна е прозрачността и отворените данни що се отнася до действията на институциите. Не само за проследимост и възстановяването на доверие, но и в случая за постигане на най-добри продажни цени предвид, че не се крият фиктивни търгове за предварително съгласувани облагодетелствани.
Why localisation matters for AI literacy: Lessons from Uzbekistan
Post Syndicated from Rehana Al-Soltane original https://www.raspberrypi.org/blog/why-localisation-matters-for-ai-literacy-lessons-from-uzbekistan/
Experience AI has grown into a global effort to build AI literacy in schools, supporting educators and young people around the world to better understand and critically engage with AI technologies. We recently brought Experience AI to Uzbekistan through a new collaboration with UNICEF.
Together, we are integrating Experience AI into the Tinkering with Tech programme, which supports Uzbekistani educators and learners to develop 21st-century skills, including computational thinking, and digital and AI literacy skills.
As one of the Learning Managers on the Foundation’s AI literacy team, I travelled to Uzbekistan to lead the AI literacy part of the programme, working closely with local trainers and educators and introducing them to Experience AI.

Experience AI training in action
On the plane to Tashkent, Uzbekistan, I found myself wondering about the level of engagement with AI tools among teachers and educators in Uzbekistan: how interested are teachers and students in AI technologies? Are they more excited or hesitant about AI technologies?
My questions were answered within minutes of the start of the training session in Tashkent. The teachers and trainers, who had travelled from cities and rural areas across the country, were enthusiastic, inquisitive, and already experimenting with AI technologies in their daily lives.
The training session created space for educators to deepen their understanding of both technical concepts like classification and accuracy, but also ethical considerations, including data representation, bias, and the implications of inaccurate AI tools.
One particularly powerful example of how AI systems can be inaccurate came from a trainer who shared video footage from a local cattle market, where an AI tool classifies animals and monitors traffic. In the video, a human was misclassified as a horse, and a goat misclassified as a human.

While the example was funny and showed a harmless error, it quickly became a meaningful learning opportunity. Together, we used it to have a wider discussion around the implications of these errors. For example, what happens when AI tools fail in higher stakes situations? Would we trust a self-driving car that might misclassify a person in a long, dark coat as a lamp post, or a child in an orange-and-white coat as a traffic cone?

Localisation and representation
Working closely with the partners and trainers, we used localised examples in the training to explore other AI literacy concepts, particularly representation and bias.
In one activity, we used an AI tool to generate an image of Gulistan, a beautiful city in eastern Uzbekistan. The result sparked a range of reactions — while Gulistan is known for its flat landscape and mosques, the AI-generated image showed mountains and churches.


This led to a rich discussion about how AI systems represent places and cultures, and what it means when those representations are inaccurate. I asked them: why did the tool produce this image? What data might the underlying model have been trained on? And how do these inaccuracies shape perceptions, especially for those unfamiliar with the place being represented?
This example resonated strongly with the trainers, particularly because it reflected their own context. After a short break, I returned to find everyone still engrossed in a deep discussion around the lack of neutrality of AI tools, and what that meant for them, their students and communities. As one trainer reflected, “I have changed my mind about AI and now I have a better understanding of it.”
Adapting to global classrooms
Spending time with educators in Uzbekistan was also a reminder that classrooms are far from uniform. In some Uzbekistani settings, learners have access to laptops and interactive whiteboards; in others, teaching happens with limited electricity, lower levels of digital literacy, or shared devices among many students.
As we continue to expand Experience AI globally, localisation remains crucial. From South Africa to Saudi Arabia, and from Ukraine to Uzbekistan, flexible, context-aware resources are key to ensuring that all learners have the opportunity to develop a meaningful and critical understanding of AI.

In our ongoing collaboration on the Tinkering with Tech programme with UNICEF, the Micro:bit Educational Foundation, and Arm, we’re supporting teachers to develop the confidence and skills they need to teach AI in ways that are engaging, relevant and grounded in real-world contexts for their students. Together, we aim to equip young people with the knowledge and confidence to shape how these technologies affect their lives and communities.
For more information about Experience AI, visit our website, experience-ai.org.
About Tinkering with Tech and AI: UNICEF is co-developing new learning materials, enhancing AI literacy, and scaling the Tinkering with Tech and AI initiative to reach more learners and education systems worldwide. The initiative benefits from the continued strategic support from Arm and the Government of Finland, along with technical partners the Raspberry Pi Foundation and Micro:bit Educational Foundation. Learn more here.
The post Why localisation matters for AI literacy: Lessons from Uzbekistan appeared first on Raspberry Pi Foundation.




