Китайские хакеры, предположительно действующие при поддержке государства, более полугода имели возможность запускать бинарники на компьютерах пользователей Notepad++
Детали компрометации Notepad++, осуществлённой китайскими государственными хакерами:
- В июне 2025 года был скомпрометирован сервер обновлений Notepad++. Это позволило вредоносным бинарным файлам загружаться и выполняться через механизм обновления Notepad++.
- По словам исследователя в области кибербезопасности Кевина Бомонта, взлом был осуществлён группировкой «Funky Stamen» (также известной как «Judgment Panda»), связанной с Китаем.
- Автор Notepad++ также заявил, что, по всей вероятности, атака была проведена «китайской группой, спонсируемой государством».
- Бомонт сообщает, что по состоянию на 2 декабря 2025 года он получил сообщения от «небольшого числа пострадавших», которые представляют собой организации с интересами в Восточной Азии, и которые фиксируют подозрительную активность, начиная с сентября или октября.
- 18 ноября 2025 года разработчик Notepad++ выпустил обновление версии 8.8.8, в которое был включён патч для апдейтера в связи с «потенциальной проблемой перехвата», отметив, что он «находился в контакте с рядом экспертов по безопасности на протяжении последних двух недель». На тот момент никаких дополнительных деталей пользователям предоставлено не было.
- Разработчик Notepad++: «Я оцениваю общий период компрометации как промежуток с июня по 2 декабря 2025 года, когда весь доступ злоумышленников был окончательно устранён».
notepad-plus-plus.org/news/hijacked-incident-info-update/
https://doublepulsar.com/small-numbers-of-notepad-users-reporting-security-woes-371d7a3fd2d9
https://cyberplace.social/@GossiTheDog/115695929481595809
@linuxos_tg
Детали компрометации Notepad++, осуществлённой китайскими государственными хакерами:
- В июне 2025 года был скомпрометирован сервер обновлений Notepad++. Это позволило вредоносным бинарным файлам загружаться и выполняться через механизм обновления Notepad++.
- По словам исследователя в области кибербезопасности Кевина Бомонта, взлом был осуществлён группировкой «Funky Stamen» (также известной как «Judgment Panda»), связанной с Китаем.
- Автор Notepad++ также заявил, что, по всей вероятности, атака была проведена «китайской группой, спонсируемой государством».
- Бомонт сообщает, что по состоянию на 2 декабря 2025 года он получил сообщения от «небольшого числа пострадавших», которые представляют собой организации с интересами в Восточной Азии, и которые фиксируют подозрительную активность, начиная с сентября или октября.
- 18 ноября 2025 года разработчик Notepad++ выпустил обновление версии 8.8.8, в которое был включён патч для апдейтера в связи с «потенциальной проблемой перехвата», отметив, что он «находился в контакте с рядом экспертов по безопасности на протяжении последних двух недель». На тот момент никаких дополнительных деталей пользователям предоставлено не было.
- Разработчик Notepad++: «Я оцениваю общий период компрометации как промежуток с июня по 2 декабря 2025 года, когда весь доступ злоумышленников был окончательно устранён».
notepad-plus-plus.org/news/hijacked-incident-info-update/
https://doublepulsar.com/small-numbers-of-notepad-users-reporting-security-woes-371d7a3fd2d9
https://cyberplace.social/@GossiTheDog/115695929481595809
@linuxos_tg
В эти выходные ведущий разработчик uutils (переписывания GNU Coreutils на Rust, которое поставляется в Ubuntu) выступил с докладом на FOSDEM под названием:
Судя по всему, это выступление в основном было попыткой сгладить ущерб.
Прозвучало несколько заявлений в духе: «Никакого заговора нет», «Никакого скоординированного плана захвата нет», «Дело не в лицензии».
Также были озвучены типичные, одобренные «Культом Rust», тезисы, вроде: «C — это язык из прошлого!»
В презентации были приведены несколько высказываний людей, названных «троллями», которые ставили под сомнение логику переписывания GNU Coreutils на Rust, а также «ответы» этим «троллям». Всё это было очень аккуратно отобрано, чтобы обойти стороной те опасения, которые невозможно логически опровергнуть.
Судя по всему, презентация достигла желаемого пропагандистского эффекта для Культа Rust, поскольку новостное медиа Phoronix довольно быстро написал статью по мотивам доклада под заголовком:
По версии Phoronix, «презентация также указывает на некоторые популярные троллинговые аргументы вокруг Rust Coreutils и в конечном итоге показывает, что многие из этих комментаторов оказались неправы». Среди них:
- Опасения по поводу смены лицензии исходного кода (с GPL на MIT).
- Замена функционально богатого ПО на незавершённое ПО (в котором до сих пор отсутствуют значимые возможности).
- Замена хорошо протестированного ПО на почти не протестированное (не проходит даже самые упрощённые тест-сьюты, по качеству всё ещё alpha).
- Принудительное навязывание языка программирования, основанное на идеологии и убеждениях, а не на инженерных требованиях и решении задач.
Особенно удивляет, что один из ключевых аргументов, высказанных «троллями», сводится всего лишь к следующему:
Однако стремление защитить Культ Rust настолько сильно, что технические журналисты готовы завязываться в ментальные узлы, лишь бы атаковать «троллей». В результате они умудряются соглашаться с «троллями» в первой части заголовка («Rust Coreutils продолжает движение к 100% совместимости с GNU»), и одновременно провозглашать победу над злыми «троллями» во второй части заголовка («Доказывая, что тролли были неправы»).
fosdem.org/2026/schedule/event/DTYYL9-rust-coreutils/
https://phoronix.com/news/Rust-Coreutils-FOSDEM-2026
@linuxos_tg
«Rust Coreutils в Ubuntu: да, мы переписали /bin/true на Rust — вот что на самом деле произошло»
Судя по всему, это выступление в основном было попыткой сгладить ущерб.
Прозвучало несколько заявлений в духе: «Никакого заговора нет», «Никакого скоординированного плана захвата нет», «Дело не в лицензии».
Также были озвучены типичные, одобренные «Культом Rust», тезисы, вроде: «C — это язык из прошлого!»
В презентации были приведены несколько высказываний людей, названных «троллями», которые ставили под сомнение логику переписывания GNU Coreutils на Rust, а также «ответы» этим «троллям». Всё это было очень аккуратно отобрано, чтобы обойти стороной те опасения, которые невозможно логически опровергнуть.
Судя по всему, презентация достигла желаемого пропагандистского эффекта для Культа Rust, поскольку новостное медиа Phoronix довольно быстро написал статью по мотивам доклада под заголовком:
«Rust Coreutils продолжает движение к 100% совместимости с GNU, доказывая, что тролли были неправы»
По версии Phoronix, «презентация также указывает на некоторые популярные троллинговые аргументы вокруг Rust Coreutils и в конечном итоге показывает, что многие из этих комментаторов оказались неправы». Среди них:
- Опасения по поводу смены лицензии исходного кода (с GPL на MIT).
- Замена функционально богатого ПО на незавершённое ПО (в котором до сих пор отсутствуют значимые возможности).
- Замена хорошо протестированного ПО на почти не протестированное (не проходит даже самые упрощённые тест-сьюты, по качеству всё ещё alpha).
- Принудительное навязывание языка программирования, основанное на идеологии и убеждениях, а не на инженерных требованиях и решении задач.
Особенно удивляет, что один из ключевых аргументов, высказанных «троллями», сводится всего лишь к следующему:
«Наверное, не стоит заменять что-то настолько критичное, как GNU Coreutils, пока замена не будет готова.»
Однако стремление защитить Культ Rust настолько сильно, что технические журналисты готовы завязываться в ментальные узлы, лишь бы атаковать «троллей». В результате они умудряются соглашаться с «троллями» в первой части заголовка («Rust Coreutils продолжает движение к 100% совместимости с GNU»), и одновременно провозглашать победу над злыми «троллями» во второй части заголовка («Доказывая, что тролли были неправы»).
fosdem.org/2026/schedule/event/DTYYL9-rust-coreutils/
https://phoronix.com/news/Rust-Coreutils-FOSDEM-2026
@linuxos_tg
Разработчик DuckStation (опенсорс эмулятора PlayStation 1) добавил код, который намеренно блокирует сборку эмулятора на NixOS и Arch Linux.
Коннор Маклафлин, разработчик DuckStation, говорит:
Он называет NixOS и Arch "враждебными пакетными окружениями", добавляя:
https://github.com/stenzek/duckstation/commit/64d13882479e5598a1276e273d231c95a094158c
@linuxos_tg
Коннор Маклафлин, разработчик DuckStation, говорит:
«Мне уже надоело разбираться с людьми, которые жалуются на поломки, внесённые пакетными мейнтейнерами, а потом ещё и получать атаки от этих самых мейнтейнеров пакетов, которые нарушают кодексы поведения своих дистрибутивов».
Он называет NixOS и Arch "враждебными пакетными окружениями", добавляя:
«Вот поэтому у нас и не бывает нормальных вещей».
https://github.com/stenzek/duckstation/commit/64d13882479e5598a1276e273d231c95a094158c
@linuxos_tg
Forwarded from IT Portal
Справочное руководство по BASH является частью "файлов Эпштейна"
Серьёзно. Язык скриптов BASH. В файлах Эпштейна.
Теперь всё становится понятно😒
https://justice.gov/epstein/files/DataSet%209/EFTA00315849.pdf
@IT_Portal
Серьёзно. Язык скриптов BASH. В файлах Эпштейна.
Теперь всё становится понятно
https://justice.gov/epstein/files/DataSet%209/EFTA00315849.pdf
@IT_Portal
Please open Telegram to view this post
VIEW IN TELEGRAM
😁230
С днём рождения, Кен Томпсон. Соавтор UNIX, создатель языка B и один из архитекторов Go. Настоящая легенда IT 👒
@linuxos_tg
@linuxos_tg
Please open Telegram to view this post
VIEW IN TELEGRAM
❤326🎉230🔥48👍22
«Rust в ядре NetBSD, скорее всего, вообще не вариант», – говорит давний разработчик NetBSD.
Приводится множество причин, по которым язык программирования Rust не подходит для использования в NetBSD, в том числе:
- «NetBSD поддерживает множество архитектур, для которых Rust просто недоступен».
- «Даже просто запустить компилятор Rust изначально — сложно», и «Поддерживать работоспособность Rust — это довольно много работы».
- «Процесс bootstrap опирается на бинарный пакет предыдущей версии. Это неприемлемо».
- «NetBSD 9.0 был выпущен в 2020 году. На тот момент актуальной версией был Rust 1.41. Если бы Rust 1.41 был включён в NetBSD 9, он был бы бесполезен для чего-либо, кроме сборки самого NetBSD — Rust 1.41 настолько старый, что практически никакой современный код с ним не скомпилируется. Такое себе».
https://bentsukun.ch/posts/netbsd-rust-kernel/
@linuxos_tg
Приводится множество причин, по которым язык программирования Rust не подходит для использования в NetBSD, в том числе:
- «NetBSD поддерживает множество архитектур, для которых Rust просто недоступен».
- «Даже просто запустить компилятор Rust изначально — сложно», и «Поддерживать работоспособность Rust — это довольно много работы».
- «Процесс bootstrap опирается на бинарный пакет предыдущей версии. Это неприемлемо».
- «NetBSD 9.0 был выпущен в 2020 году. На тот момент актуальной версией был Rust 1.41. Если бы Rust 1.41 был включён в NetBSD 9, он был бы бесполезен для чего-либо, кроме сборки самого NetBSD — Rust 1.41 настолько старый, что практически никакой современный код с ним не скомпилируется. Такое себе».
https://bentsukun.ch/posts/netbsd-rust-kernel/
@linuxos_tg
👍124👌24
Совет дня по Linux
У тебя есть привычка случайно перезаписывать файлы в bash с помощью
Чтобы этого избежать, можно включить режим noclobber.
Сначала проверь статус noclobber:
Если он выключен, включи его для текущей сессии:
Или включи его навсегда, добавив эту строку в свой
Когда noclobber включён, попытка перенаправить вывод в уже существующий файл завершится ошибкой:
Если
cannot overwrite existing file.
Это защищает от случайного уничтожения содержимого файлов. Оператор добавления (
Если тебе действительно нужно перезаписать файл при включённом noclobber, используй принудительный оператор
Он обходит защиту noclobber.
@linuxos_tg
У тебя есть привычка случайно перезаписывать файлы в bash с помощью
>?Чтобы этого избежать, можно включить режим noclobber.
Сначала проверь статус noclobber:
$ set -o | grep noclobber
Если он выключен, включи его для текущей сессии:
$ set -o noclobber
Или включи его навсегда, добавив эту строку в свой
~/.bashrc.Когда noclobber включён, попытка перенаправить вывод в уже существующий файл завершится ошибкой:
echo "Hello, World!" > hello.txt
Если
hello.txt уже существует, bash вернёт ошибкуcannot overwrite existing file.
Это защищает от случайного уничтожения содержимого файлов. Оператор добавления (
>>) при этом продолжает работать без изменений.Если тебе действительно нужно перезаписать файл при включённом noclobber, используй принудительный оператор
>|:echo "Hello, World!" >| hello.txt
Он обходит защиту noclobber.
@linuxos_tg
👍118✍38❤17
В 2004 году Sun Fire E25K был вершиной пищевой цепочки в мире вычислений. Это была самая большая single-image Unix-машина, которую вообще можно было купить за деньги (около $2 млн в максимальной конфигурации)
Этот зверь имел:
• 36 процессоров UltraSPARC IV (72 ядра)
• 576 ГБ ОЗУ
• 18 полностью hot-swap плат CPU/памяти
• гигабитный Ethernet и Fibre Channel HBA
• резервированные блоки питания и зоны охлаждения, энергопотребление – около 15 кВт
Я выкатывал на эти машины софт. Аптайм измерялся годами. Это была ТА САМАЯ
@linuxos_tg
Этот зверь имел:
• 36 процессоров UltraSPARC IV (72 ядра)
• 576 ГБ ОЗУ
• 18 полностью hot-swap плат CPU/памяти
• гигабитный Ethernet и Fibre Channel HBA
• резервированные блоки питания и зоны охлаждения, энергопотребление – около 15 кВт
Я выкатывал на эти машины софт. Аптайм измерялся годами. Это была ТА САМАЯ
@linuxos_tg
Media is too big
VIEW IN TELEGRAM
😁236
Создан "де-Rust’ированный" форк Git ведущим разработчиком XLibre (популярного форка Xorg)
Форк описывается как "Git с применённым WD-40" – из него удалён код на Rust. Судя по всему, это делается в преддверии релиза Git 3.0, который ожидается позже в этом году и где Rust станет жёсткой зависимостью для сборки Git.
На просьбу прокомментировать ситуацию разработчик (Энрико Вайгельт) ответил:
Эта позиция перекликается с недавними опасениями по поводу внедрения Rust, которые высказывал давний разработчик проекта NetBSD.
https://github.com/Libre-WD-40/git
@linuxos_tg
Форк описывается как "Git с применённым WD-40" – из него удалён код на Rust. Судя по всему, это делается в преддверии релиза Git 3.0, который ожидается позже в этом году и где Rust станет жёсткой зависимостью для сборки Git.
На просьбу прокомментировать ситуацию разработчик (Энрико Вайгельт) ответил:
«Нужно гарантировать, что Git продолжит работать на любых платформах и CPU-архитектурах, оставаясь надёжным и стабильным, вместо того чтобы ограничиваться лишь несколькими архитектурами и зависеть от недоверенного компилятора, который даже невозможно полностью бутстрапнуть без использования какого-то недоверенного бинарника.»
Эта позиция перекликается с недавними опасениями по поводу внедрения Rust, которые высказывал давний разработчик проекта NetBSD.
https://github.com/Libre-WD-40/git
@linuxos_tg
😁95🔥57
В воскресенье Линус Торвальдс объявил, что следующий релиз ядра Linux будет иметь номер версии "7.0"
Ещё один коммит, также сделанный в воскресенье и относящийся к релизу Linux 7.0, содержал следующую пометку:
Иными словами: 7.0 станет первым релизом ядра Linux, в котором поддержка Rust больше не будет считаться "экспериментальной".
Любопытно, что мейнтейнеры Rust-направления в ядре Linux также отметили, что завершение "эксперимента с Rust" вовсе не означает, что "всё работает".
Коротко: в Linux 7.0 поддержка Rust теперь официальная и больше не имеет статуса experimental… но "не всё работает" и многое всё ещё "довольно экспериментально".
Официальный релиз Linux Kernel 7.0 ожидается уже 12 апреля. Это означает, что есть вероятность включения 7.0 в следующий релиз Ubuntu (26.04), запланированный на 23 апреля
@linuxos_tg
Ещё один коммит, также сделанный в воскресенье и относящийся к релизу Linux 7.0, содержал следующую пометку:
"– Завершить эксперимент с Rust."
Иными словами: 7.0 станет первым релизом ядра Linux, в котором поддержка Rust больше не будет считаться "экспериментальной".
Любопытно, что мейнтейнеры Rust-направления в ядре Linux также отметили, что завершение "эксперимента с Rust" вовсе не означает, что "всё работает".
«Во всех направлениях ещё предстоит огромный объём работы», — заявили разработчики Rust для Linux. «… более того, некоторые комбинации конфигураций по-прежнему остаются весьма экспериментальными».
Коротко: в Linux 7.0 поддержка Rust теперь официальная и больше не имеет статуса experimental… но "не всё работает" и многое всё ещё "довольно экспериментально".
Официальный релиз Linux Kernel 7.0 ожидается уже 12 апреля. Это означает, что есть вероятность включения 7.0 в следующий релиз Ubuntu (26.04), запланированный на 23 апреля
@linuxos_tg
Забавный факт о номерах версий Linux:
Смена мажорной версии (например, с "7.0") в Linux не означает появления каких-то серьёзных новых фич.
На практике повышение мажорного номера часто происходит просто потому, что Линус Торвальдс не любит, когда номера версий "разрастаются настолько, что их уже сложно нормально различать".
В 2015 году, готовясь к релизу ядра Linux 3.20, Торвальдс запостил опрос в Google+ (соцсеть, которая уже закрыта), где спросил сообщество, что делать с нумерацией версий.
В опросе было два варианта:
По итогам опроса Торвальдс решил перескочить с версии 3.19 сразу на 4.0, объяснив это так: "Я снова почти исчерпал запас пальцев на руках и ногах".
Теперь, в 2026 году, он продолжает эту традицию, перепрыгивая с 6.19 на 7.0.
@linuxos_tg
Смена мажорной версии (например, с "7.0") в Linux не означает появления каких-то серьёзных новых фич.
На практике повышение мажорного номера часто происходит просто потому, что Линус Торвальдс не любит, когда номера версий "разрастаются настолько, что их уже сложно нормально различать".
В 2015 году, готовясь к релизу ядра Linux 3.20, Торвальдс запостил опрос в Google+ (соцсеть, которая уже закрыта), где спросил сообщество, что делать с нумерацией версий.
В опросе было два варианта:
a) «Мне нравятся большие версии, и я не буду врать»
b) «v4.0, потому что я легко путаюсь»
По итогам опроса Торвальдс решил перескочить с версии 3.19 сразу на 4.0, объяснив это так: "Я снова почти исчерпал запас пальцев на руках и ногах".
Теперь, в 2026 году, он продолжает эту традицию, перепрыгивая с 6.19 на 7.0.
@linuxos_tg
❤127😁78👍31🤯25
Forwarded from IT Portal
Windows Notepad.exe теперь имеет уязвимость удалённого выполнения кода (RCE)
Да, вы всё правильно прочитали.
Notepad.exe, который раньше был обычным текстовым редактором, оброс таким количеством сетевых/онлайн-фич (включая ИИ и подписки через Microsoft Account)… что в итоге у него появились уязвимости безопасности
Данный CVE классифицирован как SEVERE и получил оценку 8.8.
https://cve.org/CVERecord?id=CVE-2026-20841
@IT_Portal
Да, вы всё правильно прочитали.
Notepad.exe, который раньше был обычным текстовым редактором, оброс таким количеством сетевых/онлайн-фич (включая ИИ и подписки через Microsoft Account)… что в итоге у него появились уязвимости безопасности
Данный CVE классифицирован как SEVERE и получил оценку 8.8.
https://cve.org/CVERecord?id=CVE-2026-20841
@IT_Portal
IT Portal
Windows Notepad.exe теперь имеет уязвимость удалённого выполнения кода (RCE) Да, вы всё правильно прочитали. Notepad.exe, который раньше был обычным текстовым редактором, оброс таким количеством сетевых/онлайн-фич (включая ИИ и подписки через Microsoft Account)……
Да, по сути вся эта история с RCE в Блокноте(он же Notepad.exe) Windows 11 оказалась до абсурда тупой. Настолько нелепой, что даже больно.
В Блокноте Windows 11, с этим "навороченным" Copilot AI, теперь появилась возможность обрабатывать разметку, то есть markup/Markdown… В общем, "mark-что-то", то, что используют в README. Ну вы поняли.
И вот один исследователь безопасности обнаружил, что если использовать Markdown в Notepad и вместо обычной гиперссылки с
Дальше он понял, что можно указать удалённый хост, откуда это будет выполняться, используя другой, специфичный для Microsoft протокол, который применяют для установки приложений. То есть если юзер кликнет по гиперссылке в Блокноте, она скачает и запустит программу с любого сайта… и никак не предупредит пользователя.
В нормальной реализации любой переход по ссылке на другой домен или попытка запуска файла должна сопровождаться алертом, диалоговым окном подтверждения или хотя бы каким-то предупреждением. Но инженеры Microsoft, по всей видимости, просто забыли реализовать это окно подтверждения.
С учётом того, что этот вектор атаки существовал как минимум 9 месяцев, злоумышленнику было достаточно отправить пользователю
Ещё абсурднее выглядит ситуация с точки зрения форензики: на уровне логов Windows или для анти-малварного решения всё выглядело так, будто Notepad скачивает что-то, а затем запускает программу. Это довольно уникальный кейс, с которым (насколько мне известно) большинство security-продуктов ранее не сталкивались. Теоретически это могло привести к тому, что файлы скачивались и исполнялись бы полностью мимо анти-малварной защиты, потому что инициатором выступал доверенный системный процесс — Блокнот. С чего антималвару вообще подозревать Блокнот?
В общем, я к тому, что не совсем понимаю, зачем Microsoft напихала в Блокнот столько новых фич. Новые фичи – это новая поверхность атаки (больше того, что можно абьюзить)
Как-то так... Думайте, Linux зовёт 🌝
@linuxos_tg
В Блокноте Windows 11, с этим "навороченным" Copilot AI, теперь появилась возможность обрабатывать разметку, то есть markup/Markdown… В общем, "mark-что-то", то, что используют в README. Ну вы поняли.
И вот один исследователь безопасности обнаружил, что если использовать Markdown в Notepad и вместо обычной гиперссылки с
https:// указать file:// (Windows-протокол для доступа к файлам, как в проводнике), то приложение выполнит этот ресурс произвольно. Без какого-либо промпта или предупреждения.Дальше он понял, что можно указать удалённый хост, откуда это будет выполняться, используя другой, специфичный для Microsoft протокол, который применяют для установки приложений. То есть если юзер кликнет по гиперссылке в Блокноте, она скачает и запустит программу с любого сайта… и никак не предупредит пользователя.
В нормальной реализации любой переход по ссылке на другой домен или попытка запуска файла должна сопровождаться алертом, диалоговым окном подтверждения или хотя бы каким-то предупреждением. Но инженеры Microsoft, по всей видимости, просто забыли реализовать это окно подтверждения.
С учётом того, что этот вектор атаки существовал как минимум 9 месяцев, злоумышленнику было достаточно отправить пользователю
.txt-файл. Если пользователь кликал по ссылке внутри файла, происходило автоматическое выполнение всего, что было прописано в гиперссылке.Ещё абсурднее выглядит ситуация с точки зрения форензики: на уровне логов Windows или для анти-малварного решения всё выглядело так, будто Notepad скачивает что-то, а затем запускает программу. Это довольно уникальный кейс, с которым (насколько мне известно) большинство security-продуктов ранее не сталкивались. Теоретически это могло привести к тому, что файлы скачивались и исполнялись бы полностью мимо анти-малварной защиты, потому что инициатором выступал доверенный системный процесс — Блокнот. С чего антималвару вообще подозревать Блокнот?
В общем, я к тому, что не совсем понимаю, зачем Microsoft напихала в Блокнот столько новых фич. Новые фичи – это новая поверхность атаки (больше того, что можно абьюзить)
Как-то так... Думайте, Linux зовёт 🌝
@linuxos_tg
❤142
Xorg теперь официально отказался от ветки "master" в своей реализации X11…
И перенёс всю разработку в новую ветку "main", созданную на основе двухлетней версии Xorg (февраль 2024 года), при этом в процессе были утрачены многочисленные улучшения (внесённые разработчиком XLibre).
Похоже, это было сделано для того, чтобы Xorg мог продемонстрировать "правильную позицию", удалив код, который сейчас успешно используется в XLibre (форке Xorg, набирающем популярность), поскольку контролирующие Xorg считают, что у этого проекта "неправильные политические взгляды"
https://cgit.freedesktop.org/xorg/xserver/commit/?id=0da4d2480066fb2c783325e7594902aacc23413e
@linuxos_tg
И перенёс всю разработку в новую ветку "main", созданную на основе двухлетней версии Xorg (февраль 2024 года), при этом в процессе были утрачены многочисленные улучшения (внесённые разработчиком XLibre).
Похоже, это было сделано для того, чтобы Xorg мог продемонстрировать "правильную позицию", удалив код, который сейчас успешно используется в XLibre (форке Xorg, набирающем популярность), поскольку контролирующие Xorg считают, что у этого проекта "неправильные политические взгляды"
https://cgit.freedesktop.org/xorg/xserver/commit/?id=0da4d2480066fb2c783325e7594902aacc23413e
@linuxos_tg