 |
| Хакнаха и Европейската комисия
|
 |
|
|
 |
 |
от DeepUltramarine на 5-04-2026@20:38 GMT(+2)
Съобщава се за сериозен пробив в сигурността на Европейската комисия, причинен от supply chain атака чрез отравяне (poisoning) на популярния open-source инструмент Trivy.
Какво ни е известно?
На 19 март 2026 Европейската комисия автоматично е изтеглила компрометирана версия на Trivy (по-точно от GitHub actions trivy-action).
Хакерската група TeamPCP (известна още като DeadCatx3, PCPcat, ShellForce) е използвала остатъчен достъп след предишно пробиване на хранилището на Trivy в края на февруари. Злонамерен код е качен в 76 от 77 версии на trivy-action.
Когато инструментът се е изпълнил в pipeline-а на Комисията, malware-ът се е добрал до AWS API ключ, с който хакерите са получили достъп до облачната инфраструктура на Комисията в Amazon Web Services.
Между 19 и 27 март групата е провела систематична кампания, като е атакувала и други open-source инструменти за сигурност (Checkmarx KICS и LiteLLM).
В резултат хакерите са свалили 92GB компресирани данни (около 340GB некомпресирани).
Почти 52,000 файла, включително изходящи имейли, списъци с имена, потребителски имена и имейл адреси.
Данните са от уебсайтове, хоствани за до 71 клиента на услугата Europa.eu web hosting – 42 вътрешни клиента на Европейската комисия и поне 29 други институции на ЕС (включително European Medicines Agency, European Banking Authority, ENISA, Frontex и редица други).
Пробивът е забелязан като на 24 март (5 дни по-късно) Центърът за киберсигурност на Комисията забелязва аномалии в използването на AWS API и необичаен скок в мрежовия трафик.
На 27 март Комисията публично съобщава за инцидента.
Данните са публикувани в dark web от групата ShinyHunters.
Хакерите са били изключително методични.
Създали са нов access key и са го прикрепили към съществуващ IAM потребител (Identity and Access Management) вместо да използват директно откраднатия ключ.
След това са се заели с подробно разузнаване на цялата AWS среда:
IAM users и IAM roles — за да видят кои акаунти и роли с какви права разполагат:
EC2 instances (виртуални машини)
Lambda функции
RDS databases (бази данни)
S3 buckets (хранилища за файлове)
Route 53 hosted zones (DNS)
ECS clusters (контейнери) — като са се фокусирали върху task definitions, за да намерят контейнери, които са могли да се достъпят директно.
Целта е била намиране на по-високи привилегии. След това са направили bulk exfiltration (масово източване) главно от AWS Secrets Manager.
Това е класическа техника при облачни атаки — първо разбираш "картата" на акаунта (кой какво може), после крадеш.
В процеса е използван инструмент, наречен TruffleHog.
TruffleHog е open-source софтуер, който сканира за "hardcoded" (вписани директно в кода или файловете) удостоверения и ключове.
В атаката инструмента е използван от хакерите за да проверят дали още работят откраднатите AWS credentials (като се обръщат към AWS Security Token Service – STS) и да търсят допълнителни "тайни"/secrets в средата на Европейската комисия.
Конкретно в случая тези тайни включват:
AWS access keys и secret keys
Други cloud credentials (GCP, Azure и т.н., ако има)
Database connection strings (потребител/парола за RDS или други БД)
API keys за различни услуги
SSH keys, GitHub tokens, Kubernetes tokens
OAuth tokens, пароли и всякакви чувствителни данни, които са оставени в код, env файлове, конфигурации или в паметта на процесите
В malware от самия компрометиран Trivy (който е вече е "cloud stealer") е имало и по-ниско ниво събиране на данни:
Сканиране на файловата система за над 50 чувствителни пътища (.aws/credentials, .env, .kube/config, SSH ключове и т.н.).
Четене на паметта на процесите (/proc/*/mem) за да се измъкнат декриптирани secrets, които са в RAM (дори ако GitHub маскира логовете).
С две думи, търсили са всичко, което може да им даде още достъп — допълнителни AWS ключове, пароли за бази данни, токени за други системи и т.н.
Последователността на атаката е била приблизително следната:
Получаване на начален AWS API key от Trivy malware.
Пускане на TruffleHog, валидиране на ключа, търсене на още secrets.
Създаване на нов ключ за достъп и прикачването му към съществуващ потребител (за да не се набива на очи).
Изброяване на IAM roles/users и всички други ресурси.
Фокусиране върху Secrets Manager и ECS и масово източване данни (~92GB компресирани).
Това е показно за много методична и професионална cloud атака, типична за supply-chain кампаниите на TeamPCP.
Класически пример за supply chain атака – хакерите не атакуват директно Комисията, а компрометират инструмент за сигурност (Trivy), който тя използва, за да се защитава. В публикацията се подчертава , колко опасна е зависимостта на правителства и големи организации от open-source инструменти и колко крехка е веригата на доставка в софтуерната сигурност.
В статията от която е взета информацията за публикацията тук се цитират CERT-EU, които официално приписват атаката на TeamPCP и публикуването на данните от ShinyHunters.
Източник: https://thenextweb.com/news/european-commission-breach-trivy-supply-chain
Използвани са и други източници за допълнителни подробности и разяснения (главно по терминологията - не съм професионалист в областта) - за което моля за извинение, ако има неточности относно AWS и облачните услуги като цяло.[Коментари: 0] |
|
 |
|
 |
|
| nft по подразбиране в Arch
|
|
|
|
|
|
от DeepUltramarine на 6-04-2026@12:54 GMT(+2)
От Arch Linux съобщават за важна промяна в пакетите по подразбиране за управление на firewall.
Пакетът iptables вече ще използва nft backend (т.е. nftables).
Старият пакет iptables-nft се преименува/заменя с обикновения iptables.
Легаси версията (истинският стар iptables) остава достъпна като отделен пакет iptables-legacy.
Или с две думи, когато инсталирате iptables (което е част от base/meta пакета), вече получавате модерната версия, която зад кулисите работи с nftables, а не със стария xtables/legacy код.
Nftables е по-новият и модерен framework за packet filtering в Linux (част от netfilter), който цели да замени изцяло стария iptables (iptables, ip6tables, arptables и т.н.).
Основните предимства на nftables са:
По-добра поддръжка на dual-stack (IPv4 + IPv6) — правилата са в едно място, не се дублират.
По-ефективен и бърз (по-малко overhead).
По-гъвкав синтаксис (един инструмент nft вместо множество: iptables, ip6tables и т.н.).
По-лесно за разширение и поддръжка от разработчиците на ядрото (Netfilter team вече фокусира усилията си основно върху nftables).
По-малко дублиране на код и по-модерна архитектура.
Смяната не е нова идея — повечето големи дистрибуции (Debian, Ubuntu, Fedora и др.) отдавна са я направили. Arch просто се изравнява с останалите.
За повечето хора нищо не се променя — iptables командите продължават да работят по същия начин (благодарение на compatibility layer).
Ако имате стари правила в /etc/iptables/, проверете за .pacsave файлове след ъпдейта и ги възстановете, ако е нужно - файловете с разширение .pacsave се създават, когато премахнете пакет в Arch Linux и pacman реши да направи резервно копие на променените ви конфигурационни файлове, вместо да ги изтрие. Тези резервни копия ви позволяват да възстановите предишните си настройки, ако по-късно преинсталирате пакета.
Ако ползвате някакви редки extensions или нещо много специфично за legacy iptables, може да се появят проблеми — в такъв случай можете да инсталирате iptables-legacy и да го ползвате вместо стандартния.
Промяната е активна от вчера, 5 април 2026г.
От Arch препоръчват да преминете към чист nftables (nft командата) за нови конфигурации.
Източник: https://linuxiac.com/arch-linux-makes-nft-the-default-backend-for-iptables/[Коментари: 0] |
|
|
|
|
|
| ODF става стандартен формат в Германия
|
|
|
|
|
|
от DeepUltramarine на 7-04-2026@19:43 GMT(+2)
Германия въвежда Open Document Format (ODF) като задължителен стандартен формат за документи в публичната администрация в рамките на новата си "суверенна цифрова инфраструктура" наречена Deutschland-Stack.
Това е публикувано от Федералното министерство за цифрова трансформация и модернизация на държавата. Рамката определя технически стандарти за единна, съвместима цифрова среда на всички нива на управление (федерално, провинциално и местно).
По-конкретно, изисква се използването на:
ODF (отвореният стандарт, който се ползва от LibreOffice и подобни)
PDF/UA - стандарт за универсална достъпност (Universal Accessibility) на PDF документи.
Официално се нарича ISO 14289 и определя строги технически изисквания за структурата на PDF файловете, така че те да са лесно четими и навигируеми от хора с увреждания (със screen readers, брайлови дисплеи и други assistive технологии).
Собственически (proprietary) формати като .docx се изключват от официална употреба.
Основната цел на това е:
Да се осигури последователност при работа с документи
Да се осигури съвместимост между системите
Дългосрочна достъпност на официалните записи - почти всяка промяна в основните версии на офис пакета на Microsoft е водела до несъвместимост с новите файлови формати и след въвеждането на нови. Старите документи стават нечетими от новите версии на софтуера.
Намаляване на зависимостта от един доставчик (vendor lock-in)
По-голяма цифрова суверенност чрез отворени стандарти, отворен код и локално съхранение на данни
Ето и какво казва Florian Effenberger (изпълнителен директор на The Document Foundation):
Решението на Германия да постави ODF в основата на националния си суверенен стек потвърждава това, за което аргументираме от години: отворените, независими от доставчик формати за документи не са нишова тема за техно-специалисти и привърженици на свободния софтуер. Те са фундаментална инфраструктура за демократични, съвместими и суверенни публични администрации.
Отбелязва се още, че това е в синхрон с европейските политики за цифрова суверенност (European Interoperability Framework, Cyber Resilience Act и др.).
Deutschland-Stack ще ръководи развитието на общата цифрова инфраструктура до 2028г. и ще влияе върху обществените поръчки и софтуерните избори в целия публичен сектор.
Основните компоненти на Deutschland-Stack трябва да са готови дотогава. Вече има предварителни решения от 2025г. за постепенно преминаване към ODF до 2027г.
Официалната страница на Deutschland-Stack където се обясняват целите, стратегията, кои са за задължителните формати за администрацията и новите технически изисквания, както и целите на тези промени (на немски): https://deutschland-stack.gov.de/gesamtbild/
Линк към съобщението на The Document Foundation: https://blog.documentfoundation.org/blog/2026/03/19/germanys-sovereign-digital-stack-mandates-odf/
Както и втори пост с повече детайли: https://blog.documentfoundation.org/blog/2026/03/20/big-news-germany-has-just-made-odf-mandatory/
Решението има значителни последици както за Германия, така и потенциално за целия Европейски съюз.
Това е задължителен стандарт за целия публичен сектор - от федерално ниво, през провинциите, до общините. Всички официални документи (текстове, таблици, презентации) трябва да са в ODF (като .odt, .ods, .odp), а финалните/архивирани документи – в PDF/UA (достъпен PDF). Собственически формати като .docx (Microsoft Word) се изключват от официална употреба.
Намалява се зависимостта (vendor lock-in) — Германия вече няма да е "заключена" в екосистемата на Microsoft Office. Това намалява риска от внезапни промени в лицензи, цени или политики от страна на един доставчик.
Осигурява се по-голяма цифрова суверенност — документите остават дългосрочно достъпни и четими, независимо от бъдещи софтуерни продукти. Данните се съхраняват локално или в европейски облаци, а не под юрисдикцията на закони като американския CLOUD Act.
Също така, по този начин се гарантира и по-добра оперативна съвместимост и достъпност — всички институции ще могат лесно да обменят документи без загуба на форматиране. PDF/UA гарантира, че документите са достъпни за хора с увреждания (съгласно European Accessibility Act).
Ще има промяна и при обществените поръчки — доставчиците на софтуер за държавата ще трябва да поддържат пълноценно ODF. Това дава силен тласък на LibreOffice, Collabora и други open-source решения, но и на Microsoft (ако иска да остане конкурент, ще трябва да подобри поддръжката си).
Като най-голямата икономика в ЕС Германия се явява и основен двигател за промени.
Когато тя налага стандарт, доставчиците на софтуер за целия европейски пазар се адаптират. Това може да стане "де факто" стандарт и в други държави, без да се чакат нови директиви.
Сегашното решение е в пълна хармония с европейнките политики:
European Interoperability Framework (EIF) — препоръчва отворени стандарти като ODF.
Cyber Resilience Act.
Както и с общата цел за намаляване на зависимостта от неевропейски (най-вече американски) технологии.
Подобна промяна обаче налага и свои изисквания, но носи и
Обучение и преквалификация на стотици хиляди служители в държавната администрация, провинциите и общините. Преминаването от Microsoft Office към LibreOffice (или други ODF-съвместими инструменти) изисква време и курсове.
Миграция на съществуващи документи — конвертиране на огромни архиви от .docx в .odt, което може да доведе до временни несъответствия в форматирането и нужда от ръчни корекции.
Еднократни инвестиции в IT инфраструктура, поддръжка и разработка на интеграции. Да припомним например, че Windows 11 изискваше изцяло нови машини, за да се инсталира изобщо. Което е огромен разход само за хардуер.
Например в провинция Schleswig-Holstein еднократните разходи за подобен преход са около 9 милиона евро през 2026г. За дооборудване на работни места, доразработка на open-source решенията и завършване на миграцията).
Но, спестявани над 15 милиона евро всяка година (за Windows, Microsoft Office 365 и свързаните продукти). Това са пари, които преди са отивали директно към касичката на Microsoft.
Период на възвръщаемост - по-малко от 1 година (някои източници казват дори под 6–9 месеца). След това всяка следваща година държавата спестява чистите 15+ милиона евро.
По-добрата поддръжка на отворени стандарти за целия европейски пазар
ще доведе до по-ниски цени за всички държави в ЕС, ще бъде стимул за развитие на европейска софтуерна индустрия, а общите спестявания за публичните бюджети в Европа (някои оценки говорят за потенциал от стотици милиони до милиарди евро годишно в целия ЕС при масово преминаване), ще могат да се пренасочат другаде.
В дългосрочен план икономическите последствия могат да се считат със сигурност за положителни – спестявания, по-голяма независимост и стимулиране на конкуренцията. Първоначалните краткосрочните разходи са реални, но обикновено се изплащат за 1–2 години (както показва примерът с Schleswig-Holstein).
Какво показва този пример на практика?
Бърза финансова полза - преходът не е "скъп в дългосрочен план". Напротив – той се изплаща много бързо и след това генерира постоянни спестявания от бюджета.
Мащабите само в споменатата провинция: около 30 000 работни места в държавната администрация (плюс още за имейл системата – над 44 000 пощенски кутии). Към края на 2025г. вече са прехвърлени около 80% от работните места на LibreOffice, а имейлът е напълно мигриран към open-source алтернативи (Open-Xchange + Thunderbird).
Допълнителните ползи също са значителни.
Парите вече не отиват към САЩ, а остават в европейската икономика или се реинвестират в разработка на отворен софтуер.
Зависимостта от един доставчик е значително по-малка (vendor lock-in) — държавата може по-свободно да преговаря и да избира. По-голямата конкуренция за предоставяне на специфичен софтуер и услуги също така стимулира и софтуерната индустрия.
По-добра и по-евтина дългосрочна поддръжка — документите в ODF остават четими след години, без нужда от нови лицензи или миграции.
Ако повече държави последват успешния пример на Schleswig-Holstein, спестените разходи на национално ниво ще достигнат стотици милиони и дори милиарди евро.
И тук е момента да огледаме и родната картинка.
България е на доста по-различен етап от Германия по отношение на ODF и отворените стандарти в публичната администрация.
Няма задължителен национален стандарт за ODF като в Deutschland-Stack. Не съществува закон или стратегия, която да забранява .docx или други собственически формати и да прави ODF единствения официален формат за документи в държавната администрация.
Страната ни има своя Българска национална рамка за оперативна съвместимост (от 2010-те години, актуализирана) и Наредба за общите изисквания за оперативна съвместимост. Всички администрации са задължени да обменят електронни документи през Единната среда за обмен на електронни документи (ЕСОЕД).
Отворени формати се препоръчват, но не са задължителни за всички документи. В обществени поръчки и технически задания често се изисква доставчикът да предоставя документи в ODF / Office Open XML / PDF / RTF и т.н. – тоест ODF е приемлив, но не е единственият.
Националният портал за отворени данни (data.egov.bg) публикува данни в машинночетими отворени формати (CSV, JSON и др.). Това позволява бързата обработка на данни, изграждане на статистически модели и по-бързи оценки. Тук не сме толкова назад, но в Германия интеграцията е доста по-голяма.
От 2016 г. има законово изискване (изменение в Закона за електронното управление): при нови разработки или големи обществени поръчки за софтуер се предпочита open source. Това е една от най-ранните подобни политики в ЕС.
Стратегията за цифрова трансформация 2026–2030 е в процес на обществено обсъждане и одобрение.
Акцента е върху "Digital by default", оперативна съвместимост, пълно съответствие с европейските политики (European Interoperability Framework) и киберсигурност.
Но няма споменаване на ODF като задължителен стандарт или на "суверенен стек" като в Германия. Изглежда форматът на документите изобщо или почти не се обсъжда.
Публичният сектор все още разчита в голяма степен на Microsoft Office, но постепенно се увеличава използването на LibreOffice в някои общини и ведомства (главно по икономически причини).
България като цяло следва европейските препоръки за оперативна съвместимост и отворени данни и има добра правна основа за open source софтуер, но не е направила решителната крачка като Германия към задължителен ODF.
Това означава, че все още сме в "смесен" режим – спестяваме от лицензи там, където можем или по-скоро сме принудени, но нямаме национална политика, която да изключва Microsoft Office.
Решителни стъпки липсват, но се надявам, че примерът на Германия ще бъде последван от повечето от останалите държави в ЕС и може би ние ще сме сред тях, ако не отново на опашката.
Източник: https://linuxiac.com/germany-mandates-odf-for-public-administration/
Използвани са и други източници за допълнителна информация.[Коментари: 0] |
|
|
|
|
|
| APT 3.2 с допълнителни функции, вече стабилни
|
|
|
|
|
|
от DeepUltramarine на 7-04-2026@23:23 GMT(+2)
Вчера, на 7 април 2026г. излезе версия 3.2 на пакетния мениджър apt.
Това е стабилното издание с дългоочакваните функции за история и връщане назад (history, undo, redo, rollback), които вече бяха добавени в разработъчните версии 3.1.6 и 3.1.7.
Новите команди са:
apt history-list – показва списък с всички минали транзакции (инсталации, обновявания, премахвания).
apt history-info – детайлна информация за конкретна транзакция.
apt history-undo – отменя конкретна транзакция.
apt history-redo – повтаря (redo) отменена транзакция.
apt history-rollback – връща цялата система към предишно състояние (пълно rollback).
Това е първият път, когато APT получава поддръжка за история и rollback на ниво пакетен мениджър (досега се правеше с външни инструменти или скриптове). Подобно е на dnf history и dnf rollback във Fedora/RHEL.
Към този момент apt 3.2 ще можете да използвате с Debian Sid (Unstable) и вероятно в Ubuntu 26.04 LTS. Официалните Ubuntu release notes споменават APT 3.1 (с нов dependency solver, преминаване към OpenSSL и др.), а не точно 3.2. В публикацията обаче изрично пише, че новата версия ще е налична и там – най-вероятно защото Ubuntu взема пакетите от Debian Unstable/Testing и функциите history/undo/rollback вече са в 3.1.7+.
Със сигурност, APT 3.2 ще влезе в Debian 14 „Forky“ (очакван през юни-юли 2027 г.), а същата версия (или поне ключовите ѝ функции) ще бъде налична и в предстоящата Ubuntu 26.04 LTS, която Canonical планира да пусне на 23 април 2026г. (т.е. след около 2 седмици от днес).
С версия 3.2 на apt живота на ползващите Debian, Ubuntu и производните им значително се улеснява.
Останалите ще се мъчим.
Източник: https://9to5linux.com/debians-apt-3-2-released-with-history-undo-redo-and-rollback-support[Коментари: 0] |
|
|
|
|
|
| Излезе Nano 9.0
|
|
|
|
|
|
от DeepUltramarine на 8-04-2026@19:02 GMT(+2)
Версия 9.0 на познатия на всички ни конзолен текстови редактор Nano е налична за сваляне.
Това е първият основен ъпдейт, две години след 8.0.
Какво получаваме с обновяването ѝ?
Вече всички редове заедно се скролват хоризонтално, когато курсорът е на път да излезе от дясната страна на видимата област. Скролването е точно толкова, колкото е нужно, за да остане курсорът видим.
Ако искате да оставите старото поведение (само текущият ред да се скролва хоризонтално), можете да използвате опцията --solosidescroll или set solosidescroll в конфигурацията.
Можете също така да скролвате viewport-а хоризонтално на стъпки от една табулация с клавишите ALT+.
Превключвателите на функции вече не прекъсват поредицата от изрязвания (CTRL+K) или копирания (ALT+6), с изключение на ALT+K.
Клавишите ALT+Left, ALT+Right, ALT+Up и ALT+Down вече могат да се преназначават (rebindable).
Ако започнете да записвате макро и веднага го спрете, записът се анулира и старото макро остава непокътнато.
С опциите --mouse + --indicator вече можете да кликнете в областта на скролбара, за да се придвижите на приблизителна позиция в документа.
Списък с клавишните комбинации е наличен на https://www.nano-editor.org/dist/latest/cheatsheet.html
Други по-малко известни или нови опции:
Нова опция --listsyntaxes (или -z), която показва списък с наличните синтаксиси.
Подобрено запазване и възстановяване на „котви“ (anchors) при затваряне/отваряне на файл (когато positionlog е включен).
Поддръжка за центриране на курсора с CTRL+L и циклично превключване с ALT+%.
По-добро оцветяване на синтаксиса в повече локали.
Менюто за отиване на ред (GotoLine) вече приема префикси ++ и -- за скачане напред или назад с определен брой редове.
Котвите вече не се забравят, ако дадете номер на ред при стартиране от командния ред.
Препоръчително е да се прочетат официалните release notes за пълния списък с промени.
Ако сте нетърпеливи Nano 9.0 може да се свали от официалния сайт и да се компилира от изходен код. Ако не искате да компилирате, просто изчакайте да се появи в хранилищата на системата ви.
За още повече подробности, можете да погледнете и пълния changelog.
Източник: https://9to5linux.com/gnu-nano-9-0-cli-text-editor-released-with-new-features-and-improvements[Коментари: 0] |
|
|
|
|
|
| Little Snitch вече и за Linux
|
|
|
|
|
|
от DeepUltramarine на 9-04-2026@3:17 GMT(+2)
Популярното приложение за MacOS Little Snitch, вече официално има версия за Linux.
Little Snitch е интерактивен application firewall (мрежов монитор плюс блокер), който:
Показва ви в реално време коя програма се опитва да се свърже накъде (към кой сървър, за какво).
Изскача ви предупреждение и вие решавате: Allow (позволи), Deny (блокирай) или "Allow once".
Можете да създавате постоянни правила (напр. "Firefox никога да не се свързва към Mozilla telemetry").
Основната цел е поверителност (privacy), а не толкова сигурност.
Много хора, които са свикнали с програмата на Mac, се чувстват като "голи" на Linux без подобно нещо.
Затова разработчикът (Christian Starkjohann от Objective Development) е направил една.
Версията за Linux e написана на Rust и използва eBPF (модерна технология в ядрото на Linux за прихващане на трафик).
Има web базиран интерфейс (можете да я ползвате отдалечено, например от телефона си).
Не е 100% идентична с MacOS версията — на Linux няма deep packet inspection и е по-трудно да се реализира технически.
Програмата е безплатна за сваляне и ползване.
Може да се свали от официалния сайт: https://obdev.at/products/littlesnitch-linux/
Изисквания са Linux kernel 6.12+ с BTF поддръжка (Ubuntu 25.04+ би трябвало да работи добре).
За Linux има и напълно open-source алтернатива, която съществува от години и е вдъхновена точно от Little Snitch — казва се OpenSnitch. Много хора я предпочитат, защото е изцяло отворена.
Разбира се, може да просто да се използват netstat, ss, tcpdump или nethogs от терминала, но те не са толкова удобни и интерактивни като Little Snitch/OpenSnitch.
За хора, които тепърва се сблъскват с Linux и терминала все още ги плаши, двата графични инструмента са чудесна възможност, да се чувстват по-малко следени от различните приложения и с това, по-спокойни.
Източник: https://www.omgubuntu.co.uk/2026/04/little-snitch-linux[Коментари: 0] |
|
|
|
|
|
| Ghostty вече е достъпен директно в Ubuntu
|
|
|
|
|
|
от DeepUltramarine на 10-04-2026@16:58 GMT(+2)
Ghostty е модерен, бърз и богат на функции терминален емулатор (terminal emulator), който работи на Linux и macOS. Създаден е от Mitchell Hashimoto (създателят на Vagrant и HashiCorp).
И вече е достъпен директно в официалните хранилища на Ubuntu 26.04 LTS (Resolute Raccoon).
Ghostty използва GPU ускорение, което го прави много бърз при скролване, рендване и т.н.
Разполага с Native UI и на Linux изглежда и се държи като нормално GTK4/libadwaita приложение (подобно на GNOME Terminal), не като чуждо Electron/кросплатформено нещо.
Също, поддържа Wayland добре, разполага с табове, splits (разделяне на прозореца), профили, теми, лигатури, emoji, Kitty graphics protocol (може да показва изображения директно в терминала) и много други модерни функции.
Конфигурацията е само чрез текстови файл - много удобно за повечето потребители. Разполага със стотици опции, така че можете да го настроите точно както ви се иска.
Изобилието от опции не бива да ви плаши. Ghostty идва с разумни и смислени опции по подразбиране и е много удобен още с първото отваряне.
Конфигурационния файл се намира в познатите папки:
$XDG_CONFIG_HOME/ghostty/config.ghostty
$XDG_CONFIG_HOME/ghostty/config
Или, ако XDG_CONFIG_HOME не е сетната, локацията е в $HOME/.config
Планира се да се добави и графичен интерфейс за конфигуриране на Ghostty, но ще трябва малко да почакаме.
Празните стойности в конфигурационния файл нулират съответната опция до стойността ѝ по подразбиране.
Например: font-family =
Като са от значение малки и големи букви - font-family не е едно и също като Font-family.
В конфигурационния файл се използват изцяло малки букви.
Целта на Ghostty е да бъде бърз, красив и native едновременно, без да жертва функционалност.
Много хора го смятат за един от най-добрите нови терминали напоследък (наред с Kitty, Alacritty, WezTerm), особено ако искате нещо, което изглежда естествено в GNOME/Ubuntu.
Написан е предимно на Zig — модерен системен език, който е създаден да бъде по-безопасен и по-ефективен от C.
Ghostty вече влиза официално в Ubuntu хранилищата (в секцията universe) точно с Ubuntu 26.04. Преди това трябваше да се инсталира през community PPA, Snap, DEB пакет или да се компилира от изходен код.
Инсталацията е директна:
sudo apt update
sudo apt install ghostty
Ако използвате Ubuntu, ако искате нещо бързо и функционално, което се конфигурира лесно и директно (background = 282c34), да показва и картинки, да не се отличава външно от останалите приложения, с удобни клавишни комбинации по подразбиране, пробвайте Ghostty.
Пълната документация на Ghostty е на https://ghostty.org/docs
Източник: https://www.omgubuntu.co.uk/2026/04/ghostty-terminal-ubuntu-26-04-apt-install[Коментари: 0] |
|
|
|
|
|
| Франция с планове за преминаване към Linux
|
|
|
|
|
|
от DeepUltramarine на 10-04-2026@22:43 GMT(+2)
Франция обяви, че планира да мигрира част от правителствените си компютри от MS Windows към Linux с цел, да се намали зависимостта от американски технологични компании и да се постигне по-голяма цифрова суверенност ("да си върнем контрола над нашата цифрова съдба").
Френският министър Дейвид Амиел заявява, че правителството вече не може да приема липсата на контрол върху данните и цифрова си инфраструктура.
Преходът ще започне с компютрите в агенцията за цифрова трансформация DINUM, като все още не е известен конкретен краен срок или кои Linux дистрибуции ще се използват за целта.
Това е още една стъпка на Франция за намаляване зависимостта си от американските технологични компании (след като вече замениха MS Teams с френската Visio, базирана на Jitsi).
Тези действия се случват на фона на геополитическото напрежение циркулиращо от известно време между европейските държави и САЩ и хаотичната и непоследователна политика на администрацията на Тръмп.
Все още няма коментари от Microsoft.
В Европа се наблюдават все по-засилващ се стремеж към независимост и все по-ясна и ускоряваща се тенденция към цифрова суверенност – намаляване на зависимостта от американски технологии (главно Microsoft, Google, Amazon, Zoom и др.).
Това включва преминаване към open-source решения като Linux (за десктопи), LibreOffice (алтернатива на MS Office), Nextcloud (за файлове), OnlyOffice, Thunderbird и европейски/отворени инструменти за видеоконференции (като френския Visio или базирани на Matrix).
Конкретно правителството на Франция обяви пълен преход на всички държавни компютри (около 2,5–2,6 милиона устройства за цивилни служители) от Windows към Linux. Всяко министерство трябва да представи план до есента на 2026г. Вече са мигрирали стотици хиляди работни станции към LibreOffice, а Gendarmerie (жандармерията) използва собствена Linux дистрибуция (GendBuntu) от над 15 години. Замениха и MS Teams с Visio.
В Германия въведоха задължително преминаване към ODF, за което вече писах тук.
В Дания Министерството по цифровизация преминава от MS Office 365 към LibreOffice (и частично към Linux).
Започна през 2025г., с фокус върху намаляване на зависимостта от чужди доставчици. Някои общини (Копенхаген, Орхус) също ограничават Microsoft.
Австрийските военните (армията) преминаха изцяло към LibreOffice след 4-годишна миграция.
Също и в Италия Военното министерство мигрира 150 000+ компютъра към open-source решения.
Има пилотни проекти и обсъждания в Швейцария, Нидерландия и на ниво ЕС (идеи за “EU-Linux" или координирана европейска стратегия). По-стари примери като Мюнхен (LiMux проект от 2004г.) показват, че миграциите са трудни – градът се върна частично към Windows поради политика и удобство, но все още използва много open-source.
Тенденцията не е само за десктопите. Включени са и облачните услуги (по-малко AWS/Azure/Google Cloud), видеоконференциите и AI инструментите.
Целта е по-голяма независимост и сигурност — данните остават под европейски закони (GDPR), без риск от американски санкции или задължителен достъп (както се случи на няколко пъти през 2025–2026).
Конкретно, на 10/18 юни 2025г. в рамките на изслушване в френския Сенат (комисия по обществени поръчки и цифрова суверенност) представител на Microsoft Франция – Антон Карнио (директор по правни и обществени въпроси) – беше запитан под клетва:
Можете ли да гарантирате, че данните на френските граждани и институции, съхранявани в облака на Microsoft, никога няма да бъдат предадени на американските власти без изричното съгласие на френските власти?
И отговорът му беше ясен и съвсем откровен:
Не, не мога да го гарантирам.
Тогава той още добави, че Microsoft ще оспорва необосновани искания, но при валидна заповед от САЩ (според американския CLOUD Act от 2018г.) компанията е длъжна да предостави данните – независимо дали те се намират физически в ЕС (Франция, Германия и т.н.).
Това не беше теоретичен отговор – беше официално признание под клетва от американска компания, че европейските данни в нейните сървъри не са 100% защитени от достъп от САЩ.
Пълен протокол от изслушването (френски) както и видео
Събитието беше широко отразено и цитирано многократно през 2025–2026г. в дебати във Френския парламент, германския Бундестаг, Европейския парламент и послужи като основа за или беше споменато в различни доклади на ЕС за цифрова суверенност:
https://www.europarl.europa.eu/RegData/etudes/STUD/2025/778576/ECTI_STU(2025)778576_EN.pdf
https://www.europarl.europa.eu/doceo/document/A-10-2025-0107_EN.html
Подобни въпроси и опасения бяха повдигнати и в други контексти (например около Международния наказателен съд в Хага, който през есента на 2025г. се отказа от MS Office именно заради риск от "блокиране" или спиране на достъпа в следствие на американски санкции).
CLOUD Act (приет 2018г.) дава право на американските власти да изискват данни от всяка американска компания (Microsoft, Google, Amazon и др.), независимо къде тези данни се съхраняват, като при валидна съдебна заповед, те не могат да откажат. Дори данните да се намират в европейски дата центрове. Това влиза в директен конфликт с GDPR.
Тези опасения, както и появилия се след това стремеж към пълна или частична независимост от американските технологични гиганти са със сигурност стимул за европейската индустрия и за подкрепа за локални open-source проекти, разработчици и компании (напр. френски/латвийски инструменти).
Според привържениците, това ще доведе до редица положителни ефекти.
Постигат се по-добра прозрачност и контрол — кодът е отворен, може да се одитира за backdoors.
Спестявания — лицензите на Microsoft са скъпи; някои региони отчитат милиони евро икономии годишно.
Но миграцията е трудна и има редица технически трудности и предизвикателства.
Промяната изисква обучение на служители, осигуряване на съвместимост с legacy софтуер и може да доведе до временно намаляване на продуктивността (както в Мюнхен преди години).
Разходите в краткосрочен план — обучение, поддръжка, разработка на custom решения - може да се окажат болезнени или непосилни за някои райони, без сериозна държавна подкрепа.
И нека си признаем, не е реалистично, колкото и да е силна мотивацията за миграция към Linux и open-source решения.
Бизнесът и много европейски компании (над 70% според някои данни) все още разчитат на американски софтуер и основно MS Windows и Office. Пълно "отделяне" би навредило на конкурентоспособността, иновациите и интеграцията.
Докато държавите може би ще могат да отделят средства за миграцията и обучението на служителите си, при бизнеса съвсем не е така.
Да не забравяме геополитическите последствия. ЕС е 450 милионен пазар. Отношенията със САЩ (които виждат това като антиамерикански протекционизъм) със сигурност ще се влошат още повече, но пък това може да ускори развитието на европейски алтернативи.
С две думи, това е по-скоро стратегическо пренасочване, отколкото тотален отказ. Европа иска да намали риска от превръщането на технологичния монопол на САЩ в оръжие, както това става с американския долар, особено на фона на нестабилната политика в САЩ.
Дали ще успее в по-голям мащаб зависи основно от координацията на ЕС, инвестициите в обучение и качеството на open-source алтернативите.
Източник: https://techcrunch.com/2026/04/10/france-to-ditch-windows-for-linux-to-reduce-reliance-on-us-tech/
Използвани са и допълнителни източници за повече подробности.[Коментари: 0] |
|
|
|
|
|
| Основните промени в ядро 7.0
|
|
|
|
|
|
от DeepUltramarine на 13-04-2026@1:17 GMT(+2)
Дойде краят на 9 седмичния merge window и development cycle след Linux 6.19. Линус Торвалдс лично е тагнал и пуснал версията след една, бих казал, "спокойна" последна седмица с много малки фиксове. Той коментира, че много от тях вероятно идват от ИИ инструменти, които търсят да разширят възможностите докрай – и че това може да е "новото нормално" за известно време.
В анонса на Linux 7.0-rc7 (и в коментарите около последната седмица преди стабилното пускане) Линус Торвалдс отбелязва, че броят на малките поправки е по-голям от обичайното за този етап от цикъла. Повечето от тях са дребни, но реални. Не изглеждат страшни, но са забележимо повече.
Той предположи, че част от тях вероятно идват от ИИ инструменти (LLM модели като този на ChatGPT, Claude и подобни), които стават все по-добри в намирането и поправянето на грешки — редки и незабележими, които човек лесно пропуска при нормално писане на код или ревю.
Ето и по-подробен преглед на най-важните неща, базиран на KernelNewbies, merge-window summaries и анонсите във Phoronix и LKML:
Rust вече не е експериментален, що се отнася до ядрото на Linux.
Това е една от най-символичните промени. Rust поддръжката в ядрото започна експериментално по време на 6.1 (2022–2023), а в 7.0 статутът "experimental" официално отпада. Вече има по-добри Rust синхронизационни примитиви, поддръжка за PCI config space в Rust и подобрения за LTO (Link-Time Optimization) между Rust и C код. Това е голяма крачка към по-безопасен код (memory safety) в критични части на ядрото.
io_uring – добавени са нови филтри с cBPF (и наследяване по задачи).
Добавена е възможност за зареждане на BPF филтри (cBPF) върху io_uring операции. Филтрите се прилагат на ниво SQE (Submission Queue Entry) и се наследяват при fork(). Това решава сериозен проблем със сигурността. Досега io_uring беше толкова мощен, че Google плати $1M награда за откриване на уязвимости и го забрани в Chrome OS. Сега админите могат да ограничават точно кои операции са позволени (напр. в контейнери или cloud), без да го изключват напълно. Освен това има големи RX буфери (>4K), zero-copy в Netkit и други оптимизации.
Сcheduler: lazy preemption по подразбиране плюс time-slice extension
Премахнати са част от старите модели на прекъсвания (останали са само full и lazy). Lazy става по подразбиране за arm64, x86, RISC-V и др. Плюс десетгодишна patch серия за "time-slice extension" чрез rseq(2) – позволява на user-space нишките временно да удължат time slice-а си, за да не бъдат прекъсвани в критични секции (много полезно за user-space spinlocks и високопроизводителни приложения). Резултатът е по-бързи реакции и по-малко "спорове".
Имаме и няколко големи промени при файловите системи.
nullfs – нова минимална, immutable (непроменяема) която служи, който служи като истински root за йерархиите при монтирането. Улеснява pivot_root() в initramfs и контейнери.
XFS – автономно поправяне (автономно поправяне на метаданни и I/O грешки) плюс health monitoring чрез fsnotify. Събитията се доставят в реално време на потребителски процес (например systemd демон може да прави поправки без да блокира unmount).
При BTRFS е въведен експериментален remap tree за по-добра надежност при премествания и бъдещи оптимизации.
С помощта на remap-tree слоят за преобразуване на логическите адреси на блоковете позволява да се извършват промени, без да се преместват или презаписват блокове, за да се обработват премествания или други промени, изискващи копиране при запис.
Още, swap subsystem Phase II (≈20% подобрение на скоростта в redis-benchmark), fserror инфраструктура за унифицирано отчитане на файлови I/O грешки, по-добро предварително четене в NTFS3/exFAT и т.н.
При мрежите:
AccECN (Accurate Explicit Congestion Notification, RFC 9768) вече е активен по подразбиране.
AccECN вече е механизмът по подразбиране за сигнализиране на претоварване по TCP за всички нови връзки. Той беше достъпен като опция, която трябваше да се активира ръчно, в продължение на няколко версии на ядрото. От Linux ядро 7.0 нататък вече не се изисква потребителите да го активират ръчно.
Големи RX буфери в ZCRX и до 30% по-малко процесорно натоварване.
io_uring zero copy Rx (ZC Rx) е функция, която премахва копирането от ядрото към потребителското пространство по пътя на приемане в мрежата, като позволява пакетните данни да се приемат директно в паметта на потребителското пространство. Тази функция се различава от TCP_ZEROCOPY_RECEIVE, тъй като няма строги изисквания за подреждане и няма нужда от mmap()/munmap().
В сравнение с решенията за заобикаляне на ядрото, като например DPDK, хедърите на пакетите се обработват от TCP стека на ядрото по обичайния начин.
Много ъпдейти на драйвери за WiFi, Bluetooth, RDMA, Ethernet.
Промени при сигурността и криптирането:
Поддръжка на ML-DSA (post-quantum digital signature algorithm) в X.509, PKCS#7 и crypto subsystem.
Clang thread-safety analysis за compile-time проверка на блокировките, стъпил на LLVM Clang 22
Подобрения при seccomp/ Landlock / AppArmor / SELinux.
Други особености, които си струва да се споменат:
open_tree(2) с нов флаг OPEN_TREE_NAMESPACE за по-бързо създаване на container mount namespaces.
Много архитектурни ъпдейти (нови Qualcomm, MediaTek, Intel Nova Lake, AMD, Apple Silicon и т.н.).
Премахнати са някои legacy неща: SHA-1 за подписване на модулите, laptop_mode, част от стария initrd код и др.
Цикълът беше по-дълъг от обикновено.
Rc4 се проточи повече от очакваното заради networking pull request. Въпреки това, всичко мина сравнително гладко и 7.0-rc7 беше много чист. Ubuntu 26.04 LTS вероятно ще го вземе като default kernel.
Пълен списък с промените и новостите може да видите на https://kernelnewbies.org/Linux_7.0
Източник: https://www.phoronix.com/news/Linux-7.0-Released
Както и някои други.[Коментари: 0] |
|
|
|
|
|
| KDE - виртуални десктопи за всеки екран
|
|
|
|
|
|
от DeepUltramarine на 14-04-2026@11:20 GMT(+2)
Една заявка от KDE потребител още от юни 2005г. (по времето на KDE 3.3.2) най-накрая е изпълнена. След 21 години чакане, последният код на KWin вече поддържа виртуални десктопи отделно за всеки екран (per-screen desktops).
През 2005г. е подаден bug report/feature request, защото при два монитора с X11 Xinerama, когато сменя виртуален десктоп, и двата екрана се сменят едновременно. Тогавашната конфигурация е била dual 1280×1024.
Вчера е изпълнен merge request (на 4 месеца), който добавя поддръжка за per-output desktops в мениджъра на виртуални десктопи.
"VirtualDesktopManager вече следи текущия виртуален десктоп отделно за всеки output. По подразбиране сменя десктопа на всички екрани заедно, но вече има опция да се включва независима смяна за всеки екран."
Сега потребителите могат да сменят виртуалните десктопи независимо на всеки дисплей.
Свързаните merge requests към Plasma и KWayland също са слети. В merge request-а има всички технически детайли, плюс демо видео.
Важно уточнение:
Новата функция работи само на Wayland, не и на X11 или XWayland.
Очаквайте я в KDE Plasma 6.7.
Няма планове да се добави per-screen (независими виртуални десктопи за всеки монитор) към X11 в KDE Plasma. Тази функция разчита на архитектурата на Wayland, където всеки output (монитор) се третира по-независимо.
KDE планира постепенно да прекрати поддръжката на X11 (има обсъждания за замразяване и евентуално премахване около Plasma 6.8 или по-късно). Затова инвестират ресурси основно в Wayland.
На X11 има само частични workaround-и, като ограничаване на виртуалните десктопи само до primary монитора (добавено в Plasma 6.6) докато другите монитори остават "статични".
Или използване на Activities вместо виртуални десктопи (може да се настрои различно поведение).
Все още Wayland има сериозни проблеми с хибридния режим при конфигурации - вградена графика прюс Nvidia.
Което може да се окаже сериозна пречка, ако искате да изпробвате новата функционалност при KDE.
Ако все пак искате да го направите, можете да преминете временно само на Nvidia.
Източник: https://www.phoronix.com/news/KDE-Per-Screen-Virt-Desktops[Коментари: 0] |
|
|
|
|
|
| OpenSSL 4.0 е тук
|
|
|
|
|
|
от DeepUltramarine на 14-04-2026@15:03 GMT(+2)
Днес - 14 април 2026 - излезе OpenSSL 4.0.
Версията идва с важни нови функции, подобрения в сигурността и производителността, но също така има и доста премахвания на остарели неща. Като продължение на почистването, започнато в OpenSSL 3.0.
Какви са по-важните нови функции?
Encrypted Client Hello (ECH) поддръжка според RFC 9849.
Важно подобрение за поверителност в TLS.
Позволява криптиране на Client Hello съобщението още в началото на handshake-а, така че Server Name Indication (SNI) (т.е. името на сайта, към който се свързвате) да не се вижда в прав текст.
Това се явява наследник на стария ESNI и помага срещу цензура, проследяване и пасивно наблюдение това, кой сайт посещавате.
NMP KDF и SRTP KDF
Добавена е поддръжка за Key Derivation Functions, използвани в SNMP (мрежово управление) и SRTP (защитен RTP за VoIP/видео).
Добавени са китайски алгоритми, разработени и одобрени от Държавната криптографска администрация на Китай и post-quantum криптографски алгоритми.
Версия 4.0 осигурява поддръжка на signature алгоритъм sm2sig_sm3 (RFC 8998), Key exchange curveSM2 и Hybrid post-quantum curveSM2MLKEM768 (tls-hybrid-sm2-mlkem) — комбинация от класически SM2 и post-quantum ML-KEM.
Също така, осигурена е поддръжка на cSHAKE функция (SP 800-185).
Добавен е нов digest алгоритъм "ML-DSA-MU".
Поддръжка на negotiated FFDHE key exchange в TLS 1.2 (RFC 7919).
По-добри проверки при верификация на сертификати (AKID, augmented CRL verification).
FIPS модулът вече позволява отлагане на self-tests с опция -defer_tests.
Някои промени при API и подобрения в производителността:
BIO_snprintf() вече използва стандартния snprintf() от libc - подобрение в бързината.
Премахнато е глобалното почистване чрез atexit() в libcrypto.
Много API функции са направени opaque или с добавени const квалификатори.
ASN1_STRING вече е opaque.
Какво е премахнато (важно за разработчици)?
Напълно премахнати са:
SSLv2 Client Hello и SSLv3 (отдавна deprecated).
Поддръжката за engines (старият начин за hardware acceleration).
Стари конфигурационни target-и за macOS (darwin-i386, ppc и т.н.).
Скриптът c_rehash (заменен от openssl rehash).
Някои неработещи или остарели BIO и EVP методи.
Тагнати като Deprecated:
Поддръжка на стари elliptic curves в TLS (RFC 8422) – по подразбиране се изключва при компилация.
Някои функции за сравнение на време в X509 сертификати.
Custom EVP_CIPHER, EVP_MD, EVP_PKEY методи (вече не се препоръчват).
При печатане на ключове (hex dump) е премахнат допълнителният '00:' отпред в някои случаи и е стандартизирана ширината на dump-овете.
OpenSSL 4.0 има промени, които са несъвместими, особено ако ползвате стари deprecated API-та или engines. Затова официално се препоръчва да инсталирате версията от пакетите на вашата Linux дистрибуция (когато я обновят), вместо да компилирате ръчно, за да се избегнат проблеми със съвместимостта на приложенията.
Ако разработвате софтуер, който зависи от OpenSSL, прегледайте внимателно migration упътването и release notes на GitHub.
doc/designs/ech-api.md в сорс кода.
Обобщение на промените на: https://github.com/openssl/openssl/blob/master/NEWS.md
Подробен changelog: https://github.com/openssl/openssl/blob/master/CHANGES.md
Ако искате да видите точно какво се е променило от OpenSSL 3.6 към 4.0, най-добре отворете NEWS.md и релиз тага на GitHub (първият линк, който пуснах тук
Източник: https://9to5linux.com/openssl-4-0-released-with-support-for-encrypted-client-hello-snmp-kdf-and-more[Коментари: 0] |
|
|
|
|
|
| Nginx 1.30.0 бе пусната днес
|
|
|
|
|
|
от DeepUltramarine на 14-04-2026@18:49 GMT(+2)
Nginx 1.30.0 е най-новата стабилна версия на популярния уеб сървър, която беше пусната на 14 април 2026г. (днес).
Тя включва всички подобрения и поправки от mainline клона (1.29.x серията) и сега става препоръчителната стабилна версия за production.
Ето по-важните добавки и подобрения от последните месеци, които влизат в 1.30:
Multipath TCP (MPTCP) поддръжка чрез параметъра multipath в listen директивата (в 1.29.7). Позволява по-добра производителност и надеждност по множество мрежови пътища.
Sticky sessions за upstream сървъри (в 1.29.6) — нова директива sticky в upstream блока за session affinity (включително route и drain параметри за сървърите).
Early Hints (HTTP 103) — поддръжка за 103 Early Hints отговори от proxied backends плюс директива early_hints.
Бекендът трябва да изпрати информационен отговор 103 Early Hints заедно с Link хедъри, които казват на браузъра да започне да зарежда критични ресурси (CSS, JS, шрифтове и т.н.) преди да е получил финалния HTML (200 OK).
Nginx предава този отговор (103) към клиента, ако така е конфигуриран.
Encrypted ClientHello (ECH) — поддръжка за TLS ECH (с OpenSSL), директива ssl_ech_file.
max_headers директива — лимит върху броя на HTTP хедърите (в 1.29.8).
По-добър keepalive към upstream — по подразбиране се използва HTTP/1.1 с keep-alive (в 1.29.7), плюс нови директиви като proxy_force_ranges, proxy_limit_rate и параметър local в keepalive.
OpenSSL 4.0 съвместимост и други SSL подобрения (включително certificate compression, hardware tokens и т.н.).
Подобрения в HTTP/3 и QUIC, включително по-добро управление на пакети и сигурност.
Други:
wildcard в include вътре в geo блок, нови променливи ($request_port, $ssl_sigalg и др.), поддръжка за AWS-LC и BoringSSL.
Версията включва също поправки на няколко уязвимости от март 2026г. (buffer overflows в dav и mp4 модулите, проблеми с mail authentication, OCSP bypass и др.).
Препоръчително е да обновите, ако използвате по-стара версия.
Пакети за Windows и pre-built за Linux може да свалите от https://nginx.org/en/download.html
Пълен списък с промените може да видите на https://nginx.org/en/CHANGES-1.30
Не се бъркайте от това, че няма нищо точно за версия 1.30.
Четете всичко до 1.29 серията - 1.29.0 или 1.29.1.
Всички тези промени (нови функции плюс security fixes плюс bugfixes) са включени в 1.30.0 stable.
Бърза представа за промените може да добиете на https://github.com/nginx/nginx/releases/tag/release-1.30.0
Източник: https://www.phoronix.com/news/Nginx-1.30-Released[Коментари: 0] |
|
|
|
|
|
| Началото на края за i486 настъпи
|
|
|
|
|
|
от DeepUltramarine на 15-04-2026@6:37 GMT(+2)
Започна премахването на кода за Intel 486 (i486) процесори в Linux kernel версия 7.1.
Разработчиците (включително Ingo Molnar) са подготвили patch, който премахва опциите за конфигурация (Kconfig) CONFIG_M486, CONFIG_M486SX и CONFIG_MELAN.
Това означава, че от Linux 7.1 нататък няма да можем да компилираме ядро, което поддържа i486 клас процесори (включително различни варианти от AMD, Cyrix, IBM, Intel DX/DX2/DX4, UMC и AMD Elan).
Първата стъпка е само премахване на възможността за build. В следващите версии (вероятно 7.2) ще се изчисти и останалият код, свързан с тези стари процесори, за да се намали "бремето" върху разработчиците.
Linus Torvalds е одобрил промяната без проблеми и според коментарите няма "носталгия", която да го спре. Той и другите са на мнение, че поддръжката за толкова стар хардуер (от 1989г.) вече не си заслужава времето и създава излишни усложнения.
Тази промяна няма значение за почти никого в реалния свят.
Няма известни Linux дистрибуции, които все още предлагат i486 поддръжка. Хората, които все още ползват такива музейни експонати (ако има такива), могат да продължат с Linux 6.18 LTS или по-стари LTS версии и ще получават ъпдейти още години.
32-битовите процесори след i486 (т.е. от Pentium нагоре) остават поддържани (засега).
Intel i486 е на 37 години (излязъл 1989г. и спрян през 2007).
Поддръжката е била само "compatibility glue" – код, който поддържа стари неща, но забавя развитието и усложнява работата по ядрото. Разработчиците искат да се фокусират върху модерен хардуер.
Промяната вече е влязла в merge window за 7.1.
Ако имате стар 486 компютър и искате да го държате жив благодарение на Linux, можете да останете на LTS ядро. За всичко останало, нищо не се променя.
Източник: https://www.phoronix.com/news/Linux-7.1-Begins-Removing-i486[Коментари: 0] |
|
|
|
|
|
| €1000 за "Star Wars: Racer Revenge" за PS4
|
|
|
|
|
|
от DeepUltramarine на 15-04-2026@7:19 GMT(+2)
В края на 2025 и началото на 2026 г. дискът с играта се продаваше за $15–50.
Откакто хакери обявиха, че физическият диск на играта "Star Wars: Racer Revenge" за PS4 се използва за jailbreak (хакване) на конзоли PS5 и PS4 с firmware до 12.00 (и някои по-високи версии), цената на физическите носители с това заглавие се промени.
Играта е ремастър/порт на стара PS2 заглавие от 2002 г., издаден физически от Limited Run Games през 2019 г. (много малък тираж – около 8500–10 000 копия за стандартното издание).
В нея има бъг, особено в менюто "Hall of Fame", която позволява инжектиране на код (userland exploit, известен като mast1c0re или Luac0re).
Физическият диск не може да бъде "закърпен" от Sony (за разлика от цифровата версия), а PS5 може да чете PS4 дискове чрез backward compatibility.
Това дава входна точка за по-нататъшен kernel exploit и пълен jailbreak без нужда от интернет или други сложни похвати.
Хакът работи предимно с физическия PS4 диск (CUSA03474), не с оригиналната PS2 версия и не винаги с чисто цифровата покупка (макар че ако вече сте я имали, може да се използва в някои случаи).
След като хакерите обявиха ролята на диска с играта за PS5 jailbreak (31 декември 2025), цената скочи драстично – често $250–400+, а някои listings стигат и по-високо (до $500–1000 в зависимост от състоянието и търсенето).
Цените варират по сайтове като eBay, PriceCharting и т.н. – complete in box (CIB) версии често са около €200–400+, но могат да стигнат и по-високо при трескаво търсене.
Трябва да се подчертае, че Jailbreak-ването нарушава условията на Sony и може да доведе до бан на акаунта ви, загуба на онлайн права, проблеми с гаранцията или да има директни правни последствия срещу извършителя и не се препоръчва.
Настоящата публикация е с единствената цел - предоставяне на информация.
[Коментари: 0] |
|
|
|
|
|
| OS Age verfication на федерално ниво в САЩ?
|
|
|
|
|
|
от DeepUltramarine на 16-04-2026@5:34 GMT(+2)
На 13 април 2026г. в Конгреса на САЩ е внесен законопроект H.R. 8250 ("To require operating system providers to verify the age of any user of an operating system, and for other purposes").
Вносители са демократът Josh Gottheimer от Ню Джърси и републиканката Elise Stefanik от Ню Йорк.
Законопроектът е насочен към производителите на операционни системи (OS providers). Главно Microsoft (Windows), Apple (macOS/iOS), Google (Android/ChromeOS) и другите големи играчи.
Изисква се те да въведат проверка на възрастта на потребителя на ниво операционна система (OS-level age verification).
Това означава, че при създаване на нов акаунт на някое устройство операционната система трябва да пита за дата на раждане или възраст.
След това да предоставя "сигнал" (age bracket/signal) на приложенията и уебсайтовете. Например под 13, 13–15, 16–17 или 18+.
Целта е приложенията да могат автоматично да прилагат различни правила (по-строги за деца) без всяко приложение да прави своя собствена проверка.
Но бъдете спокойни!
Това не е задължителна строга верификация с паспорт или биометрия (поне според наличната информация засега), а по-скоро самоатестация плюс сигнал към приложенията, подобно на вече приетите щатски закони в Калифорния (AB 1043, който влиза в сила 2027г.) и предложените в Колорадо и други щати.
Пълният текст на законопроекта все още не е публично достъпен (към 15 април 2026), а е предаден на комисията по Енергетика и търговия в Камарата на представителите. Това е много ранен етап — може да бъде променен, отслабен или изобщо да не мине.
Статията от която взимам тази информация отразява реално внесения законопроект и реакциите в Linux и open-source общността - много хора се притесняват, че ще засегне и Linux дистрибуции, макар че те често нямат централен "provider" като Microsoft или Apple.
Преди време засегнах точно тази тема ( може да си я припомните тук) и тогава ясно споменах, че такъв тип закони, които навлизат грубо в личния живот на хората могат много бързо да се превърнат в slippery slope, в опасна тенденция. По всичко изглежда, че това става по-бързо, отколкото поне аз очаквах.
Проблемът поне според мен е сериозен. Ако големите технологични гиганти като Microsoft, Apple, Google и разработчиците на Ubuntu, Debian, Arch и RedHat са задължени да въведат това, те ще го направят глобално, за всички ни.
От това, до задължителна верификация чрез документи за самоличност за да може да използвате операционната си система, крачката е само една.
Не зная, какви са законите за защита на децата в САЩ, но в Европа си имаме предостатъчно от тях.
И то много строги правила за деца онлайн: DSA (Digital Services Act), GDPR (вкл. специални правила за деца), предложения за Child Sexual Abuse Regulation и национални закони във Великобритания (Online Safety Act), Франция и др.
Има силен натиск за проверка или подвърждение на възрастта на различни платформи, особено за порно, социални мрежи и друго "вредно съдържание". Някои страни обсъждат или въвеждат задължителни проверки.
Ако САЩ приемат предложението и то се превърне във федерален закон, това може да създаде глобален прецедент. Големите компании (Apple, Google, Microsoft) често прилагат еднакви политики в целия свят, за да не поддържат различни версии на операционните системи. Така че европейските потребители могат да видят подобна функция "по подразбиране" дори без европейски закон.
От друга страна, в ЕС има много по-силен фокус върху поверителност (GDPR забранява ненужно събиране на данни). Age verification на ниво ОС би предизвикало огромни дебати за масово следене, цензура и дискриминация. Privacy организации (като EFF в САЩ) вече критикуват подобни идеи като "постоянна възрастова класификация на устройството".
Малко вероятно е да видим директен европейски еквивалент на този конкретен законопроект.
Възможно е някои елементи да се появят чрез обновяване на DSA или нови предложения за "защита на децата".
Linux дистрибуциите (Debian, Ubuntu, Fedora и т.н.) традиционно се съпротивляват на такива изисквания, защото нямат централен "provider", който да ги наложи.
Но както и законите могат да се прокарват по заобиколни пътища и на части, това става и тук. Например през systemd, както вече видяхме.
Това е реален, но все още много ранен опит за преместване на отговорността за age checking от уебсайтовете и приложенията към самата операционна система. Мотивът е "защита на децата", но критиките са сериозни - повече събиране на данни, риск от злоупотреби, трудности за open-source и потенциално превръщане на всяко устройство в "възрастов контролер".
И докато ние правим догатки, докъде може да стигне това и как би ни засегнало, последните 2-3 години компании като Facebook силно подкрепят такива инициативи и дори силно лобират за закони, които прехвърлят отговорността за age verification от социалните мрежи към app stores (Apple, Google) и операционните системи.
Ако ОС или магазинът за приложения предоставя age bracket signal (напр. "под 13", "13–15", "16–17", "18+"), Meta вече не трябва да прави тежка собствена проверка на възрастта за всеки потребител.
Това намалява юридическата отговорност на Meta (особено по COPPA в САЩ, където "actual knowledge" че има деца под 13 може да доведе до огромни глоби).
Meta продължава да събира свои собствени данни за поведение, интереси и демография, но сега вече таргетираната реклама става по-ефективна и дори по-лесна, защото получава готов "официален" сигнал от ОС.
Освен това Meta лобира за изключения или по-леки правила за самите социални мрежи, докато натоварва конкурентите (Apple и Google) с разходи и инфраструктура.
Компанията е похарчила рекордни суми за лобиране. Десетки милиони долари директно плюс стотици милиони (според някои разследвания дори над $2 млрд. през "непрозрачни" nonprofits организации (като Digital Childhood Alliance) в подкрепа на щатски и федерални законопроекти от типа на App Store Accountability Act, Digital Age Assurance Act (Калифорния) и подобни.
Snap (Snapchat) и X (Twitter) в някои случаи са се присъединявали към Meta в joint letters, подкрепяйки прехвърляне на проверката към app stores и ОС.
Pinterest и някои по-малки платформи също са се обявили в подкрепа.
Google и Apple, разбира се, се съпротивляват (поне външно) на идеята да носят цялата отговорност и обвиняват Meta, че се опитва да прехвърли топката. Google и Apple предпочитат проверката да остане на ниво индивидуални приложения или да се сподели по-справедливо.
В Европа (DSA и обсъжданията около age assurance) също има разделение. Тук Meta също често лобира за device/app store level, докато отново Google и Apple имат различни предпочитания.
Много критици (вкл. privacy организации, EFF, независими анализатори и open-source общността) виждат в това класически регулаторен капан.
Докато социалните платформи печелят от по-лесно събиране и използване на данни, Apple и Google трябва да инвестират в инфраструктура за „age signal“, която после всички приложения (вкл. Meta) ползват.
Потребителите все повече губят поверителност (постоянно "възрастово етикетиране" на устройството).
Open-source системите (различните Linux дистрибуции) се оказват в трудно положение, защото нямат централен "provider" като Microsoft/Apple.
Това вече не е конспирация, а открита лобистка стратегия, която се вижда в публични лобистки декларации, щатски езслушвания и разследвания.
В Европа ситуацията с проверката на възрастта е доста по-различна от САЩ и се развива по-бавно, но с по-силен акцент върху поверителност и хармонизация на ниво ЕС.
Актуалната картина към април 2026г. е доста пъстра.
Основните регулаторни рамки са:
Digital Services Act (DSA) — главният закон (в сила от 2024г.). Изисква от платформите (особено Very Large Online Platforms като Meta, TikTok, YouTube) да оценяват и смекчават системните рискове за деца (чл. 34–35). Чл. 28 задължава платформите, достъпни за непълнолетни, да осигуряват "високо ниво на поверителност, безопасност и сигурност".
Не се изисква задължителна строга проверка на възрастта за всички платформи.
Самоатестацията (само да кажете възрастта си) често се смята за недостатъчна, особено за високорисково съдържание (порно, хазарт).
Комисията публикува насоки през 2025г., които препоръчват age assurance (оценка на възрастта) чрез комбинация от методи: самоатестация, age estimation (напр. анализ на лице/поведение) или истинска age verification с проверени източници.
А глобите са тежки — до 6% от глобалния оборот.
След това е EU Age Verification Blueprint ("мини-wallet" или interim app) — публикуван през юли-октомври 2025г.
Това е защитаващо личните данни решение, базирано на eIDAS 2.0 (Европейски цифров идентификатор). Позволява да докажете, че сте "18+" (или друг праг), без да давате име, дата на раждане или други данни на платформата — само анонимен "age token".
Въвежда се пробно в няколко държави (Франция, Дания, Италия, Испания и др.).
Целта е да се използва от платформите за съответствие с DSA, без масово събиране на данни.
Пълният EU Digital Identity Wallet се очаква да се разпространи през 2026г. и да интегрира това.
EDPB (European Data Protection Board) издаде становище през 2025г. с 10 принципа - потвърждението на личността трябва да е пропорционално, минимално инвазивно и да спазва GDPR (не се насърчава ненужно събиране на данни).
На ниво ОС проверка на възрастта в Европа не е задължително на ЕС ниво като предложеният в САЩ закон H.R. 8250.
Но има дебати и натиск да се премести част от отговорността към app stores (Apple, Google) или операционните системи — точно както в САЩ.
Meta (Facebook и Instagram) силно лобира за това.
Предлага "Digital Majority Age" (родителско одобрение при сваляне на приложения за тийнейджъри под 16) и проверка на ниво ОС/app store. Така Meta прехвърля тежестта и отговорността към Apple/Google, докато продължава да получава "age signal" и да събира свои данни за реклама.
Въпреки съпротивата, в някои държави има движение в тази посока (напр. UK — извън ЕС, но Apple вече въведе device-level age verification в iOS в съответствие с Online Safety Act).
Засега Франция е най-агресивна - закон за задължителна age verification за порно сайтове (SREN law), обсъжда се забрана на социални мрежи за под 15г. и е от първенците с EU blueprint.
В Германия има строги правила за младежка защита (JuSchG), изискващи въвеждането на различни мерки от платформите.
UK (не ЕС) си имат Online Safety Act изискващ "highly effective" age assurance, включително за порно; Apple вече реагира с промени на ниво ОС.
В други държави (Испания, Италия, Гърция и др.) бързат да въведат инструмента EU Age Verification Blueprint или обсъждат минимална възраст за социални мрежи (14–16г.).
Позицията на компаниите е същата като в САЩ.
Дори порно индустрията (например Aylo/Pornhub) лобира за прехвърляне на отговорността на ниво ОС или app store.
Това е картинката към момента.
Но според мен, свидетели сме само на началото и може би времето, когато ще трябва да се идентифицираме за да ползваме което и да е устройство, не е толкова далеч и почти сигурно ще го доживеем.
Източник: https://linuxiac.com/federal-bill-would-bring-os-level-age-verification-to-the-entire-us/
Използвани са и множество допълнителни източници за справки и повече подробности.
Бърза редакция ден по-късно:
Някак всичко става едновременно.
Напълно случайно, разбира се…
https://www.politico.eu/article/eu-says-age-verification-app-is-technically-ready/
[Коментари: 1] |
|
|
|
|
|
| Какво е IPv8
|
|
|
|
|
|
от DeepUltramarine на 20-04-2026@20:08 GMT(+2)
IPv8 е ново предложение за Internet Protocol Version 8, което се появи като IETF Internet-Draft през април 2026г. Авторът на предложението е J. Thain от One Limited.
Това не е официален стандарт, а просто чернова, която все още се обсъжда и може да отмине или да бъде променена.
IPv8 се опитва да реши няколко дългогодишни проблема на интернет, без да претърпи "болките" на IPv6.
Адресно пространство се състои от 64-битови адреси, вместо 32-битови при IPv4 и 128-битови при IPv6.
Които дават около 18 квинтилиона адреси (2⁶⁴). Достатъчно, за да се реши изчерпването на IPv4.
Форматът на адресите е r.r.r.r.n.n.n.n.
Първите 4 октета (r.r.r.r) са routing prefix (често базиран на ASN – Autonomous System Number).
Последните 4 октета (n.n.n.n) са за host частта.
Ако routing prefix е 0.0.0.0, адресът се третира точно като обикновен IPv4 адрес. Така IPv4 се явява като "подмножество" на IPv8.
Което означава пълна обратна съвместимост. Няма нужда от dual-stack (работа с IPv4 + IPv6 едновременно), няма "flag day" (ден, в който всички трябва да преминат към нова версия или правило), нито принудителна миграция. Съществуващите устройства и приложения продължават да работят без промяна.
IPv8 би трябвало да осигури и по-добро рутиране. Глобалната BGP таблица теоретично се ограничава до един запис на ASN, което би намалило драстично размера ѝ и би опростило рутирането в интернет.
Новопредложената версия не е само нов адресен формат.
Тя идва с допълнителни функции и цял протоколен инструментариум с вградени механизми за сигурност, управление, мониторинг, Zone Server платформа и т.н. Включва задължително удостоверяване на устройства (тук ми присветват червени предупредителни светлини), нови протоколи за L2/L3 и др.
Всеки управляем елемент в IPv8 мрежата (това включва почти всяко устройство - компютър, телефон, рутер, switch, IoT устройство и т.н.) трябва да се идентифицира преди да може да изпрати дори първия си пакет.
Това става чрез OAuth2 JWT токени (JSON Web Tokens).
Токените се издават и кешират локално от специален Zone Server (централен "мозък" на мрежата, който управлява DHCP8, DNS8, NTP8, logging, достъп и т.н.).
Устройството се свързва постоянно (persistent TCP/443) към Zone Server-а.
Удоствоверяването е на ниво хардуер/устройство и се обвързва с NIC (мрежовата карта), а не само на ниво потребител.
Ако устройството не успее да премине през процеса на удостоверяване, попада в силно ограничен режим (много нисък rate limit, например 10 пакета в секунда), което практически го прави неизползваемо за нормален трафик.
Според автора, целта е да се намали спуфинга (фалшифицирането на адреси), да се подобри сигурността на мрежата "от самото начало" и всички устройства да са идентифицирани и управлявани централизирано.
Това е една от основните критики към IPv8.
Идентификацията e на хардуерно ниво.
Всяко устройство има уникален "пръстов отпечатък" (JWT токен, обвързан с NIC). Анонимното свързване към мрежата (както е сега с IPv4 или IPv6) става много по-трудно или невъзможно в пълноценна IPv8 мрежа.
Друг повод за критика е универсалното логиране (NetLog8).
Zone Server-а събира телеметрия за почти всичко: кое устройство какво прави, кога, накъде се свързва. Това е задължително и унифицирано.
Централизирания контрол е още един причина за критика.
Всичко минава през Zone Server (egress validation). Администраторът (или който контролира Zone Server-а) може лесно да вижда, блокира или логва трафика на конкретно устройство.
В днешния интернет можете да смените MAC адрес, да се използва VPN/Tor, да се свържете през публичен Wi-Fi и да останете относително анонимен на ниво устройство. В IPv8 това става по-трудно, ако не и невъзможно, защото протоколът изисква постоянна идентификация.
Критиците (в Reddit, Hacker News, Substack и др.) го наричат директно "surveillance architecture" или "mandatory hardware identity binding".
Според тях IPv8 не просто подобрява сигурността, а вгражда механизъм за масово следене и контрол на мрежово ниво. Особено притеснително е, че това се прави на протоколно ниво (MUST в черновата), а не като опционална функция.
Релно, това важи главно за управлявани IPv8 мрежи (тези, които използват Zone Server). Ако някой просто използва IPv8 адреси без Zone Server (чисто адресиране), идентификацията може да не е задължителна.
В домашна или малка мрежа вероятно ще можете да я изключите или да я конфигурирате не толкова строго.
Ако имплементацията го позволява изобщо.
В корпоративни, операторски или държавни мрежи е много вероятно този механизъм да бъде включен на пълни обороти.
Засега това е само чернова, не реален стандарт. Повечето експерти я гледат доста накриво.
Според тях, черновата съдържа много детайли, които изглеждат прекалено амбициозни или нереалистични (например задължителни spanning tree протоколи, VRF-ове, постоянни връзки към Zone Server и т.н.).
Други я виждат като интересна идея, но са скептични, че ще мине през IETF процеса и ще бъде приета.
Днес идентификацията е на по-високо ниво (логин в сайтове, VPN, сертификати). IPv8 я сваля на L2/L3 ниво и я прави задължителна за самото изпращане на пакети. Това дава по-голяма видимост и контрол на мрежовите оператори (ISP, компании, държави).
Привържениците казват, че това ще направи мрежата по-безопасна срещу хакове, DDoS и анонимни атаки.
Но на фона на днешната външно и вътрешно политическа обстановка в по-голямата част от света, засилващите се стремежи за масово следене на популацията на световно и държавно ниво, рискът за злоупотреба с този механизъм на IPv8 става неприемлив, а цената може да е пагубна.
В миналото е имало и по-стари предложения за IPv8 (през 90-те години, като Pip протокола например), но те са били отхвърлени в полза на IPv6.
Повече за предложението можете да научите от тук[Коментари: 3] |
|
|
|
|
|
| HDMI FRL поддръжка в Nouveau за Nvidia
|
|
|
|
|
|
от DeepUltramarine на 25-04-2026@9:57 GMT(+2)
Благодарение на David Airlie от Red Hat е постигната поддръжка на HDMI FRL (Fixed Rate Link) под Linux в open-source драйвера Nouveau за графичните карти на NVIDIA.
HDMI FRL е част от спецификацията на HDMI 2.1 и позволява по-високи резолюции и честоти на опресняване през HDMI кабел.
За разлика от AMD (където HDMI 2.1 среща проблеми заради HDMI Forum), при NVIDIA това е възможно, защото GSP firmware (GPU System Processor) на NVIDIA поема голяма част от тежката работа.
D. Airlie е тествал успешно с Ampere GPU и HDMI 2.1 capture карта.
Той е изпратил серия от 4 поправки в mailing list-а на Nouveau.
В коментар казва още, че с GSP firmware трябва просто да се подава информацията в правилния ред и да се прави link training в точните моменти.
Той също споделя, че е използвал Claude Code (AI инструмент), за да итерира и реши проблеми с последователността на операциите, за да съвпадне с програмните последователности при NVIDIA.
Промените се очаква да влязат в mainline ядрото някъде около Linux 7.2 (лятото на 2026г.).
Това е много добра новина за хората, които използват open-source драйвера Nouveau на NVIDIA под Linux.
Досега с Nouveau HDMI поддръжката беше ограничена главно до HDMI 2.0 нива (до ≈18Gbps). С добавянето на HDMI FRL се отключват по-високите режими на HDMI 2.1 като 4K при 120Hz (или дори по-високо) или 8K при 60 Hz.
Подобрява се и качеството на изображението, а също ще имаме и по-добра поддръжка на VRR (Variable Refresh Rate), Dynamic HDR и други HDMI 2.1 функционалности.
Това важи особено за потребители с по-нови NVIDIA карти (от Ampere нагоре, които имат GSP firmware).
Важно е да се уточни, че ако вече използвате официалния proprietary драйвър на NVIDIA (nvidia-driver), вероятно вече имате HDMI 2.1/FRL поддръжка от години. Тази промяна е голяма стъпка именно за чисто open-source стека (Nouveau + Mesa).
В старите HDMI версии (до 2.0) се използва TMDS (Transition-Minimized Differential Signaling). Там има отделен clock канал и максимум ≈18Gbps bandwidth.
При FRL часовникът се вгражда директно в данните, използват се до 4 ленти за данни, всяка с фиксирана скорост (3, 6, 8, 10 или 12 Gbps). Така общият bandwidth стига до 48 Gbps (uncompressed).
Благодарение на това се постигат по-високи резолюции и refresh rates (4K 120Hz, 8K 60Hz и т.н.), имаме по-ефективно използване на кабела (link training определя оптималната скорост) и си осигуряваме поддръжка на нови функции като Dynamic HDR, по-добър VRR и т.н., специфични за HDMI 2.1.
HDMI 2.1 спецификациите (включително FRL) са под строг контрол - NDA (споразумение за неразгласяване).
HDMI Forum не позволява пълна open-source имплементация, защото се страхуват от нарушаване на лицензите и DRM (защита на съдържанието).
При AMD (amdgpu драйвъра) това е голям проблем от години. Те имат хардуерната поддръжка, но не могат да я пуснат в open-source ядрото без да нарушат договора с HDMI Forum.
Затова на AMD под Linux през HDMI често се ограничаваш до 4K 60Hz или 4K 120Hz с намалено качество (4:2:0 chroma или chroma subsampling).
Тъй като окото ни вижда по-слабо цветните детайли в сравнение с яркостта, можем да "спестим" цветна информация, без да се забелязва голяма разлика в обикновени филми, видео или при видео игри. Това позволява по-висока резолюция или по-висок refresh rate при ограничена пропускателна способност на кабела.
Но за това, разбира се, ви трябва и подходящ кабел.
Не забравяйте да проверите, какъв точно използвате!
Източник: https://www.phoronix.com/news/HDMI-FRL-On-Nouveau-Linux
Използвани са и други източници за допълнителна техническа информация.
[Коментари: 0] |
|
|
|
|
|
| Новото при QEMU 11.0
|
|
|
|
|
|
от DeepUltramarine на 25-04-2026@10:56 GMT(+2)
QEMU 11.0 беше пуснат на 22 април 2026 и е поредната голяма версия на популярния open-source емулатор и виртуализатор.
Съдържа над 2500 commits от 237 автора.
Версията идва с:
Вградена поддръжка за AWS Nitro Enclaves.
Нов "nitro" accelerator и машина тип nitro, с които можете да стартирате Nitro Enclaves директно под QEMU (много полезно за тестване на AWS confidential computing без реален хардуер).
При KVM - CET virtualization.
Поддръжка за Control-flow Enforcement Technology (Intel CET) във виртуални машини през KVM. Това подобрява сигурността срещу определени видове атаки (ROP и т.н.).
Допълнително при KVM - Reset за confidential VMs.
Вече можете да рестартирате машини с AMD SEV-SNP и Intel TDX без да ги спирате напълно.
virtio-gpu
Поддръжка за native context drivers и възможност за задаване на различна резолюция на всеки изход (output).
Някои архитектурни подобрения:
x86
Нов CPU модел: Intel Xeon Diamond Rapids.
RISC-V
Добавени разширения: ZALASR, Zilsd, Zclsd, Smpmpmt.
LoongArch
Повече инструкции в TCG (SC.Q, LLACQ/SCREL, estimated reciprocal и др.), плюс PMU migration за KVM.
MIPS — Нов CPU: P8700
ARM
Поддръжка за FEAT_ASID2 и FEAT_E2H0, ускорение на SMMUv3 IOMMU, TCG емулация на SME (без SVE), възможност за стари OABI binaries, и нови свойства за virt машината (kvm-psci-version, virtio-mmio-transports).
От по важните промени:
Премахнати са старите и остарели PC машини: i440FX и Q35 от версии 2.6/2.7 (и някои още по-стари). Ако все още ползвате много стари архитектури, ще трябва да ги обновите.
Подобрения в блок устройствата (NFS с libnfs v6, curl, FUSE), IO_uring, NVMe и като цяло, подобрена I/O производителност.
Подобрена поддръжка за MSHV и WHPX accelerators.
TCG вече поддържа C++ plugins директно в дървото.
Ако ползвате QEMU основно с KVM за Linux/Windows вирутални машини, най-интересни биха били CET, reset на confidential VMs и virtio-gpu подобренията.
За разработчици на embedded/RISC-V/LoongArch/ARM има доста нови неща - TCG C++ Plugins, qemu_plugin_set_pc() за пренасочване на program counter, нов discontinuity callback (полезен при прекъсвания, изключения, host calls), в linux-user режим API за филтриране на syscalls, FUSE block export и други.
По-горе споменах още няколко.
Официалния анонс може да погледнете на https://www.qemu.org/2026/04/22/qemu-11-0-0/
За повече подробности, пълния changelog ще намерите на https://wiki.qemu.org/ChangeLog/11.0
Източник: https://www.phoronix.com/news/QEMU-11.0-Released[Коментари: 0] |
|
|
|
|
|
| Подобренията и новостите при Firefox 150
|
|
|
|
|
|
от DeepUltramarine на 25-04-2026@12:46 GMT(+2)
Firefox 150 излезе официално на 21 април 2026 година.
Това е поредната голяма версия с няколко полезни подобрения в интерфейса, сигурността и PDF редактора.
Ето, кои са най-важните нови неща…
Split View (разделен изглед) е значително подобрен:
Можете да щракнете с десен бутон върху всяка връзка и да изберете "Open Link in Split View" и се отваря директно до текущата страница.
Добавена е възможност за търсене сред отворените табове, когато създавате split view.
Нова опция "Reverse Tabs" в контекстното меню на табовете, която бързо разменя позициите на двата панела.
Споделяне/копиране на множество табове наведнъж:
Изберете няколко таба > десен клик > Copy X Links (или Share → Copy X Links на macOS).
При поставяне в други приложения се копират и заглавието, и web адресът (ако приложението поддържа rich text).
PDF редакторът във Firefox става още по-мощен и полезен.
Сега можете директно да премествате, копирате, поставяте, изтривате и експортирате страници от PDF файл.
Изключително удобно, ако често боравите с PDF-и без външни програми.
Някои други важни промени:
Ограничения за достъп до локалната мрежа.
Вече се прилагат за всички потребители (не само при Strict Tracking Protection). Сайтовете трябва да искат разрешение, преди да се свързват с устройства в локалната ви мрежа или приложения на устройството. Това е подобрение на сигурността.
Поддръжка на GTK emoji picker на Linux.
Можете да вмъквате емоджита със системния shortcut (обикновено Ctrl + .).
Real-time private translations
Можете да тествате страницата about:translations за преводи на живо без да се изпращат данни навън.
Глобално разгръщане на новата система за управление на профили (включително backup на профила като файл. Засега само за Windows).
Версията включва поправки на над 270 уязвимости (включително 41 CVE в някои отчети).
Обновяването е силно препоръчително.
Пълните release notes можете да видите от тук: https://www.mozilla.org/en-US/firefox/150.0/releasenotes/
Източник: https://linuxiac.com/mozilla-firefox-150-now-available-for-download/[Коментари: 0] |
|
|
|
|
|
| Canonical ще интегрира ИИ в Ubuntu
|
|
|
|
|
|
от DeepUltramarine на 27-04-2026@11:28 GMT(+2)
Canonical обяви намерението си за бъдещо добавяне на ИИ функции в Ubuntu през 2026 година.
Ubuntu не става ИИ продукт, както Microsoft се опитват да направят с Windows, но Canonical планира да го направи "по-силен" чрез внимателна интеграция на изкуствен интелект.
След пускането на Ubuntu 26.04 LTS (Resolute Raccoon, пуснат преди няколко дни), през цялата 2026г. ще започнат да се добавят различни ИИ функции.
Фокусът е върху локално изпълнение (local inference) по подразбиране. ИИ моделите да работят ефективно на хардуера на потребителя, без задължително да разчитат на облак.
Планира се Ubuntu да бъде context-aware OS. Операционната система да стане по-"осъзната" за контекста на потребителя и да помага по-интелигентно.
Ще има възможност за Agentic workflows - интегриране на ИИ агенти които да могат да изпълняват задачи автономно, но само за тези, които ги искат.
Подобряване на съществуващи функции с ИИ (напр. интерпретация на системни логове на сървъри).
По-мощни accessibility функции за по-добра достъпност за хора с увреждания чрез ИИ.
От Canonical подчертават, че всичко ще се добавя обмислено, без да се нарушава сигурността и в съответствие с open-source ценностите на Ubuntu.
Jon Seager (VP of Engineering в Canonical):
През 2026г. ще работим за предоставяне на достъп до frontier AI за потребителите на Ubuntu по начин, който е обмислен, сигурен и съобразен с нашите open-source ценности. (…) Ще доставим ефективно локално inference, мощни accessibility функции и context-aware OS, която прави Ubuntu значително по-капацитетен.
Заради тези си намерения в Canonical ще добавят в Ubuntu директна поддръжка на Nvidia CUDA. Ще може да се инсталира направо от хранилищата чрез познатата команда apt install.
Същото и за AMD ROCm.
Ще бъде подобрена и поддръжката за Intel NPU (Neural Processing Unit) и други хардуерни ускорители.
Това ще направи Ubuntu много по-лесен и приятен за разработка и production на ИИ модели, както и за работа с тях, без предишните главоболия с драйвери и зависимости.
Canonical вече предлага и други ИИ инструменти:
Inference Snaps: лесен начин за инсталиране и стартиране на ИИ модели, оптимизирани за конкретния хардуер.
Charmed Kubeflow и Charmed MLFlow за MLOps (Machine Learning Operations).
Поддръжка за edge ИИ на различни платформи (MediaTek Genio, Qualcomm, Arduino и др.).
През 2026г. се очаква разширяване на тези възможности, с акцент върху локално изпълнение, sandboxing на ИИ агенти (чрез LXD и др.) и по-дълбока интеграция в десктопа и сървъра.
Накратко, това е следващата фаза след Ubuntu 26.04. Не революционни "ИИ навсякъде" промени, а постепенна, обмислена еволюция към по-интелигентна и контекстно осъзната операционна система, със силен фокус върху локалния хардуер, локално изпълнение и open-source принципи.
Как това ще бъде прието от потребителите след като всички видяхме неистовите напъни на Microsoft да вгради и наложи ИИ на всички нива в тяхната ОС, ни предстои да видим.
За автоматизация, аз бих продължил със старите методи - BASH/Python скриптове, cron jobs или systemd scheduling и custom servises, както и някои други похвати.
Операционната система е инструмент и всеки майстор трябва да познава инструментариума си, за да е ефективен и продуктивен независимо от обстоятелствата.
Не всеки хардуер ще разполага с CUDA, ROCm или NPU.
"Линукс за българи" не е медия и затова добавих и личното си мнение относно интегрирането на ИИ в операционните системи.
За много хора това би било удобство, особено за новаците при използването на Linux или за хора с различни физически увреждания.
Но според мен, тези инструменти не следва да идват още с инсталацията, а да се добавят само при желание.
Така системата ще бъде по-лека, по-продуктивна и по-пъргава.
А може и да научите нещо, ако оставите настрани ИИ и отделите малко време на документацията и изобилието от how to и уроци в интернет.
Източник: https://www.phoronix.com/news/Ubuntu-AI-Features-2026[Коментари: 0] |
|
|
|
|
|
| Ядро 7.1 с realtime поддръжка за x32 ARM
|
|
|
|
|
|
от DeepUltramarine на 28-04-2026@11:19 GMT(+2)
Започвайки от Linux 7.1 (в момента е в rc1 към април 2026г.), вече ще може да се компилира реално-времево ядро за класическия 32 битов ARM директно от основния източник на Linux, без да са нужни никакви външни кръпки (patches).
PREEMPT_RT е голям набор от промени в Linux ядрото, който го превръща в операционна система с работа в реално време (Real-Time Operating System – RTOS).
В обикновеното Linux ядро има много процеси (като обработка на прекъсвания, заключвания и дълги операции в ядрото), които забраняват прекъсването на задачите. Това води до непредвидими закъснения при изпълнението на по-важните задачи.
С PREEMPT_RT почти цялото ядро става прекъсваемо (preemptible).
Заключванията (spinlocks) се превръщат в нормални mutex-и, които позволяват на високоприоритетни реално-времеви задачи да прекъсват ядрото много по-надеждно.
В обикновеното Linux ядро се използва механизъм, наречен spinlock.
Той е много бърз, но си има недостатък - докато един процес държи spinlock, другите задачи чакат и се въртят в празен цикъл, а често не могат да обработват и прекъсвания, ако са използвани spin_lock_irq() или spin_lock_irqsave().
Това прави spinlock-а много бърз за кратки критични секции, но лош вариант за обработна на задачи в "реално" време, защото създава непредвидими и често, дълги закъснения.
С PREEMPT_RT ядро нещата се променят значително.
Обикновените spinlock_t се превръщат в rt_mutex (т.е. работят като mutex). Прекъсванията не се забраняват докато се държи такъв lock.
Mutex-a е механизъм (инструмент) в програмирането и операционните системи, който служи да предпази споделен ресурс (например променлива, масив, файл или част от паметта), така че само една задача (нишка или процес) да може да го използва в даден момент.
Това предпазва данните от промени по време на изпълнението на един процес, от друг, като по този начин се предотвратяват нежелани и непредвидими резултати.
Ако друга задача иска да работи с данните, тя подава заявка за това до ядрото и се нарежда на опашката, като задачите могат да бъдат прекъснати от по-високоприоритетни реално-времеви такива, след като завършат критичната си част и освободят сами "ключалката".
Такава е и целта на PREEMPT_RT - да направи ядрото по- "прекъсваемо" и предвидимо. Синхронизация на процесите според приоритета им. Механизмът е малко по-сложен, не тук няма да навлизаме в такива детайли - preemption, priority inheritance, Threaded interrupts, Preemptible RCU, премахване или намаляване на дълги участъци, в които се забраняват прекъсванията (irq disable), както и по-добро управление на приоритетите в scheduler-а за реално-времеви задачи (SCHED_FIFO, SCHED_RR, SCHED_DEADLINE).
С това не претендирам, че самият аз разбирам как се случва всичко това. :)
Линковете са за заинтересованите.
Вградената поддръжка на "реалновремеви" процеси в 7.1 ще е много важна за системи, които изискват гарантирано и предвидимо време за реакция.
При индустриалния контрол (PLC, автоматизация), в роботиката, при професионална обработка на звук (иска се ниска латентност), при автомобилите, в CNC машини, в медицината, както и в огромното множество от embedded устройства с изисквания за работа в реално време.
Последната голяма пречка при 32-битовия ARM беше свързана с обработката на грешки в ARM архитектурата. Тя беше поправена точно преди излизането на Linux 7.1-rc1. След това RT екипът обяви, че всички специфични кръпки за ARM вече са ненужни и всичко необходимо вече е в основното ядро.
Така 32-битовият ARM се нарежда до останалите архитектури, които вече имаха тази поддръжка - x86 / x86_64, ARM64, RISC-V.
Вече няма да е нужно да се поддържат и пренасят външни кръпки при всяка нова версия на ядрото. Просто включвате една опция в конфигурацията.
Това осигурява и по-добра дългосрочна поддръжка и сигурност. Можете да използвате най-новото основно ядро с всички поправки и подобрения, вместо да стоите на стари версии с кръпки.
Ще бъде по-лесно и за дистрибуциите.
Разпространители като Yocto, Debian, Ubuntu и други могат по-лесно да предлагат официални реално-времеви ядра за стари и нови ARM платки (BeagleBone, Raspberry Pi в 32-битов режим, индустриални контролери и т.н.).
И докато се говори за реално време, следва да се уточни, защо поставях този израз в кавички.
Дори с RT ядро, реалното време за обработка зависи много от хардуера. Колко бързо се обработват прекъсванията, кеш паметта, скоростта на трансфер на данните, драйверите и т.н..
То не превръща обикновен процесор в твърдо реално-времев микроконтролер. Някои драйвери все още трябва да се настройват внимателно за критични приложения.
С две думи, това е поредната важна крачка (след почти 20 години работа) към превръщането на основното Linux ядро в добра платформа за работа в реално време на почти всички популярни архитектури. За хората, които работят с реално-времеви системи на по-стари ARM платки, новината е наистина добра.
Излизането на Linux kernel 7.1 се очаква да е някъде през юни.
Източник: https://www.phoronix.com/news/Linux-7.1-ARM-RT
Използвани са и други източници, за допълнителна техническа информация.[Коментари: 0] |
|
|
|
|
|
| Изненадващо развитие на пазара за лаптопи
|
|
|
|
|
|
от DeepUltramarine на 28-04-2026@15:18 GMT(+2)
Framework е американска компания основана не толкова отдавна (през 2020г.), която прави модулни, лесни за ремонтиране и изключително лесни за ъпгрейд лаптопи. Един от малкото производители - ако не и единствения - с такава философия.
Можете лесно да смените почти всичко - процесор (в някои модели), RAM, SSD, клавиатура, дисплей, портове (чрез сменяеми Expansion Cards).
Лаптопите са с много добра поддръжка на Linux от самото начало на компанията.
Дори продават DIY (do it yourself) пакет за по-запалените ентусиасти. Сглабяте си машината сами.
Най-новият им лаптоп - Laptop 13 Pro - е и най-производителният засега. С мощни процесори (AMD Ryzen AI 300 или Intel), тънък и лек корпус, добър дисплей 3:2 и физически превключватели за камера/микрофон (privacy switches).
Но какво е любопитното в случая?
Framework Laptop 13 Pro конфигурациите с предварително инсталирана Ubuntu Linux се продават по-добре от същите конфигурации с Windows 11.
Това е необичайно, защото от години производителите на лаптопи (Dell, HP, Lenovo и др.) твърдят, че "няма търсене на Linux" и затова почти не предлагат такива модели с предварително инсталирана Linux система. Framework обаче дава реален избор при поръчка - Windows или Ubuntu. И хората по-често избират Ubuntu.
Framework обявиха това в Х (Twitter). Лаптопът се продава много над очакванията (първите 6–8 партиди са се изчерпали бързо), а Ubuntu вариантите са с по-голям обем от продажбите от Windows вариантите на идентична хардуерна конфигурация.
Авторът на статията от която преразказвам прави някои заключения.
Когато хората имат реален и лесен избор (а не "Windows или сам си инсталирай Linux и се оправяй с драйверите и всичко останало"), много от тях избират Linux.
Много купувачи не искат Windows заради телеметрията (реално шпиониране на потребителите от Microsoft), реклами (въпреки, че си плащате за системата), нежелания от почти никой ИИ Copilot и т.н.
Което опровергава твърдението на големите производители, че "Linux е само за маниаци".
Framework обслужва ниша от хора, които са готови да платят 1500–2500+ долара за лаптоп, който е лесно се ремонтира и уважава свободата им на избор. До степен, да могат да си избират сами компонените ма на машината и да ги подменят по желание.
Това обаче е малка компания и продава директно. Клиентите им са предимно ентусиасти, разработчици, хора, които ценят правото си на избор и Linux в това число.
Много купувачи на Framework и без това най-вероятно щяха да изтрият Windows и да сложат Linux. Сега просто избират Ubuntu още при поръчката и спестяват от лиценз.
Всичко това не означава, че на масовия пазар Ubuntu внезапно ще изпревари Windows, но е силен сигнал, че търсенето на качествени Linux лаптопи съществува.
В самата статия има и скрийншот (взет от поста на момчетата от Framework в Х/Twitter) на който ясно може да се види, че лаптопите с Ubuntu са разпродадени предварително и новите купувачи ще си получат поръчката най-рано през юли.
Въпреки, че може да гадаем за относителната социална принадлежност и интересите на купувачите на лаптопите на Framework с предварително инсталирана Ubuntu, самият факт е може би сигнал, че все повече хора искат да поемат глътка свеж въздух, а не бутилираната от десетилетия, застояла и вече задушаваща корпоративна атмосфера.
Източник: https://linuxstans.com/frameworks-ubuntu-laptops-are-outselling-windows/
Настоящия материал не е спонсорирана публикация.
Въпреки, че с удоволствие бих пробвал една от тези машинки.[Коментари: 0] |
|
|
|
|
Общо новини за този период: 23 |
