Для OpenBSD реализована возможность использования рабочего стола KDE Plasma

а не мне.

А другим ненужна?

нвидии норм под опенком работают.

Да, я это знаю. Работают очень старые версии. У меня тоже старая версия, но она не работает.

не понимаю, почему они до сих пор не взялись за переписывание.

Может, лет через десять и перепишут…

ну а смысл портировать бету

Нужно портировать не бету, а портировать когда выйдет стабильная ветка. А она не за горами.

после EOL пользоваться. что такого.

Не секюрно как то.

кде не бывает стабильным. какая нафиг стабильная ветка.

Ну так в опенсорсе как заведено - кому надо тот и делает.
«Patches welcome».

Не секюрно как то.

а ты давно видел уязвимости к kde in the wild? если какая-то проблема будет массовой, переполнение там какое-нибудь пофиксит любой программист, а так этот вообще в принципе секьюрным считать нельзя. что еще более грустно, даже в компонентах xorg баги по 15 лет лежат. о чем тут можно говорить? так что я совершенно не согласен с @JamesHolden, что даже ограниченными преимуществами, которые дает rust, можно пренебречь. по моим понятиям, если хотя бы прикладные программисты начнут писать более защищенный код, это будет мега-успех. а жалобы, что основная библиотека не безопасна… ну блин, это локализация проблемы, в одной библиотеке проще ошибки исправить.

я изучал вопрос и OpenBSD не адаптирует rust по двум причинам а) консервативность и недоверие б) непортабельность под все те архитектуры, что они поддерживают.

но кде-то в основном работает на x86.

кроме того

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.

и я, конечно, не программист, но в презентации я вижу на 12.50:

• Don’t allow user to pass and destroy closure
• Handle life time nicely
• Handle concurrency nicely

вот это все то, что я бы хотел видеть у авторов плазмы. Потому что проект сыпется и сыпется на подобных вещах.

я изучал вопрос и OpenBSD не адаптирует rust по двум причинам

Основная причина третья - мозг.

Жаль, что это есть у gtk, но нет у qt.

Ты подумай что пишешь. Qt это C++ фреймворк, с ним нельзя работать из раста.

Gtk это C фреймворк.

C++ не обладает свойством C работать с любыми языками.

там же идут биндинги на уровне методов, api

а ты давно видел уязвимости к kde in the wild?

Я имел в виду уязвимости в qt5.

пофиксит любой программист

Я представления не имею, как такое отправят в Debian…тем более, без согласования с апстримом.

кому надо тот и делает.

А ты перестань шланговать, и почитай OpenBSD рассылку, клторая касается Nvidia.

какая нафиг стабильная ветка.

Это то, что они сами так называют.

Я представления не имею, как такое отправят в Debian…тем более, без согласования с апстримом.

мы же о том, что делать, если апстрим достиг EOL

я к тому, что я нормально отношусь к тому, что kde портировали, когда портировали. там все настолько условно, что сложно достоверно сказать, как лучше. я бы на его месте делал так же. взял версию, где линуксоиды уже наконец пофиксили самое очевидное, а на EOL забил.

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

Мне вот до фонаря, на чем написан пакетный менеджер, он кстати с 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.

но мне чаще по списку нужно удалить зависимости

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

rust - это ничего не дающая профанация, с экосистемой в сравнении с C/C++ вызываещей лишь припадки смеха.

Откуда такая категоричность? Да, язык прошел стадию становления и детских ошибок. Сейчас-то за что ты его так? Мысль можешь развернуть?

Лучше, для начала, разверните мысль что именно даёт rust из того, что не даёт C++. А потом разберемся почему растовая пропаганда это лапша на уши.

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

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

а на EOL забил.

Они себя позиционируют как супер-дупер секюрную систему, так что забить не выйдет.

так KDE не входит в систему.

если апстрим достиг EOL

Я о том, что никто этим заниматься не будет. Было бы проще форкнуть, как форкнули KDE3, и создали франкенштейн, под названием TDE.

так KDE не входит в систему.

Знаю, но для хомячков нужен гуй.

да блин, чуваку просто надо было, чтобы его привычный рабочий стол работал. не больше. чего вы все развели тут историю. я сделал себе билд пакетов на фряхе и я ее не трогаю. сижу себе и не обновляю спокойненько до FreeBSD 13 EOL.

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$ 

это что-то самописное?

хорошо, что у нас осталась хоть одна система, где хомячки никого не волнуют. чувак выложил то, что сделал для себя.

перечитай мое сообщение

чуваку просто надо было

Что и требовалось доказать.

чего вы все развели тут историю

Хо, хо, хо. Какая тут история. Просто насмехаюсь над разрабами OpenBSD, которые имитируют бурную деятельность.

Как можно имитировать бурную деятельность, если бурная деятельность в принципе в проекте не предполагается? Ты над проектом насмехаешься или себя на смех решил поднять? Это проект-песочница, они вообще никуда не торопятся.

никуда не торопятся.

Оно и видно. Достаточно посмотреть на поддержку железа.

Ты понимаешь вообще, что у проекта нет цели его активно поддерживать? Или ты умом не можешь понять, что у проекта могут быть другие цели? Или тебя просто обида заела, что на тебя, хомячка, всем плевать?

Это не баг, это by design. Зато OpenSSH из этого проекта пользуется весь мир. OpenBSD - это тупо платформа, которая нужна самим разработчикам.

Ты понимаешь, что есть принципиальная разница между маргинальным Void, который нацелен на хомячков, которые хотят быть маргиналами, и OpenBSD, которому на хомячков наплевать?

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

А OpenBSD вообще не для этого.

Кто это сказал, что void нацелен на хомячков? Что за лол

А ты посмотри, мне один такой ща пишет. FreeBSD 14. Кеды, коньки, холст. (комментарий)

Он тупо не отличает фряху от линукса.

Или вот @odalist мне пишет по очереди в два треда (очень неудобно у нас получилось): Для OpenBSD реализована возможность использования рабочего стола KDE Plasma (комментарий)

Он в одном треде топит против OpenBSD, потому что хомячковых фич мало, а в другом за Void.

Ты пойми, что есть хомячки, которые хотят быть не такими, как все, но это тоже хомячки!

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

Маргинальный хомячок не может использовать винду, как все. И не может использовать хайку из-за ограничений. Поэтому постоянно ноет, что ОС где-то тормозит или железо не поддерживает)

По rust - если кратко, то обеспечение безопасной работы с памятью - это основной тренд развития C++ все эти годы. И современный C++ ее обеспечивает, давая в стандартной библиотеке все нужные структуры данных (списки, векторы, массивы, кортежи и т. д.), с которыми можно и нужно (!), именно Н У Ж Н О работать без использования указателей.

Напомню, что в «небезопасных» языках «небезопасность» связана всегда именно с использованием сырых указателей - это лишает компилятор возможности контроля за происходящим, и все отдается на откуп корректности кода, который мы написали. В современном C++ вместо этого, надо использовать готовые высокоуровневые структуры данных из стандартной библиотеки, что снимает необходимость использования сырых указателей в пользовательском коде. А если этого недостаточно - можно добавить любые свои структуры при помощи языка шаблонов.

И в итоге получается ровно то о чем пишет @crypt постоянно - баги работы с памятью локализуются в стандартной библиотеке, и уходят из прикладного кода.

То же самое, по сути, происходит и в rust. Надо использовать safe rust, при этом низкоуровневые вещи должны быть уже написаны до нас на unsafe rust. Баги локализуются там.

Разница только в том, что rust четко разграничивает safe/unsafe блоки кода. А C++ нет - ты можешь всунуть сырые указатели куда угодно, это нельзя запретить на уровне компилятора для блока кода.

Но это не является проблемой, потому что правила «safe C++» очень просты, установить для проекта их несложно, отслеживать не ревью неправомерное применение сырых массивов и сырых указателей - не составляет труда. Проверять это статическим анализатором - не составляет труда.

Поэтому, если мы имеем офонаренную кодовую базу на корявом C++, рациональнее всего переписать некоторые места (где сырые указатели и массивы плещутся в прикладном коде) на современном C++. Это уберет проблемы работы с памятью и сохранит миллионы человеко-часов работы.

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

ААААА ВООООООТ ЕЕЕЕЕЕСЛИИИИ у вас сама цель и состоит в том, чтобы ПЕРЕПИСЫВАТЬ ВЕСЬ СОФТ С НУЛЯ, выбив под это финансирование - тогда конечно вам нужен новый ни с чем не совместимый шизоязык! Вы будете на него молиться!

Ты пойми, что есть хомячки, которые хотят быть не такими, как все, но это тоже хомячки!

Конечно! И для них делают Haiku!

И современный C++ ее обеспечивает

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

Поэтому, если мы имеем офонаренную кодовую базу на корявом C++, рациональнее всего переписать некоторые места (где сырые указатели и массивы плещутся в прикладном коде) на современном C++. Это уберет проблемы работы с памятью и сохранит миллионы человеко-часов работы.

Да, эта логика для меня звучит убедительно.

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

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

ООП для GUI это мастхев, на языках без него катитесь колбаской по малой спасской. Я писать отказываюсь.

Для драйверов - спорно, но код драйверов Haiku на C++ для меня более удобен и понятен, чем в linux на C. По крайней мере, это никак не мешает точно.

Да, для этого подойдёт и rust, но зачем плодить сущности? Нафейхоа нам два разных языка, для ОС и для прикладнухи, если есть один язык для всего?

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

для гуи, наверное, ты прав, а мне как системному специалисту с++ вообще никак не уперся. по сути у меня выбор, какой из двух безопасных языков учить и rust мне ближе.

действительно куда как лучше!

куда лучше чем что?) чем Си или rust в ядре?)