Рафаэль Садовский (Rafael Sadowski) объявил о доступности пользовательского окружения KDE Plasma 5.27 для установки в OpenBSD-current, формировании готовых для установки пакетов kde-plasma и kde-plasma-extra, и намерении обеспечить поддержку KDE Plasma в весеннем выпуске OpenBSD 7.5. После прекращения поддержки KDE4 в OpenBSD так и не была перенесена возможность использования новой ветки рабочего стола KDE Plasma 5. Пакеты с приложениями KDE Gears 5 и библиотеками KDE Frameworks 5 достаточно давно доступны в портах OpenBSD, но сама оболочка до настоящего времени оставалась неработоспособной.
Для установки KDE Plasma и KDE Gear теперь достаточно выполнить команды:
pkg_add kde
pkg_add kde-plasma
pkg_add kde-plasma-extra
Отмечается, что переход ветки KDE 6 на Qt 6 не будет большой проблемой для OpenBSD, так как в рамках проведённого портирования ветка Qt 6 и связанные с ней зависимости уже адаптированы для работы в OpenBSD. Из остающихся задач отмечается решение некоторых недоработок с композитным сервером KWin, Wayland, NetworkManager и SDDM. Также планируется добавить поддержку утилиты pkg_add в интерфейсе установки приложений Discover.
По rust - если кратко, то обеспечение безопасной работы с памятью - это основной тренд развития C++ все эти годы. И современный C++ ее обеспечивает, давая в стандартной библиотеке все нужные структуры данных (списки, векторы, массивы, кортежи и т. д.), с которыми можно и нужно (!), именно Н У Ж Н О работать без использования указателей.
Напомню, что в “небезопасных” языках “небезопасность” связана всегда именно с использованием сырых указателей - это лишает компилятор возможности контроля за происходящим, и все отдается на откуп корректности кода, который мы написали. В современном C++ вместо этого, надо использовать готовые высокоуровневые структуры данных из стандартной библиотеки, что снимает необходимость использования сырых указателей в пользовательском коде. А если этого недостаточно - можно добавить любые свои структуры при помощи языка шаблонов.
И в итоге получается ровно то о чем пишет @crypt постоянно - баги работы с памятью локализуются в стандартной библиотеке, и уходят из прикладного кода.
То же самое, по сути, происходит и в rust. Надо использовать safe rust, при этом низкоуровневые вещи должны быть уже написаны до нас на unsafe rust. Баги локализуются там.
Разница только в том, что rust четко разграничивает safe/unsafe блоки кода. А C++ нет - ты можешь всунуть сырые указатели куда угодно, это нельзя запретить на уровне компилятора для блока кода.
Но это не является проблемой, потому что правила “safe C++” очень просты, установить для проекта их несложно, отслеживать не ревью неправомерное применение сырых массивов и сырых указателей - не составляет труда. Проверять это статическим анализатором - не составляет труда.
Поэтому, если мы имеем офонаренную кодовую базу на корявом C++, рациональнее всего переписать некоторые места (где сырые указатели и массивы плещутся в прикладном коде) на современном C++. Это уберет проблемы работы с памятью и сохранит миллионы человеко-часов работы.
Для этого не надо изобретать новый язык с шизоидным синтаксисом и правилами, без ООП, и переписывать на этом недоразумении весь софт мира с нуля.
ААААА ВООООООТ ЕЕЕЕЕЕСЛИИИИ у вас сама цель и состоит в том, чтобы ПЕРЕПИСЫВАТЬ ВЕСЬ СОФТ С НУЛЯ, выбив под это финансирование - тогда конечно вам нужен новый ни с чем не совместимый шизоязык! Вы будете на него молиться!
Да, я слышал об этом. Правда говорят, что очень легко начать писать незащищенный код и отстрелить ногу.
Да, эта логика для меня звучит убедительно.
Но если говорить о новых проектах, драйверах и т.д., то лично для меня объектность языка - недостаток. А вот Си с защитой памяти - это самое то, что нужно.
ООП для GUI это мастхев, на языках без него катитесь колбаской по малой спасской. Я писать отказываюсь.
Для драйверов - спорно, но код драйверов Haiku на C++ для меня более удобен и понятен, чем в linux на C. По крайней мере, это никак не мешает точно.
Да, для этого подойдёт и rust, но зачем плодить сущности? Нафейхоа нам два разных языка, для ОС и для прикладнухи, если есть один язык для всего?
для гуи, наверное, ты прав, а мне как системному специалисту с++ вообще никак не уперся. по сути у меня выбор, какой из двух безопасных языков учить и rust мне ближе.
куда лучше чем что?) чем Си или rust в ядре?)
Чем php или python на бэкенде, javascript на фронтэнде, в рамках одного проекта.
как бы да, но если ты читал новости, в проекте node.js постоянно что-то дикое творится с репами. современный язык сейчас почему-то обязательно связан с публичной помойкой всяких модулей от noname творцов… и последующими историями, когда что-то рвануло на производстве…
Ага, это прямо про rust. Теперь такая помойка будет в ядре, бггг
Потому что в расте как раз пакетный менеджер языка, как любят смузихлебы.
вот да, я тоже спросил “хороший язык, зачем его портить”. мне сказали, что сейчас так модно и без этого нельзя.
кстати, ты блог читал? https://rsadowski.de/posts/2024-01-09-openbsd-kde/
NetworkManager кстати и во фряшном порте KDE отсутствует.
че? это сейчас к чему? нету во фряхе nm.
А в OpenBSD есть?
nm - это чисто линуксовая питонятина, которую пишет RH, емнип. не понял, как это связано с ссылкой на блог. там автор пишет о своих мотивах.
Here are some thoughts on what we could work on. Fix KWin compositor KDE Wayland NetworkManager (It’s based on glib and GObject. I don’t like it)???
без понятия. NetworkManager was originally developed by Red Hat and now is hosted by the GNOME project. может, он и гном 5 заодно хочет портировать.
Если бы я был президентом, я бы совсем не на линуксе приказал делать национальную ОС.
Так больше не на чем, на остальных надо работать, а не просто заменять обоину.
Аааа, вот начинают проявляться истинные причины хейта. Понятно. Ничего нового. Старопердунский механизм застилает глаза, и там хоть оглоблей по башке, но никакие аргументы не подействуют.
В разграничении работы людей вокруг этого языка. Сам же выше приводишь пример с выводом библиотек на unsafe за пределы поля внимания программиста. Этим занимаются другие люди. Это тупо эффективнее.
Ну давай поднимем градус шизы и вернемся к чистой С89. Вполне хватает, чо.
Под дельфи же писали, а она ООП тщательно от пользователя скрывает. Да, получаются “магические кнопки” и т.д. - но, для малого проекта ваще непринципиально.
Даже смузи вебники прозрели внезапно и поняли, что куда лучше иметь один язык для всего, и вкорячили JavaScript на сервер. И надо сказать, это действительно куда как лучше!
Лучше для чего? Для усиления вэбмакакства? Ну да, однозначно лучше.
Да. Я не говорю что это само по себе хорошо, но в рамках их мира им лучше.
На самом деле, если ты топишь за С++, то с твоей т.з. использование С/С++ подобного языка для разработки веба - это максимально выгодно. А что бы ты еще мог желать собственно?
Такого туда не завезли.