Представлен первый выпуск проекта XLibre, развивающего форк X.Org Server. Выпуск позиционируется как имеющий качество бета-версии и предназначен для тестирования и выявления возможных недоработок. XLibre 25.0 включает изменения ABI, то есть для корректной работы требуется пересборка X11-драйверов. Проект открыт к сотрудничеству с дистрибутивами и готов интегрировать в свой состав патчи, накопившиеся в процессе сопровождения пакетов с сервером X.Org.
( читать дальше... )
15 июня состоялся выпуск 4.0.7 многопоточной консольной утилиты поиска файлов bfs (Breadth-First Search, поиск в ширину), написанной на языке C и распространяемой по лицензии BSD.
Изменения:
Tewi — это TUI-клиент для управления демоном Transmission через его RPC-протокол.
Проект написан на Python и использует фреймворк Textual для реализации интерфейса. Лицензия — GPLv3+.
Поддерживается Transmission 2.40 и выше.
( читать дальше... )
Разработчики свободной системы автоматизированного проектирования печатных плат 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:
Команда разработчиков Arch Linux сообщила, что теперь Wine и Wine-Staging по умолчанию собираются в режиме Wow64 (Windows-on-Windows 64-bit). Это решение позволяет запускать 32-битные Windows-приложения в 64-битных Unix-средах без необходимости использовать 32-битные библиотеки. Благодаря переходу на 64-битные версии Wine отпала необходимость в использовании репозитория multilib для пакетов wine и wine-staging.
Основной причиной такого перехода стало стремление к согласованию с актуальными изменениями в основном проекте Wine — для упрощения сборки пакетов и уменьшения числа зависимостей. Вместе с тем, разработчики предупреждают о возможных сложностях: может наблюдаться снижение производительности OpenGL в 32-битных Windows-программах, а также потребуется пересоздать имеющиеся 32-битные префиксы Wine.
Установка steam по прежнему требует использования репозитория multilib.
Новая версия Plasma уже здесь, и она стала ещё больше похожа на /home, поскольку стала более плавной, дружелюбной и полезной.
Plasma 6.4 улучшена практически по всем направлениям, прогресс достигнут в в специальных возможностях, цветопередаче, поддержке планшетов, управлении окнами и многом другом.
( читать дальше... )
GoTo – консольный менеджер ssh-подключений. Программа написана на языке Go и распространяется по лицензии MIT.
Утилита помогает быстро манипулировать списком серверов, а также предоставляет интерфейс к файлу .ssh/config. Программа поддерживает поиск и группировку. На гитхабе есть короткие демки и F.A.Q., где можно посмотреть некоторые детали.
Мотивацией для написания было желание сэкономить собственное время, но программа расползлась по друзьям и коллегам. В итоге автор ее причесал, выложил в общий доступ и потихоньку наполняет фичами. Если понравится - берите и пользуйтесь.
Это прямой перевод записи из блога Rust.
Мы запускаем Опрос по производительности компилятора Rust.
Долгая компиляция кода на Rust часто упоминалась как одно из самых больших испытаний, ограничивающих продуктивность Rust-разработчиков. Люди, вносящие вклад в компилятор Rust, конечно, в курсе об этом, и они постоянно работают над улучшением ситуации, ища новые способы ускорить компилятор, сортируя регрессии производительности и измеряя наши долгосрочные улучшения производительности. Недавно мы также внесли крупные изменения, на разработку которых было потрачено много времени, так что производительность компилятора должна значительно улучшиться по умолчанию.
Когда речь идёт о производительности компиляции, важно отметить, что это не всегда так же просто, как определить, насколько долго rustc компилирует крейт. Есть много разнообразных рабочих процессов разработки, которые могут заставлять идти на компромиссы, и тех, которые могут быть затруднены различными факторами, такими как интеграция компилятора с используемой сборочной системой.
Для того, чтобы лучше понять эти рабочие процессы, мы приготовили Опрос по производительности компилятора Rust. Он акцентирован именно на производительности компиляции, что позволяет нам получить более подробные данные, чем те, которые мы обычно получаем из ежегодного опроса «State of Rust». Данные из этого опроса помогут нам понять места, на которых нам следует сосредоточить усилия по улучшению продуктивности Rust-разработчиков.
Пройти опрос вы можете здесь.
Прохождение должно занять приблизительно 10 минут вашего времени. Опрос полностью анонимен. Мы будем принимать формы до 7 июля 2025 года. По окончании опроса мы обработаем результаты и опубликуем ключевые моменты в этом блоге.
Приглашаем вас принять участие в опросе, ведь ваши ответы помогут нам улучшить производительность компиляции Rust. Спасибо!
После двух месяцев разработки состоялся выпуск 0.12 кроссплатформенного (Linux, MacOS, Windows) редактора текстов Notepad Next, написанного на языке C++ с использованием фреймворка Qt 6 (возможно, что скомпилируется и с Qt 5) и библиотек Lexilla, Scintilla, Qt Advanced Docking System, Lua и других.
Редактор распространяется по лицензии GPL-3.0 и называется автором кроссплатформенной реализацией Notepad++.
( читать дальше... )
Опубликован выпуск 6.0 MyCompany – бесплатного и открытого программного обеспечения для автоматизации малого и среднего бизнеса, основанного на платформе lsFusion. Исходный код доступен на GitHub под лицензией Apache 2.0, что позволяет разработчикам адаптировать и распространять решения под собственной торговой маркой.
( читать дальше... )