Рафаэль Садовский (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.
Пропатчили таки
Пропатчили таки
А говно можно патчить? Если можно, то что получится?
Ох ты ж, блин, слоупоки! Но, новость позитивная, конечно.
Да, смотрю херней заниматься они умеют. Вместо того, чтобы заняться поддержкой Nvidia с Nouveau, они добавляют KDE…
Вот и займись =)
Вот и займись =)
Займусь, когда задонатишь на топовое железо.
Так этож тебе невидия нужна а не мне.
а не мне.
А другим ненужна?
Ну так в опенсорсе как заведено - кому надо тот и делает. “Patches welcome”.
кому надо тот и делает.
А ты перестань шланговать, и почитай OpenBSD рассылку, клторая касается Nvidia.
Ток идет по пути наименьшего сопротивления.
кроме того
Link is a talk called Default Security at BlueHat IL 2023 by David Weston. He covers a bunch of areas and the final part of the talk (around 10 minutes) is about Microsoft introducing Rust in some self-contained areas in Windows. Some highlights: Their focus is on "killing bug classes". More context in this post by Microsoft Research from 2019 - A proactive approach to more secure code. They want to do this with memory safe languages, CPU architectural changes and safer language subsets. This talk focussed on memory safe languages, specifically Rust. First area they've introduced Rust in - a cross platform rewrite of a font parser called DWriteCore. The team reported that parsing was "incredibly easy". Font shaping performance increased by 5-15% compared to the C++ version. It took about 2 devs working for half a year to complete this. The speaker says this is pretty good value for an area that is notorious for security bugs. Second area is the REGION data type in Win32k GDI. Currently in consumer Windows, disabled by feature flag. Will be enabled in insider builds soon. Performance has been good, some small wins for the Rust version. There is now a Windows SysCall implemented in completed safe Rust. TLDR - Rust is inside the Windows Kernel, will be enabled widely soon.В опенсорсе по мне больше всего пользы будет не от модулей ОС на rust, хотя и это неплохо. А вот от такой вещи: https://gtk-rs.org/
Жаль, что это есть у gtk, но нет у qt.
Жаль, что это есть у gtk, но нет у qt.
Ты подумай что пишешь. Qt это C++ фреймворк, с ним нельзя работать из раста.
Gtk это C фреймворк.
C++ не обладает свойством C работать с любыми языками.
там же идут биндинги на уровне методов, api
и я, конечно, не программист, но в презентации я вижу на 12.50:
- Don’t allow user to pass and destroy closure
- Handle life time nicely
- Handle concurrency nicely
вот это все то, что я бы хотел видеть у авторов плазмы. Потому что проект сыпется и сыпется на подобных вещах.
KDE тоже нужно, не гном же использовать.
ЮKDE тоже нужно
Спорить не буду, но посмотрю как запоешь, когда она официально переползет на qt 6.
когда она официально переползет на qt 6
только-только основные баги в пятом кде успеют исправить… и тут сначала.
только-только основные баги в пятом кде успеют исправить
Именно так и будет.
единственное спасение для KDE - это переходить на безопасный язык типа rust. всех ошибок не вылечит, но в коде плазмы станет ошибок заметно меньше. не понимаю, почему они до сих пор не взялись за переписывание.
Потому что любой разработчик понимает, что rust - это ничего не дающая профанация, с экосистемой в сравнении с C/C++ вызываещей лишь припадки смеха. Это просто дурилка картонная для любителей лапши на уши.
блин, но чуть-чуть сокращается поверхность. основной глючный код делают сами кдешники. вот станет хотя бы он лучше - уже 50% проблем уйдет.
Это просто дурилка картонная для любителей лапши на уши.
Даже Линус понял преимущества раста и разрешил его в ядро. А вот от твой любимый С++ он всегда посылал нахер. А ты просто старый консервативный пердун.
Он разрешил, потому что за жизнь он уже задолбался бодаться с баранами. Это просто мудрость.
Это же клоунада какая-то (по расту в ядре)
Например, у нас есть конкретные машинно-проверяемые требования, касающиеся использования небезопасного кода: для каждой небезопасной функции разработчик должен документировать те требования, которым должна удовлетворять вызывающая сторона – таким образом, гарантируется безопасность использования. Кроме того, при каждом вызове небезопасных функций разработчик обязан документировать те требования, которые должны удовлетворяться вызывающей стороной в качестве гарантии того, что использование будет безопасным. Кроме того, для каждого вызова к небезопасным функциям (или использования небезопасных конструкций, например, при разыменовании сырого указателя) разработчик должен документировать обоснование, почему делать так безопасно.Я и на C могу написать в документации, почему небезопасный вызов делать безопасно. Лол)))
rust - это ничего не дающая профанация, с экосистемой в сравнении с C/C++ вызываещей лишь припадки смеха.
Откуда такая категоричность? Да, язык прошел стадию становления и детских ошибок. Сейчас-то за что ты его так? Мысль можешь развернуть?
Лучше, для начала, разверните мысль что именно даёт rust из того, что не даёт C++. А потом разберемся почему растовая пропаганда это лапша на уши.
не понимаю, почему они до сих пор не взялись за переписывание.
Может, лет через десять и перепишут…
Классика опенсурса
мне кстати один чувак рассказывал в тележном опеночном чатике, что какие-то нвидии норм под опенком работают. Ну как норм, для десктопа хватит
нвидии норм под опенком работают.
Да, я это знаю. Работают очень старые версии. У меня тоже старая версия, но она не работает.
Все равно до линукса как до Китая раком.
@odalist вы не понимаете! это проект-песочница! у них нет цели тягаться с линуксом!!! им этот KDE вообще не уперся, это просто кто-то по фану сделал.
ЕМНИП у них pf до сих пор не умеет в многопоточность.
ты знаешь, что такое проект-песочница?
Да, что-то типа AROS.
вот про твой арос никто не знает, так что я думаю и ты не знаешь. отсюда какие-то странные комменты про pf. эту операционку никто не собирается использовать в проде.
в этой операционке тестируют защищенные системные вызовы, прочие техники обеспечения безопасности, пишут портабельный код OpenSSH… ну и все, пожалуй.
жаль, что они пока к расту относятся как к новомодной фигне, которая еще через 10 лет только может созреть.
Короче дрочат вприсядку. Хотя не спорю, некоторые функции в опенбсдшном libc вроде
strtonum,strlcpyиstrlcatдовольно полезные и я их часто использую, пусть и путем линковки с libbsd.Последние две даже в свежей glibc появились.
Короче дрочат
ну короче ты как всегда ничего не понял. что в политике не бельмеса не понимаешь, что в айти.
екоторые функции в опенбсдшном libc
если что openssh весь мир использует. а это конкретно их проект. оска здесь чисто под свои нужды. не хотят они на линуксе тестировать.
ну короче ты как всегда ничего не понял. что в политике не бельмеса не понимаешь, что в айти.
Один ты самый умный.
жаль, что они пока к расту относятся как к новомодной фигне, которая еще через 10 лет только может созреть.
Жаль что у людей есть мозг? Вот это да.
ну давай считать вот у нас есть три участка кода на си: A + B + C. ты заменяешь один на безопасный. становится хуже или что?
Его невозможно заменить на безопасный. Он все равно будет дергать опасный код.
ну не совсем так, с каждым релизом он становится все более многопоточным
по фану сделал.
Значит, стащили наработки из FreeBSD. Хотя эта плазма и у них глючная…
и у них глючная…
ну так если на всем линуксе все баги не выловили, то на фряхе уж и подавно аудитория меньше. плазма настолько глючная, что весь опенсорс с этим ничего не может сделать годами. а вот если бы они на раст писали…
на раст писали…
Так пишут, но дела продвигаются медленно. Так медленно, что работает только vesa.
а что пишут-то? есть официальная линия партии новый кде писать на раст?
кде писать на раст?
Они свою пишут. Она похожа на KDE.
ну так если на всем линуксе все баги не выловили
Они там все ССЗБ. Плазма скоро на qt6 будет, а они портируют 5.27, которой не за горами EOL.
Они там все ССЗБ.
ну а смысл портировать бету. чтобы потом она падала постоянно? будут после EOL пользоваться. что такого.
ну а смысл портировать бету
Нужно портировать не бету, а портировать когда выйдет стабильная ветка. А она не за горами.
после EOL пользоваться. что такого.
Не секюрно как то.
кде не бывает стабильным. какая нафиг стабильная ветка.
какая нафиг стабильная ветка.
Это то, что они сами так называют.
Не секюрно как то.
а ты давно видел уязвимости к kde in the wild? если какая-то проблема будет массовой, переполнение там какое-нибудь пофиксит любой программист, а так этот вообще в принципе секьюрным считать нельзя. что еще более грустно, даже в компонентах xorg баги по 15 лет лежат. о чем тут можно говорить? так что я совершенно не согласен с @JamesHolden, что даже ограниченными преимуществами, которые дает rust, можно пренебречь. по моим понятиям, если хотя бы прикладные программисты начнут писать более защищенный код, это будет мега-успех. а жалобы, что основная библиотека не безопасна… ну блин, это локализация проблемы, в одной библиотеке проще ошибки исправить.
я изучал вопрос и OpenBSD не адаптирует rust по двум причинам а) консервативность и недоверие б) непортабельность под все те архитектуры, что они поддерживают.
но кде-то в основном работает на x86.
я изучал вопрос и OpenBSD не адаптирует rust по двум причинам
Основная причина третья - мозг.
а ты давно видел уязвимости к kde in the wild?
Я имел в виду уязвимости в qt5.
пофиксит любой программист
Я представления не имею, как такое отправят в Debian…тем более, без согласования с апстримом.
смотря в чем, в каких то вещах линуксу до опенка как до китая раком https://www.openbsd.org/innovations.html
Ладно, pledge/unveil годная вещь.
OpenBSD - замечательный проект. Тео - замечательный чувак. Но я сам иногда оказываюсь в ситуации ворчащего пользователя, который не может это заюзать. Ну вот, например, мне нравится пакетный менеджер фряхи на чистом С. Ну ничего не могу с собой поделать. Мне нравится размер в 25к и то, что он делает абсолютно все, что мне нужно и абсолютно так, как мне нужно. Что он настолько гибкий, что я могу из него выгнуть то, что хочется лично мне. OpenBSD использует просто заменитель PM в виде набора perl-скриптов. Ну это не то:(
Поэтому, если бы в проекте FreeBSD заимствовали больше именно то, из-за чего OpenBSD создавался…
мне вот во фряхе немного раздражает что местами что-то где-то кривовато. Линуксолятор есть, но для меня он малоюзабельный и кривой, звук черти как через хинты настраивается, прекрасный бихэв с ужасным интерфейсом, ну и тому подобное прочее. А опенок - простой, падла, и просто работает из коробки, почти ничего настраивать не надо. Да, тормозной, тюнить костылями пожалуй только это вот, и софта меньше, ну и фиг с ним, почти все что мне надо - все есть.
Мне вот до фонаря, на чем написан пакетный менеджер, он кстати с 7.4 значительно ускорился. Мне им пакеты ставить, и все. Я кстати искал во фряхе, чтобы можно было сохранить список всех установленных пакеты без версий в файл, чтобы можно было воспроизвести на другой системе/переставить существующую, как я это делаю на опенке - https://www.openbsd.org/faq/faq15.html#PkgDup и нифига не нашел в этом навороченном pkg на чистом си.
Да, но фряха, конечно гораздо лучше линукса для меня.
чем более сложная хрень, тем больше беспорядка. openbsd -> freebsd -> linux.
конечно, чем проще, тем лучше, если можешь себе позволить отсутствие фич. я все-таки активно использую снапшоты фс и jail. bhyve ни о чем пока. впрочем, я с таким интерфейсом и qemu терпеть не мог. дома просто использую VirtualBox и не играю в хакера.
Я кстати искал во фряхе, чтобы можно было сохранить список всех установленных пакеты без версий в файл
я ко всем pm пишу свои обертки, чтобы не думать, где я сейчас. я же по работе с кучей систем дело имел. но мне чаще по списку нужно удалить зависимости, если я что-то пробовал. и фряшный pm позволяет удобно все завернуть.
crypt@witch ~ $ aplist -h aplist -l list package's files -n list packages without versions. crypt@witch ~ $ apre -h apre -f remove by list crypt@witch ~ $ aplist -n |head archivers/7-zip misc/box2d x11-fonts/gentium-basic graphics/ImageMagick7а скорость может иметь значение. если опенбздешный для тебя не достаточно медленный, попробуй yum/dnf.
но мне чаще по списку нужно удалить зависимости
Там же оба пакетных менеджера, что фряшный, что опеночный умеют удалять неиспользованные зависимости, или ты не об этом?
Там же оба пакетных менеджера, что фряшный, что опеночный умеют удалять неиспользованные зависимости, или ты не об этом?
я таким обычно не пользуюсь. оно, например, решит удалить 10 пакетов со шрифтами, потому что от них ничего не зависит. нет, это именно то, что ты сказал - по списку. ставишь что-то на пробу. сохранил зависимости в файл. попробовал - удалил четко то, что поставил.
amihailov@t60p[0]:/usr/home/amihailov$ aplist ksh: aplist: not found amihailov@t60p[127]:/usr/home/amihailov$ doas pkg search aplist amihailov@t60p[1]:/usr/home/amihailov$это что-то самописное?
перечитай мое сообщение
скриншот зачетный. это у них по дефолту так аккуратно?
По rust - если кратко, то обеспечение безопасной работы с памятью - это основной тренд развития C++ все эти годы. И современный C++ ее обеспечивает, давая в стандартной библиотеке все нужные структуры данных (списки, векторы, массивы, кортежи и т. д.), с которыми можно и нужно (!), именно Н У Ж Н О работать без использования указателей.
Напомню, что в “небезопасных” языках “небезопасность” связана всегда именно с использованием сырых указателей - это лишает компилятор возможности контроля за происходящим, и все отдается на откуп корректности кода, который мы написали. В современном C++ вместо этого, надо использовать готовые высокоуровневые структуры данных из стандартной библиотеки, что снимает необходимость использования сырых указателей в пользовательском коде. А если этого недостаточно - можно добавить любые свои структуры при помощи языка шаблонов.
И в итоге получается ровно то о чем пишет @crypt постоянно - баги работы с памятью локализуются в стандартной библиотеке, и уходят из прикладного кода.
То же самое, по сути, происходит и в rust. Надо использовать safe rust, при этом низкоуровневые вещи должны быть уже написаны до нас на unsafe rust. Баги локализуются там.
Разница только в том, что rust четко разграничивает safe/unsafe блоки кода. А C++ нет - ты можешь всунуть сырые указатели куда угодно, это нельзя запретить на уровне компилятора для блока кода.
Но это не является проблемой, потому что правила “safe C++” очень просты, установить для проекта их несложно, отслеживать не ревью неправомерное применение сырых массивов и сырых указателей - не составляет труда. Проверять это статическим анализатором - не составляет труда.
Поэтому, если мы имеем офонаренную кодовую базу на корявом C++, рациональнее всего переписать некоторые места (где сырые указатели и массивы плещутся в прикладном коде) на современном C++. Это уберет проблемы работы с памятью и сохранит миллионы человеко-часов работы.
Для этого не надо изобретать новый язык с шизоидным синтаксисом и правилами, без ООП, и переписывать на этом недоразумении весь софт мира с нуля.
ААААА ВООООООТ ЕЕЕЕЕЕСЛИИИИ у вас сама цель и состоит в том, чтобы ПЕРЕПИСЫВАТЬ ВЕСЬ СОФТ С НУЛЯ, выбив под это финансирование - тогда конечно вам нужен новый ни с чем не совместимый шизоязык! Вы будете на него молиться!
И современный C++ ее обеспечивает
Да, я слышал об этом. Правда говорят, что очень легко начать писать незащищенный код и отстрелить ногу.
Поэтому, если мы имеем офонаренную кодовую базу на корявом C++, рациональнее всего переписать некоторые места (где сырые указатели и массивы плещутся в прикладном коде) на современном C++. Это уберет проблемы работы с памятью и сохранит миллионы человеко-часов работы.
Да, эта логика для меня звучит убедительно.
Но если говорить о новых проектах, драйверах и т.д., то лично для меня объектность языка - недостаток. А вот Си с защитой памяти - это самое то, что нужно.
ООП для GUI это мастхев, на языках без него катитесь колбаской по малой спасской. Я писать отказываюсь.
Для драйверов - спорно, но код драйверов Haiku на C++ для меня более удобен и понятен, чем в linux на C. По крайней мере, это никак не мешает точно.
Да, для этого подойдёт и rust, но зачем плодить сущности? Нафейхоа нам два разных языка, для ОС и для прикладнухи, если есть один язык для всего?
для гуи, наверное, ты прав, а мне как системному специалисту с++ вообще никак не уперся. по сути у меня выбор, какой из двух безопасных языков учить и rust мне ближе.
действительно куда как лучше!
куда лучше чем что?) чем Си или rust в ядре?)
куда лучше чем что?)
Чем php или python на бэкенде, javascript на фронтэнде, в рамках одного проекта.
как бы да, но если ты читал новости, в проекте node.js постоянно что-то дикое творится с репами. современный язык сейчас почему-то обязательно связан с публичной помойкой всяких модулей от noname творцов… и последующими историями, когда что-то рвануло на производстве…
с публичной помойкой всяких модулей от noname творцов
Ага, это прямо про rust. Теперь такая помойка будет в ядре, бггг
Потому что в расте как раз пакетный менеджер языка, как любят смузихлебы.
Ага, это прямо про rust. Теперь такая помойка будет в ядре, бггг
вот да, я тоже спросил “хороший язык, зачем его портить”. мне сказали, что сейчас так модно и без этого нельзя.
кстати, ты блог читал? https://rsadowski.de/posts/2024-01-09-openbsd-kde/
NetworkManager кстати и во фряшном порте KDE отсутствует.
че? это сейчас к чему? нету во фряхе nm.
А в OpenBSD есть?
Если бы я был президентом, я бы совсем не на линуксе приказал делать национальную ОС.
Так больше не на чем, на остальных надо работать, а не просто заменять обоину.
Для драйверов - спорно, но код драйверов Haiku на C++ для меня более удобен и понятен, чем в linux на C
Аааа, вот начинают проявляться истинные причины хейта. Понятно. Ничего нового. Старопердунский механизм застилает глаза, и там хоть оглоблей по башке, но никакие аргументы не подействуют.
Да, для этого подойдёт и rust, но зачем плодить сущности?
В разграничении работы людей вокруг этого языка. Сам же выше приводишь пример с выводом библиотек на unsafe за пределы поля внимания программиста. Этим занимаются другие люди. Это тупо эффективнее.
Нафейхоа нам два разных языка, для ОС и для прикладнухи, если есть один язык для всего?
Ну давай поднимем градус шизы и вернемся к чистой С89. Вполне хватает, чо.
ООП для GUI это мастхев, на языках без него катитесь колбаской по малой спасской. Я писать отказываюсь.
Под дельфи же писали, а она ООП тщательно от пользователя скрывает. Да, получаются “магические кнопки” и т.д. - но, для малого проекта ваще непринципиально.
Даже смузи вебники прозрели внезапно и поняли, что куда лучше иметь один язык для всего, и вкорячили JavaScript на сервер. И надо сказать, это действительно куда как лучше!
и вкорячили JavaScript на сервер.
И надо сказать, это действительно куда как лучше!
Лучше для чего? Для усиления вэбмакакства? Ну да, однозначно лучше.
Для усиления вэбмакакства?
Да. Я не говорю что это само по себе хорошо, но в рамках их мира им лучше.
Да. Я не говорю что это само по себе хорошо, но в рамках их мира им лучше.
На самом деле, если ты топишь за С++, то с твоей т.з. использование С/С++ подобного языка для разработки веба - это максимально выгодно. А что бы ты еще мог желать собственно?
использование С/С++ подобного языка для разработки веба
Такого туда не завезли.
Подписался, на мелодраму.
А раньше не было что ле? 😳
Были четвертые
Были четвертые
А, ну ок.
