В ветку Android Canary добавлена возможность запуска графический приложений linux. Запуск осуществляется через приложение Linux Terminal, позволяющее запустить в окружении Android виртуальную машину с Debian GNU/Linux, в которой можно выполнять обычные Linux-приложения.

Функциональность виртуальной машины c Linux развивается в рамках проекта Ferrochrome. В гостевом окружении запускается Debian GNU/Linux 12. Для виртуализации используется Android Virtualization Framework, реализованный на базе гипервизора KVM и инструментария crosvm. Графическое окружение использует протокол Wayland и основано на композитном сервере Weston. Запуск приложений, собранных для X11, производится при помощи DDX-компонента XWayland, например, продемонстрирован запуск текстового редактора Gedit.

Есть принципиальная возможность использовать аппаратное ускорение графики на основе виртуального GPU Virgil3D для QEMU/KVM. В качестве иллюстрации продемонстрирован запуск doom. По умолчанию аппаратное ускорение отключено.

>>> Подробности

Исследовательская группа METR (Model Evaluation & Threat Research) опубликовала результаты эксперимента по оценке эффективности применения AI-инструментов для написания кода. Вопреки ожиданиям, исследование показало, что AI-помощники не ускоряют, а замедляют решение поставленных задач, при том, что субъективно участники эксперимента считали, что AI ускорил их работу.

Фактически при использовании AI-помощника на решение задачи в среднем было потрачено на 19% больше времени, в то время как участники полагали, что благодаря AI смогли выполнить работу на 20% быстрее, а до начала работы считали, что AI поможет им ускорить работу на 24%. Результаты также значительно расходятся с прогнозами экспертов в области экономики и машинного обучения, которые предсказывали экономию времени при использовании AI на 39% и 38%, соответственно.

В ходе эксперимента 16 разработчикам открытых проектов, имеющим средний опыт работы с AI-инструментами, было предложено решить 246 задач, связанных с исправлением ошибок и добавлением новых возможностей. Задачи были сформированы на основе реальных issue в GitHub-репозиториях проектов, с которыми у выбранных разработчиков был опыт работы не менее 5 лет. Случайным образом часть задач предлагалось решить вручную, а часть с использованием любого AI-помощника на выбор разработчика (большинство предпочли редактор кода Cursor с моделью Claude 3.5/3.7 Sonnet).

В эксперимент, который проводился с февраля по июнь 2025 года, были вовлечены такие открытые проекты, как mito, stdlib, ghc, cabal, flair, jsdom, hypothesis, trieve, scikit-learn, gpt-neox и transformers. В среднем задействованные проекты имели 23 тысячи звёзд на GitHub, 1.1 млн строк кода, 20 тысяч коммитов и 710 участников.

Упоминаются следующие возможные причины замедления решения задач при использовании AI:

• Низкое качество AI-рекомендаций - разработчики приняли менее 44% от сгенерированных AI предложений и потратили много времени на их чистку и проверку.

• Излишний оптимизм в плане полезности AI и завышенные ожидания от возможностей AI-инструментов.

• Большой опыт работы участников с репозиториями, для которых решались задачи. Разработчики очень хорошо ориентировались в проектах и помощь AI в этой ситуации не представляла ценности.

• В эксперименте использовались слишком крупные и сложные репозитории, с которыми AI работает хуже.

• Неявный контекст репозитория - AI не понимал контекст, в котором работал.

Итоговый вывод: при использовании AI-инструментов разработчики тратят меньше времени на написание кода, поиск информации и чтение документации, но данная экономия сводится на нет из-за повышенных затрат времени на формирование запросов к AI, разбор подсказок, ожидание результата, рецензирование предложений и бездействие. Вместо генерации кода время уходит на взаимодействие с AI, изучение результатов и проверку предложенного кода.

>>> Подробности на opennet

Там огромная стена текста и таблиц, я небольшими выдержками:

Изначально было отмечено, что при тестировании на ноутбуке Lenovo IdeaPad 3 с интегрированным GPU AMD в сеансе Wayland процессор постоянно нагружен примерно на 8% независимо от активности, а каждые 2-3 секунды наблюдается скачок, полностью нагружающий GPU. В сеансе X11 нагрузка на CPU и GPU во время простоя была на нуле.

Тестирование потребления энергии утилитой powertop также показало преимущество сеанса X11: энергопотребление сеанса Wayland составило 6.09 ватт, Wayland с профилем «Color Accuracy» 6.05-6.08 ватт, а X11 - 5.67-5.87 ватт. В целом сделан вывод, что сеанс X11 расходует на 3-7% меньше заряда аккумулятора, чем Wayland.

Проверка нагрузки на CPU утилитой vmstat показала, что во время простоя сеанс X11 потреблял 1.83% CPU, а Wayland - 1.97% (2.1% с профилем Color Accuracy).

сеанс Wayland оказался менее эффективен, чем X11: потребление энергии 22.42 ватт в Wayland и 21.86 ватт в X11, нагрузка на CPU в режиме простоя 0.067% против 0.050%, число переключений контекста - 43.835/s против 34.133/s, нагрузка при просмотре 4K видео в VLC - 12.54% против 4.26%, производительность WebGL - 16 FPS против 29 FPS.

И там далее все в таком духе, ниже делается скромный вывод о том, что Х11 немножко лучше:

По итогам тестирования сделан вывод, что X11 ещё рано сбрасывать со счетов, а решения на базе Wayland требуют дополнительной оптимизации. X11 отмечается как по-прежнему самое оптимальное решение с точки зрения производительности. Реализация Wayland в KDE предположительно лучше, чем в GNOME - сеанс GNOME Wayland, реализованный в Fedora, судя по тестам менее производителен, чем сеанс KDE Wayland, который в свою очередь отстаёт от KDE X11.

Ник Велнхофер (Nick Wellnhofer), сопровождающий библиотеку libxml2, объявил, что отныне будет трактовать уязвимости как обычные ошибки. Сообщения об уязвимостях не будут рассматриваться в приоритетном порядке, а станут исправляться по мере появления свободного времени.

Отмечается, что скрытие сведений об уязвимостях до публикации обновлений и метрики типа OpenSSF Scorecard лишь попытка крупных компаний вызвать у сопровождающих чувство вины и заставить работать бесплатно. Предъявление дополнительных требований к сопровождающим-волонтёрам, работающим без компенсации, названо пагубной практикой.

По словам Ника, библиотека libxml2 не обладает уровнем качества, пригодным для использования в браузерах и операционных системах. Тем не менее, крупные компании, такие как Apple, Google и Microsoft, стали использовать libxml2 в своих операционных системах и продуктах. Подобные действия названы безответственными, а проводимая работа - попытками избавиться от симптомов, а не устранить причину проблем. По мнению Ника для проекта было бы лучше, если упомянутые компании прекратили использование libxml2.

!Ъ

Разработчики свободной системы автоматизированного проектирования печатных плат KiCad рассказали о состоянии реализации поддержки Wayland и обобщили проблемы, мешающие полноценному использованию данного протокола. Пользователям, профессионально проектирующим печатные платы в KiCad или желающим получить стабильное и полнофункциональное окружение, рекомендовано запускать KiCad в средах рабочего стола на базе протокола X11, таких как Xfce, MATE или X11-сеанс KDE Plasma.

Тем кто намерен использовать KiCad в окружениях с Wayland следует быть готовым к возможным зависаниям и аварийным завершениям, невозможности восстановить желаемую раскладку окон и ограничению функциональности интерфейса. Утверждается, что ограничения в функциональности вызваны отсутствием в Wayland возможностей, давно применяемых в приложениях для X11, Windows и macOS, таких как поддержка позиционирования окон и мгновенного перемещения указателя мыши (cursor warp).

Что касается возникающих сбоев, то они связываются с большой фрагментацией композитных серверов для Wayland. GNOME, KDE и обособленные композитные менеджеры по-своему интерпретируют протоколы Wayland, поэтому полагаться при разработке на единую целостную реализацию протоколов Wayland и экспериментальные расширения проблематично. Разработчикам приложений приходится учитывать особенности каждого окружения и применять костыли для обхода проблем, специфичных для разных композитных менеджеров.

Фрагментация композитных серверов существенно увеличивает трудозатраты на реализацию поддержки Wayland. Отмечается, что самое неприятное в том, что разработчики KiCad не имеют возможности исправить возникающие проблемы своими силами, так как проблемы присутствуют не в KiСad, а в протоколах, оконных менеджерах и композитных серверах.

Учитывая, что Linux применяет лишь небольшая часть пользователей KiCad, решено избегать добавления в кодовую базу проекта костылей для обхода проблем, специфичных для оконных менеджеров, но при этом продолжать собирать KiCad для Wayland и тестировать сборки на совместимость. Все выявляемые проблемы и ограничения планируют документировать и доводить до сведения пользователей.

В системе отслеживания ошибок решено не разбирать жалобы от пользователей Wayland, связанные с позиционированием и размером окон, установкой фокуса, а также зависаниями, аварийными завершениями, повышенной нагрузке на CPU, проблемами с устройствами ввода и сбоями при отрисовке, не проявляющимися в сборке для X11.

Среди известных проблем, которые находятся вне зоны влияния разработчиков KiCad и которые не удаётся устранить на стороне KiCad:

• Проблемы с управлением окнами: Невозможность управления позицией окон и панелей (при открытии KiCad нельзя запомнить и восстановить положение окон и панелей инструментов). Проблемы с координацией работы одновременно с несколькими окнами. Ограничение возможности перемещения вкладок и панелей между разными областями.
• Проблемы с устройствами ввода: Возможность мгновенного перемещения курсора (cursor warping) завязана на необязательные экспериментальные расширения протокола, поддерживаемые лишь в отдельных композитных менеджерах. Непредсказуемое поведение при управлении фокусом ввода. Проблемы при использовании специализированных устройств ввода и при обработке горячих клавиш.
• Проблемы со стабильностью и производительностью: Повышенное потребление ресурсов и высокая нагрузка на CPU/GPU по сравнению с использованием X11. Появление графических артефактов при отрисовке и нарушение нормального вывода. Зависания и аварийные завершения, проявляющиеся только при работе в окружениях на базе Wayland. Ненадёжная работа с буфером обмена.
• Ограничения интерфейса пользователя: Проблемы с позиционированием, фокусом и взаимодействием в модальных диалогах. Проблемы с запуском внешних приложений и управления ими.

>>> Подробности (opennet)

Разработчики операционной системы Redox, написанной с использованием языка Rust и концепции микроядра, объявили о реализации поддержки протокола X11 в развиваемом проектом дисплейном сервере Orbital, использующем библиотеку iced. Добавленная возможность позволяет запускать в Redox приложения, использующие X11, без внесения изменений в код. Реализация поддержки X11 в Orbital концептуально напоминает применение XWayland в окружениях на базе Wayland. Реализация также использует бэкенд DRI для повышения производительности отрисовки, в котором пока не полностью реализована поддержка аппаратного ускорения графики.

Проектом развивается собственный пакетный менеджер, набор стандартных утилит (binutils, coreutils, netutils, extrautils), командная оболочка ion, стандартная Си-библиотека relibc, vim-подобный текстовый редактор sodium, сетевой стек и файловая система. Конфигурация задаётся на языке Toml. Для совместимости с существующими приложениями предоставляется POSIX-прослойка, позволяющая запускать многие программы без портирования.

Протестировать Redox можно воспользовавшись ежедневно обновляемыми сборками для виртуальных машин и реального оборудования (aarch64, i686, riscv64gc, x86_64). Среди поддерживаемого оборудования отмечены устройства ввода с интерфейсом USB (клавиатуры, мыши, тачпады), вывод графики через API VESA BIOS или UEFI GOP (драйверы для GPU не поддерживаются), звуковые чипы AC’97 и Intel HD Audio, SATA (AHCI, IDE) и NVMe. Поддержка Wi-Fi и устройств хранения с интерфейсом USB пока не доведена до готовности.

Подробности там.

Компании Meta* и Yandex уличили в скрытом отслеживании пользователей и манипуляциях для обхода предоставляемых браузерами средств обеспечения конфиденциальности, таких как режим инкогнито и возможность очистки Cookie. Активность по деанонимизации сеансов применялась на платформе Android при открытии сайтов, использующих системы web-аналитики Яндекс Метрика или Facebook Pixel.

Суть использованного метода идентификации сводится к тому, что распространяемые Meta и Yandex мобильные приложения для Android, такие как Facebook, Instagram, Yandex Maps, Yandex Navigator, Yandex Search, Yandex Go: Taxi Food и Yandex Browser, создавали дополнительный канал связи с выполняемым в браузере JavaScript-кодом. Мобильные приложения запускали отдельные обработчики соединений на локальном сетевом интерфейсе (127.0.0.1), принимающие запросы по протоколам HTTP, HTTPS, WebSocket и WebRTC.

При открытии в браузере сайтов, использующие системы web-аналитики Yandex Metric или Facebook Pixel, связанный с данными системами JavaScript-код отправлял запросы на открытые мобильными приложениями сетевые порты. В запросах передавались метаданные, Cookie и управляющие команды. В мобильных приложениях браузерные сеансы связывались с реальными идентификаторами пользователя и устройства, к которым имели доступ приложения. Например, сеансы могли связываться с учётными записями в Facebook и Yandex или с идентификаторами AAID (Android Advertising ID). Таким образом, даже при открытии сайта в режиме инкогнито или после удаления Cookie, сервисы Meta и Yandex могли точно идентифицировать пользователя, открывшего сайт, привязываясь к идентификаторам из мобильных приложений, запущенных на том же устройстве.

Реализованная техника представляла опасность не только из-за утечки информации в Facebook и Yandex, но и из-за возможности использования вредоносными приложениями. Сетевые порты, на которые отправлялись сведения об активности в браузере, могли использовать любые приложения для отслеживания активности пользователя и построения истории посещений, а не только приложения Facebook и Yandex.

Компании Facebook и Yandex воспользовались тем, что платформа Android не ограничивает создание слушающих сокетов в привязке к интерфейсу loopback (127.0.0.1), если приложение имеет полномочия INTERNET. В случае Facebook локальному приложению передавалось содержимое Cookie «_fbp» (уникальный идентификатор пользователя в Facebook Pixel). Через манипуляции с WebRTC содержимое подставлялось в поле «ice-ufrag» пакетов SDP, отправляемых в STUN-запросах на локальный хост. 17 мая в Chrome была заблокирована подобная возможность и скрипты Facebook Pixel перевели на использование WebRTC TURN. После раскрытия результатов исследования компания Meta удалила из скриптов Facebook Pixel отправку запросов на localhost.

В Яндекс метод отправки данных из браузера в мобильные приложения применялся с 2017 года. JavaScript-код сервиса Yandex Metrica устанавливал HTTP- или HTTPS-соединение с localhost по сетевым портам 29009, 29010, 30102 и 30103. Обращения отправлялись на сайт yandexmetrica.com, доменное имя которого резолвилось в IP-адрес 127.0.0.1. Информация о сетевых портах, на которых мобильные приложения Yandex должны были открыть слушающие сокеты, подгружалась динамически через запрос к хосту startup.mobile.yandex.net.

Сервер также передавал параметр first_delay_seconds, содержащий задержку перед запуском сетевых сервисов (приложения начинали принимать соединения не сразу после установки, а примерно через три дня). В ответ на HTTP-запрос мобильное приложение возвращало набор данных, включающий идентификаторы в сервисах Yandex, системные UUID и AAID (Android Advertising ID). JavaScript код Yandex Metric переправлял полученные идентификаторы на сервер mc.yango.com.

Упомянутые методы передачи данных работали в версиях Chrome и Edge для Android. В Firefox работал только метод Yandex. В DuckDuckGo и Brave отправка запросов к localhost блокировалась или требовала ручного подтверждения операции. В представленном в конце мая выпуске Chrome 137 была добавлена защита от подстановки данных в SDP.

*компания МЕТА и Facebook запрещены на территории РФ (тьфу тьфу тьфу на них окаянных).

>>> Подробности (opennet)

Microsoft опубликовал исходные тексты подсистемы wsl. Для желающих присоединиться к разработке запущен сайт wsl.dev.

WSL предоставляет виртуальную машину с полноценным ядром Linux (на базе ветки 6.6), в которой могут запускаться дистрибутивы Linux. Ядро включает специфичные для WSL изменения, такие как оптимизации для сокращения времени запуска и уменьшения потребления памяти, возможность возвращения Windows освобождённой Linux-процессами памяти и настройки для исключения лишних драйверов и подсистем. Система устанавливается в отдельный дисковый образ (VHD) c файловой системой ext4 и виртуальным сетевым адаптером.

Компоненты WSL, связанные с ядром Linux и графическим стеком wslg, применяемым для для запуска GUI-приложений на базе Wayland и X11, развивались в открытом виде изначально, но весь сопутствующий инструментарий оставался проприетарным. Отныне в число открытых переведены следующие компоненты:

• утилиты командной строки wsl.exe, wslconfig.exe и wslg.exe, используемые для взаимодействия с WSL;
• сервис wslservice.exe, применяемый для запуска виртуальной машины, активации в ней Linux-окружения и монтирования файловых систем;
• фоновые процессы, запускаемые в Linux-окружении для доступа к функциональности WSL. Например, процесс init для начальной инициализации, gns для настройки сетевого доступа, localhost для перенаправления портов;
• процесс plan9 с реализацией сервера Plan9, применяемого в WSL для совместного доступа к Linux-файлам из Windows.

Остаются частью Windows и не открыты в настоящее время:

• драйвер ядра Lxcore.sys, применяемый для запуска исполняемых файлов в формате ELF через слой обеспечения совместимости;
• драйвер P9rdr.sys и библиотека p9np.dll, обеспечивающие перенаправление доступа к ФС «\wsl.localhost» при обращении из Windows к Linux.

Одновременно компания Microsoft открыла под лицензией MIT исходный код консольного текстового редактора Edit, написанного на модном языке Rust и нацеленного на поставку по умолчанию в 64-разрядных версиях Windows. В ближайшие месяцы редактор будет предложен для ознакомления и тестирования в сборках Windows Insider Program, после чего войдёт в штатную поставку Windows 11.

В редакторе попытались реализовать современный интерфейс с управлением в стиле VS Code. Целью заявлено предоставление интерфейса, который был бы понятен и прост в использовании даже для тех, кто не имеет опыта работы в терминале. Редактор компактен и занимает всего 250kB на диске. Из возможностей упомянуты: система меню, управление клавиатурными комбинациями или мышью, поддержка вкладок и одновременной работы с несколькими файлами, операции поиска и замены, режим автоматического переноса текста на новую строку.

>>> Подробности (OpenNet)

После обновления до версии 1.24.5 пользователи редакторов VS Codium и Cursor, основанных на коде VS Code, столкнулись с невозможностью дальнейшего использования дополнения от Microsoft. Касается это С/С++ и С#.

Разработчики проекта Cursor выпустили обновление, временно решающее проблему, а в дальнейшем решили отказаться от использования проприетарных дополнений Remote access, Pylance, C/C++ и C#. В состав следующей версии планируют включить развиваемые сообществом открытые альтернативные дополнения. Аналогичный переход на открытые аналоги планируют и разработчики проекта VS Codium.

Если кого-то интересуют подробности на опенете.

Что это такое - начинающему атланту не дают расправить плечи, или это очередной этап подковёрной конкурентной борьбы между куркулями - мироедами микрософт и другими «участниками рынка» - пока не понятно.

Замена коснётся более ста утилит, входящих в состав Сoreutils, включая sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln и ls. В настоящее время утилиты uutils уже применяются по умолчанию в дистрибутиве Apertis, основанном на Debian, а также в независимом дистрибутиве AerynOS (SerpentOS). Опубликованный на прошлой неделе выпуск пакета uutils coreutils 0.0.30 успешно проходит 507 тестов (в прошлом выпуске 506, в позапрошлом - 476) из эталонного тестового набора GNU Coreutils. 69 тестов завершилось неудачей, а 41 тест был пропущен. В ближайшие недели также планируется приступить к работе над заменой в Ubuntu утилит su и sudo на пакет sudo-rs. Из рассматриваемых проектов дополнительно упоминаются zlib-rs и ntpd-rs.

Если эксперимент будет признан удачным, то uutils также будут задействованы по умолчанию в LTS-ветке Ubuntu 26.04.

В декабре 2024 года месячная аудитория магазина приложений RuStore составила 50 млн пользователей старше 12 лет по всей России, согласно исследованию Mediascope. Аудитория Xiaomi Mi Store составила 19 млн, Samsung Galaxy Store — 14 млн, HUAWEI AppGallery — 10 млн, рассказали Хабру в пресс‑службе RuStore.

>>>Источник

Количество смартфонов в России По данным Минцифры число устройств мобильной связи в конце 2022 года составляло 315.1 млн. Этот показатель вырос на 77.4 млн с 2010 года

>>>Источник

На лицо опережение таких гигантов как самсунг и ксяоми. А пользуешься ли ты, анончик, рустором?

Проект Бутылка разработан для облегчения установки вин-программ на линуксе. Но поскольку написан, как монолит python+gkt, то не позволяет реализовать использование Бутылки на более распространённом unix-дистрибутиве MacOS X.

Аффтыри хотели переписать всё на электроне, но решили хайпануть сначала на го, но это им показалось не достаточно нажористо, и потому анонсировали использование rust в качестве языка написания и какую-то там libcosmic. Но чтобы ты не расслаблялся, анончик, помимо затаскивания нескольких новых гигов зависимостей для сборки сего чуда, код агента будет написан на .net и будет пускаться вайном.

Для отрисовки могут применяться движки на базе Vulkan, Metal, DX12, OpenGL 2.1+ и OpenGL ES 2.0+. Максимум нет. Пока доступна лишь простейшая версия.

Если кого-то интересуют подробности, то они на опеннете.

Место для установки клоуна тут ↓.

Цель разработки компилятора – полная совместимость с синтаксисом языков Си и С++ при обеспечении полной безопасности работы с памятью. Заявляется, что для использования достаточно пересобрать существующий код, так уже компилируются и работают bzip2, zip, pcre и ncurses. С незначительными модификациями поддерживается сборка OpenSSH, OpenSSL, CPython, SQLite, Lua, Curl, Lynx, jpeg6b, zsh, xzutils и simdutf.

( читать дальше... )

>>> Подробности

Проект развивает Робин Роу (Robin Rowe), бывший профессор компьютерных наук, принимавший участие в комитетах по развитию стандартов С и С++, в своё время создавший графический редактор Cinepaint, использовавшийся при создании некоторых голливудских фильмов, и POSIX-библиотеку libunistd для Windows. Соучредителем компании Trasec выступает Габриэль Пантера (Gabrielle Pantera), занимавшая руководящий пост в компании Disney.

Из особенностей:

• Проверки выхода за границы массива. В TrapC применяется фундаментально иной способ работы с указателями и специальный механизм перехвата ошибок на основе обработчиков исключений (trap).

• Проверки use after free.

• Наличие GC.

• Выделение памяти через new. *alloc и free нет.

• Явная инициализация нулями.

• Строгая типизация.

Исходный код компилятора для TrapC планируют открыть в 2025 году.

>>> Подробности

Пока 3 страницы, но вы же знаете как они блочат https

https://tass.ru/ekonomika/22076043

А тот, кто им поверил,
Что он им друг и брат,
Тот, видимо, думал, что ливень
Польется в небо назад.

В опубликованных на днях исходных текстах мультимедийного проигрывателя Winamp обнаружено заимствование кода, распространяемого под лицензиями GPL и LGPL. В частности, среди кода Winamp присутствовали файл fir_proc.cpp, кодировщик BladeMP3, плагин in_vorbis и компоненты генератора парсеров GNU Bison, распространяемые под лицензией GPL. Кроме того, в составе поставлялся изменённый код библиотеки libdiscid 0.6.2, распространяемой под лицензией LGPLv2.1. В репозитории Winamp также найдены бинарные сборки открытых библиотек libogg и vorbis, добавленные без указания лицензии.

https://www.opennet.ru/opennews/art.shtml?num=61947

Код winamp открыт под пропиетарной лицензией. Ждём реакции заинтересованных лиц.

Но не переходят, а только планируют, в течении трёх лет. А там или ишак или падишах, как в известной байке. О том, будет ли переведено существующее ПО на линукс в котором ведётся работа об этом новость не сообщает.

В целом после прочтения новости на опеннете складывается впечателение, что раст это секта, по типу протестанских сект, но вместо десятины - заставляют учить и писать на этом, только вчитайтесь:

Ушедший сопровождающий, который подключился к проекту 4 года назад, является сотрудником компании Microsoft и автором экспериментального драйвера с реализацией ФС EXT2, написанного на языке Rust

Экспериментальный драйвер очень нужной фс от работоспособного разраба:

В этом году Алмейда внёс в репозиторий Rust-for-Linux 17 коммитов

В качестве причины ухода упоминается нехватка сил и энтузиазма, которые когда-то были для реагирования на некоторые бредни нетехнического характера (nontechnical nonsense).

У них там какой-то филиал двача досок /pr/ и /gay/

Закономерно те кто тащат ядро линукса слегка офигивают, то есть это они должны писать на расте, а не вот эти банальные клоуны изучать внутреннее устройство и слать патчи.

автор файловых систем ext2/ext3/ext4, который сравнил инициативу Rust-for-Linux c попыткой заставить всех принять религию Rust.

Ну и в конце место для традиционной перемоги: барен что-то там переписал на расте.

Насладиться техническими подробностями нового выпуска и немного охренеть с поведения растоманов тут.

В книге Седжвика. «Фундаментальные алгоритмы на С++» предлагается такая сортировка:

template <class Item>
void fixDown(Item *a, int k, int N)
{
    while (2 * k <= N)
    {
        int j = 2 * k;
        if ((j < N) && (a[j] < a[j + 1]))
            j++;
        if (a[k] > a[j])
            break;
        std::swap(a[k], a[j]);
        k = j;
    }
}

template <class Item>
void heapsort(Item *a, int l, int r){
    int k, N=r-1+1;
    Item *pq = a+1-1;
    for(k=N/2;k>=1;k--)
    fixDown(pq, k, N);
    while (N>1)
    {
        std::swap(pq[1], pq[N]);
        fixDown(pq, 1, --N);
    }    
}

И всё бы хорошо, сортирует полюбому быстро за O(N lgN), памяти дополнительной не требует, но есть неприятный нюанс: Если сгенерить такой массив, такой функцией.

int len=2300000;
auto array=generantion_array(0, 23000000,len);

int *generantion_array(int min, int max, int len)
{
    std::default_random_engine generator;
    std::uniform_int_distribution<int> distribution(min, max);
    int *array = new int[len];
    for (int i = 0; i < len; i++)
    {
        array[i] = distribution(generator);
    }
    return array;
}

То получается пара элементов не отсортирована:

180 10

Почему так происходит?

То есть дефакто mono все:

Microsoft продолжит сопровождение более современного форка Mono Runtime, включённого в состав кодовой базы открытой платформы .NET. Планируется постепенно перевести на данный форк компоненты проектов Microsoft, остающиеся завязанными на Mono. Компания Microsoft также заявила, что рекомендует пользователям приложений, использующих Mono, перейти на использование общей платформы .NET, включающей Mono Runtime.

Подробности.