Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
Сообщение от opennews (?), 22-Сен-24, 09:10
Опубликован выпуск проекта posixutils-rs 0.2.1, нацеленного на разработку на языке Rust коллекции утилит командной строки, упоминаемых в стандарте POSIX и соответствующих его требованиям (cp, mv, awk, make, vi, find, sort, wc, xargs, sh, m4, sed и т.п.).  При разработке по возможности используются уже существующие crate-пакеты. Код  posixutils-rs распространяется под лицензией MIT... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61908
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

2. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+22 +/–
Сообщение от Walker (??), 22-Сен-24, 09:11
Количество звездочек на GitHub свидетельствует о том, что это не вызывает большого интереса у пользователей.
Ответить | Правка | Наверх | Cообщить модератору

	3. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+21 +/–
	Сообщение от Аноним (3), 22-Сен-24, 09:18
	Это всё потому что вы ставите мало лайков и не подписыватесь на канал во время пулреквеста. Алгоритмы гитхаба не продвигают проект! Все ссылки и куаркоды в описании!
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+21 +/–
	Сообщение от 12yoexpert (ok), 22-Сен-24, 14:25
	нажал на колокольчик и рассказал всем в соцсетях я даже начал ходить по квартирам с Rust Book и рассказывать людям о Rust
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+8 +/–
	Сообщение от Аноним (68), 22-Сен-24, 14:53
	А как книжка называется, не "Сторожевая башня Rust"?
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+7 +/–
	Сообщение от OpenEcho (?), 22-Сен-24, 17:44
	> А как книжка называется, не "Сторожевая башня Rust"? Да нет же, зачем мешать кирилицу с латиницей?, - "Ржавая сторожевая башня"
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (17), 22-Сен-24, 10:19
	Так эта шляпа только опубликовалась. У uutils 17k звёзд, например.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	265. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (265), 23-Сен-24, 22:30
	Так мы узнали примерное количество адептов Раста с аккаунтом на GitHub.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–3 +/–
	Сообщение от Facemaker (?), 22-Сен-24, 10:27
	>Количество звездочек на GitHub свидетельствует о том, что это не вызывает большого интереса у пользователей. Спасибо за напоминание, добавил звезду.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	257. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (257), 23-Сен-24, 17:01
	Чему именно добавили?
	Ответить | Правка | Наверх | Cообщить модератору

5. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–4 +/–
Сообщение от Аноним (5), 22-Сен-24, 09:28
как там, cargo уже дотягивает до conan или хотя бы до vcpkg?
Ответить | Правка | Наверх | Cообщить модератору

	137. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Прохожий (??), 22-Сен-24, 22:32
	Давно превзошёл.
	Ответить | Правка | Наверх | Cообщить модератору

	266. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (265), 23-Сен-24, 22:33
	В раздутости разве что.
	Ответить | Правка | Наверх | Cообщить модератору

	277. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Прохожий (??), 23-Сен-24, 23:14
	По функциональности, конечно.
	Ответить | Правка | Наверх | Cообщить модератору

	304. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Александр (??), 24-Сен-24, 15:45
	Conan2 та ещё жесть. Причём первая версия была огонь: простая, легко интегрировалась куда угодно. Чего у авторов руки зачесались - не понятно. Хоть я и адепт плюсов, но эту тенденцию в комьюнити не понимаю: чем больше страдаешь, тем лучше. Это я о CMake и Conan2, которые чуть ли не негласные стандарты
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

7. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+14 +/–
Сообщение от Аноним (7), 22-Сен-24, 09:31
Поясните, каким образом эти новости связаны? Связь в том, что оба проекта -- едва рабочая шляпа?
Ответить | Правка | Наверх | Cообщить модератору

	138. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Прохожий (??), 22-Сен-24, 22:33
	Нет. Подсказка находится в названии новости.
	Ответить | Правка | Наверх | Cообщить модератору

10. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+3 +/–
Сообщение от Аноним (10), 22-Сен-24, 09:34
>не планирует обеспечивать совместимость с утилитами GNU, функциональность которых воспринимается авторами как необоснованно раздутая. Рекомендую авторам хотябы недельку поюзать солярку без гнутых утилит, а потом говорить о раздутой функциональности.
Ответить | Правка | Наверх | Cообщить модератору

	66. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 22-Сен-24, 14:52
	> Рекомендую авторам хотябы недельку поюзать солярку без гнутых утилит, а > потом говорить о раздутой функциональности. Они видите ли будут юзать - какое нибудь putty.exe, а вон то - для других, типа кушайте их безопасный код.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от ryoken (ok), 23-Сен-24, 10:10
	>>putty.exe Вообще говоря, в 10-ю венду с какого-то апдейта уже встроен клиент SSH. Это ваше пусси устарело.
	Ответить | Правка | Наверх | Cообщить модератору

	324. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (-), 24-Сен-24, 20:49
	>>>putty.exe > Вообще говоря, в 10-ю венду с какого-то апдейта уже встроен клиент SSH. > Это ваше пусси устарело. Оно уж совершенно точно не мое. Ибо нахрен это в линухе вперлось? Оно там страшное и кривое, так что его популярность в районе плинтуса. Ну и это, когда уже ядро то на Linux заменят? Вроде уж все слагаемые на месте :). Что они, GDI на Linux Kernel портануть не могут? Пусть вайн возьмут, во!
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 23-Сен-24, 00:13
	alpine юзаю не один год. все замечательно. единственное достоинство гнутых утилит - меньше в конечном итоге будет пайпов, а следовательно, форков. но оно невелируется тем, что в консоли Вы разницу во времени просто не заметите. а в скриптах, что посикс-совместимые, что не посикс-совместимы утилиты использовать - крайне сомнительно, ибо один черт все тормозить будет, за исключением ситуаций, когда Вы, например mv/cp/mkdir/etc в сабшелле пускаете; обойтись легко можно средставми даже исклюяительно посикс-шелла(в плане обработки текста), что уж говорить о ash-подобных.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

13. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
Сообщение от Аноним (13), 22-Сен-24, 09:45
А что, пусть люди тренируются. Всяко лучше, чем заниматся всякими ...
Ответить | Правка | Наверх | Cообщить модератору

14. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+8 +/–
Сообщение от Fracta1L (ok), 22-Сен-24, 09:54
Вчера я попробовал собрать amdgpu_top, написанный на расте. Оно по зависимостям скачало адову тучу крейтов (на мелкую утилитку, ага), среди которых была пачка чего-то там для windows. Сдаётся мне, в лице растаманов мир увидит такое цунами дерьмокодинга, какого не видел даже в лице джаваскрипто- и питоноприматов.
Ответить | Правка | Наверх | Cообщить модератору

	36. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+3 +/–
	Сообщение от Аноним (36), 22-Сен-24, 12:18
	> Оно по зависимостям скачало адову тучу крейтов (на мелкую утилитку, ага), среди которых была пачка чего-то там для windows. И запихало все в один бинарник
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (-), 22-Сен-24, 12:53
	Adding windows v0.52.0 (latest: v0.58.0) Если про эту строчку так это просто добавление в зависимости от winit https://github.com/rust-windowing/winit/blob/dfea49f48850670... Вы не не увидили фразы downloading/compiling windows
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	65. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (-), 22-Сен-24, 14:49
	> Вчера я попробовал собрать amdgpu_top, написанный на расте. Оно по зависимостям > скачало адову тучу крейтов (на мелкую утилитку, ага), среди которых была пачка > чего-то там для windows. А помните, дети, какой-то академ нахваливал WinNT? А потом он его на свое горе еще и попробовал... да... :) > Сдаётся мне, в лице растаманов мир увидит такое цунами дерьмокодинга, какого не > видел даже в лице джаваскрипто- и питоноприматов. Надо же, фракталушка стал догадываться кто в основном ведется на хайп и во что имнено это ему отольется :)
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	159. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+3 +/–
	Сообщение от Прохожий (??), 22-Сен-24, 23:25
	> на мелкую утилитку, ага Эта "мелкая утилитка" на самом деле умеет довольно многое. Не находишь? Поэтому совсем не удивительно, что ей надо много чего для своей работы. > среди которых была пачка чего-то там для windows Слышал звон, да не знаю, где он. Windows - это всегда операционная система? Или это может быть элементом интерфейса? Утилитка, которую ты решил собрать, она в двух режимах работать умеет: текстовом и графическом. Попробуй поразмышлять над этим на досуге. > Сдаётся мне, в лице растаманов мир увидит такое цунами дерьмокодинга, какого не видел даже в лице джаваскрипто- и питоноприматов. Кто-то здесь говорил про токсичное Rust-сообщество. Похоже, ему есть чему поучиться в этом плане у ненавистников этого языка программирования.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	171. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 23-Сен-24, 00:06
	> Кто-то здесь говорил про токсичное Rust-сообщество. Да они просто в своем глазу бревнище не видят. Можно вспомнить как поливали друг друга дырящечники и плюсовики в 200х. Как дыряшечники хаяли джаву, как хаяли питон, как обсирали с#, как... да мне сложно вспомнить хоть один язык, в обсуждение которого не врывались сишники и не начинали испражняться.
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (216), 23-Сен-24, 09:31
	> Слышал звон, да не знаю, где он. Windows - это всегда операционная система? Или это может быть элементом интерфейса? ну я тоже только слышал звон, да и компиляцией не занимаюсь https://github.com/Umio-Yasuno/amdgpu_top/blob/03d7c87bd66c2... https://crates.io/crates/windows/0.52.0 Это точно элемент интерфейса?
	Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

	233. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от farewell (ok), 23-Сен-24, 11:22
	Через этот crate можно отрисовать виндовый GUI
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (216), 23-Сен-24, 11:36
	круто 1. таки получается, что это все таки "пачка чего-то там для windows". И оно не только для GUI 2. зачем там виндовый GUI? оно от libdrm зависит и на винде работать не может
	Ответить | Правка | Наверх | Cообщить модератору

	267. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (265), 23-Сен-24, 22:39
	>токсичное Rust-сообщество Все так и есть. >есть чему поучиться в этом плане у ненавистников этого языка программирования. Типичное лицемерие растовщиков "а нас то за що???". Типа когда они тут токсят против другиях ЯП это норм, а их ни-ни.
	Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

	278. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Прохожий (??), 23-Сен-24, 23:17
	Растовики косят языки (всегда называя конкретные аргументы, а не типа вот этого "синтаксис не такой"). Но речь вышла шла не о языках, всё же.
	Ответить | Правка | Наверх | Cообщить модератору

	258. Скрыто модератором	+/–
	Сообщение от Аноним (-), 23-Сен-24, 17:07
	Аллилуя! Фрактал столько времени критиковавший чистый Си, и расхваливавший Раст, теперь критично отзывается о Расте! Духи открыли Фракталу глаза на реальность. Теперь, быть может он полюбит чистый Си и отвергнет Си плюс-плюс!
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

15. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
Сообщение от n00by (ok), 22-Сен-24, 10:06
6% производительность вроде бы немного -- такую разницу иногда можно получить, просто сменив транслятор. Но это потеря на обёртке над оптимизированным асмом. Если в первом приближении принять, что работа обёртки занимает 10% времени, то получается новый код медленнее на 60%?
Ответить | Правка | Наверх | Cообщить модератору

	207. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Андрей (??), 23-Сен-24, 08:12
	тут главный вопрос - зачем ? Ибо во-первых 20 человекомесяцев это дофига, а во-вторых - зачем это нужно, если AV1 на расте уже был и называется на 80% также "rav1e", причём ещё и находится в репозиториях "xiph", т.е. той же тусовки, что развивает ogg и пр.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от n00by (ok), 23-Сен-24, 09:20
	Этот вопрос сложнее, чем прикинуть цифры. Если с POSIX-утилитами очевидно -- меняют лицензию и уходят от GNU, то тут теряюсь в догадках.
	Ответить | Правка | Наверх | Cообщить модератору

	230. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+2 +/–
	Сообщение от Аноним (-), 23-Сен-24, 10:54
	> тут главный вопрос - зачем ? Странный вопрос. Но еще более странная аргументация, в которой есть собственно ответы)) Вот смотри: rav1e - AV1 encoder. ENCODER. А rav1d это что? AV1 decoder. DECODER. Видишь как просто? А теперь попробуй осознать насколько тупо звучит твое во-вторых - "Зачем же нужен декодер, если у нас уже есть энкодер?" А вообще можно было зайти на страницу проекта, благо ссылка есть прямо в новости, и прочитать его цели. Основные: выкинуть сишку на мороз и при этом использовать тот же асм-код что dav1d и оставить совместимость интерфейсов. - librav1d is designed to be a drop-in replacement for libdav1d - Move dav1d's C code to Rust for memory safety - Reuse the assembly code from dav1d and make it easy to frequently synchronize it
	Ответить | Правка | К родителю #207 | Наверх | Cообщить модератору

18. Скрыто модератором	+3 +/–
Сообщение от Аноним (18), 22-Сен-24, 10:19
А куда можно фичреквест по функционалу сайта отправить. Пора делать отдельную вкладу с названием "что сегодня переписывают и форкают"
Ответить | Правка | Наверх | Cообщить модератору

	23. Скрыто модератором	+1 +/–
	Сообщение от YetAnotherOnanym (ok), 22-Сен-24, 10:43
	Лично Максиму Чиркову, он же mc, ссылка на этой странице внизу справа.
	Ответить | Правка | Наверх | Cообщить модератору

	26. Скрыто модератором	+/–
	Сообщение от Аноним (13), 22-Сен-24, 10:51
	Нет, не надо. А вот бот-идоратор, ИМХО, слишком "злой". Но как говорится, каков хозяин, так и его собака лает! Абырвалг, всем!
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

24. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
Сообщение от Аноним (24), 22-Сен-24, 10:43
> Код posixutils-rs распространяется под лицензией MIT. Опять корпорациям помогают.
Ответить | Правка | Наверх | Cообщить модератору

	37. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+2 +/–
	Сообщение от Аноним (37), 22-Сен-24, 12:24
	>> Код posixutils-rs распространяется под лицензией MIT. > Опять неправильным корпорациям помогают. Во-во, а нужно чтоб только у Гугла, Амазона, Клаудфляра и прочих SaaS халява была. Тогда да, тогда наступит светлое гпл-будущее!!!
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (17), 22-Сен-24, 12:27
	То ли дело линукс под жипиель, который разрабатывают корпы. Двойные стандарты - во!
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	52. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (52), 22-Сен-24, 13:53
	Так конечно за них же никто не разработал бзд или мит версию.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Анониссимус (?), 22-Сен-24, 21:42
	Корпы разрабатывают линукс под жипиель --> корпы помогают юзерам Растеры разрабатывают под бздёй --> растеры помогают корпам
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	166. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+2 +/–
	Сообщение от Аноним (166), 22-Сен-24, 23:36
	> растеры помогают корпам ...которые разрабатывают линукс под жипиэль и этим помогают юзерам
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (135), 22-Сен-24, 22:26
	> То ли дело линукс под жипиель, который разрабатывают корпы. Двойные стандарты - во! Расскажи какие корпы dav1d делали? :). И вот GPL кстати помогает конверсии оных в тягловую силу, а не тех кто растаскивает проект по норкам.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	239. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 23-Сен-24, 12:47
	Так dav1d как раз под BSD. Потому что выпускать декодер под гнураком - это нужно быть ну очень особо одаренным. Его же никто использовать не сможет, ни в одну железку не засунешь.
	Ответить | Правка | Наверх | Cообщить модератору

	326. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 24-Сен-24, 20:54
	> Так dav1d как раз под BSD. Ну он и был ни жив ни мертв фиг знает сколько. > Потому что выпускать декодер под гнураком - это нужно быть ну очень особо одаренным. Ну вот именно декодер - таки, пожалуй, да. > Его же никто использовать не сможет, ни в одну железку не засунешь. Крутая идея - устроить халяву железячникам, получив с них - фигу. Впрочем они могут просто взять модуль HW декодера так то.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (75), 22-Сен-24, 15:09
	Ты наверное не в курсе, что 90% ядра пилят программисты на зарплатах в корпорациях, а не Вася Пупкин из Усть-Подпивасинска???
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	79. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+2 +/–
	Сообщение от Аноним (79), 22-Сен-24, 15:32
	Они и пилят благодаря гпл. Или почему ты думаешь они фряху не пилят подумай на досуге.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (135), 22-Сен-24, 22:27
	> Они и пилят благодаря гпл. Или почему ты думаешь они фряху не > пилят подумай на досуге. Вон там success story от всяких ластиков и редисок - как корпы у них нашару надергали кода, вернули фигу - все еще хотите им пермиссивную халяву устраивать? :)
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (79), 23-Сен-24, 08:01
	Отличный пример вреда лицензий bsd и apache для своих авторов.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (166), 22-Сен-24, 23:38
	> Или почему ты думаешь они фряху не пилят Кроме лицензий есть ещё модели разработки
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	200. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (79), 23-Сен-24, 08:02
	Модель разработки меняется в зависимости от задач и не выбита в камне.
	Ответить | Правка | Наверх | Cообщить модератору

	226. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Советский инженер (ok), 23-Сен-24, 10:33
	>Или почему ты думаешь они фряху не пилят подумай на досуге. фряху не пилят, а LLVM пилят. LLVM не маленький проект. почему так? подумай на досуге.
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	240. Скрыто модератором	+/–
	Сообщение от Аноним (-), 23-Сен-24, 12:49
	> почему так? подумай на досуге. Ставлю на то, что LLVM нужен. А фряха - нинужна)) Вот поэтому одно активно пилят, а другое гниет под забором.
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (242), 23-Сен-24, 12:57
	Потому что на зарплате или на прикорме у Яббла. И нужно, в первую очередь, огрызку.
	Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

	321. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (5), 24-Сен-24, 20:08
	потому что нужно подсадить всех на подконтрольный корпорастам llvm с несвободной лицензией, после чего закрутить гайки и грести бабло лопатой
	Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

	373. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Incorporated (?), 01-Окт-24, 10:24
	>почему ты думаешь они фряху не пилят Кто сказал? MacOS X целый напилили
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

25. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+7 +/–
Сообщение от Аноним (36), 22-Сен-24, 10:46
> rav1d > написанный на языке Rust. Assembly 65.3% Rust 17.1% C 16.1%
Ответить | Правка | Наверх | Cообщить модератору

	29. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Я (??), 22-Сен-24, 11:26
	на 17.1% безопаснее по памяти и лучше алгоритмы, чем остальные
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+3 +/–
	Сообщение от Аноним (79), 22-Сен-24, 12:11
	В чем безопасТность заключается в ансейф блоках?
	Ответить | Правка | Наверх | Cообщить модератору

Часть нити удалена модератором

	42. Скрыто модератором	+4 +/–
	Сообщение от Аноним (79), 22-Сен-24, 12:32
	Ты там явно никогда не был раз так рассуждаешь.
	Ответить | Правка | К родителю #373 | Наверх | Cообщить модератору

	140. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–2 +/–
	Сообщение от Прохожий (??), 22-Сен-24, 22:38
	В том, что они выделены этим самым unsafe. То есть, их сразу видно.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	174. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+2 +/–
	Сообщение от мяв (?), 23-Сен-24, 00:23
	когда весь проект - сплошной unsafe-блок, смысла в этом маловато :) суть их в том, чтобы пару раз заморочиться, описать условия применения, а потом в safe-коде их зафорсить. и дергать уже безопасное апи. но в кодеке, очевидно, никто таким заниматься не будет из за требуемой скорости. следовательно, толку с раста в нем - ноль.
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (79), 23-Сен-24, 08:03
	Недоброжелатель всегда может в ансейф блок внедрить небезопасный код. И никто этого не найдет.
	Ответить | Правка | Наверх | Cообщить модератору

	279. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Прохожий (??), 23-Сен-24, 23:19
	Я думаю, это будет продолжаться до тех пор, пока будут внешние зависимости от библиотек на других языках. Как только и эти библиотеки перепишут, количество unsafe-блоков заметно поуменьшится. Кроме того, будет довольно просто заменять unsafe, на обычный код, потому что, как я уже выше заметил, такие блоки сразу видны, их легко искать.
	Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

	293. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 24-Сен-24, 00:49
	что изменится? должно быть так: unsafe -> абстракция -> safe. а имеем черт-те что. и если Вы unsafe из extern'ов передвините в unsafe-блоки, это будет не более, чем перестановка кроватей.
	Ответить | Правка | Наверх | Cообщить модератору

	374. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Incorporated (?), 01-Окт-24, 10:36
	В случае с растом можно провести аудит кода и СРАЗУ оценить риски по наличию unsafe. В с++ и с это невозможно по определению. Энтерпрайз сегмент уже давно подвинул сишников из своих масштабных проектов, набрал жаберов и получает баизнес-результат, а не черную дыру затрат на разработку и ловлю багов.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (79), 23-Сен-24, 08:02
	Это как жёлтая ленточка безопасности в ней нуль и всем на неё плевать.
	Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

	192. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (192), 23-Сен-24, 03:56
	В том, что ты новость непонятно как читаешь. Особенно сложно для тебя понять то место, где написано: "...прошлый опыт выявления уязвимостей в декодировщиках видео показывает, что проблемы в основном возникают в высокоуровневом коде разбора формата, а не в низкоуровневых операциях с данными...", а перед этим - "базовые функции декодирования примитивных значений реализованы на ассемблере в виде unsafe-блоков (задействован ассемблерный код из dav1d)". Разжую - в сейф-режиме переписано то, в чем в основном возникали проблемы. Если и сейчас не понял - проходи мимо, дорогой, здоровья тебе и попутного ветра в спину. Что-то я слишком требователен к растохейтерам. Они обычно с логикой не дружат, зато у них чувство прекрасного чрезмерно развито и спать мешает - "ужасный растовский синтаксис" в кошмарах снится.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	211. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Андрей (??), 23-Сен-24, 08:18
	Во-первых есть более каноничный для rav1e, который более растоманский, чем данный протест против здравого смысла с очередным переписыванием сишного софта, а во-вторых не на 17%, а на куда меньше, ибо распределение потенциальных ошибок для упомянутых языков не пропорционально доле кода, так например в ассемблере вообще могут не выделять память, а только обрабатывать, да и не очевидно какая доля работы с памятью осталась на си, а какая перетекла и стала "безопаснее" на расте.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	281. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Прохожий (??), 23-Сен-24, 23:33
	Во-первых, rav1e - это ENCODER, тогда как rav1d - DECODER.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (37), 22-Сен-24, 12:43
	> Assembly 65.3% > Rust 17.1% > C 16.1% То ли дело > dav1d > написанный на языке Си. > Assembly 79.8% > C 19.7%
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	45. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (45), 22-Сен-24, 12:52
	> То ли дело >> dav1d >> написанный на языке Си. Пруфы будут?
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (37), 22-Сен-24, 20:29
	> Пруфы будут? Пруфы чего тебе нужны, дорогой? Посмотри в код что ли, ну или открой какую нибудь новость о dav1d: > Код проекта написан на языке C (C99) >
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от commiethebeastie (ok), 22-Сен-24, 13:37
	.v_w8_loop:     vpbroadcastq        xm1, [srcq+ssq*1]     lea                srcq, [srcq+ssq*2]     vpblendd            xm2, xm1, xm0, 0x03 ; 0 1     vpbroadcastq        xm0, [srcq+ssq*0]     vpblendd            xm1, xm1, xm0, 0x0c ; 1 2     punpcklbw           xm3, xm1, xm2     punpckhbw           xm1, xm2     pmaddubsw           xm3, xm6     pmaddubsw           xm1, xm6     pmulhrsw            xm3, xm7     pmulhrsw            xm1, xm7     packuswb            xm3, xm1     movq       [dstq+dsq*0], xm3     movhps     [dstq+dsq*1], xm3     lea                dstq, [dstq+dsq*2]     sub                  hd, 2     jg .v_w8_loop     RET Нахера и зачем, когда это делается интринсиками?
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	58. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (45), 22-Сен-24, 14:15
	> это делается интринсиками Для какого компилятора и какой версии? Скорее всего асм-код генерируют (закрытой тулзой из закрытых исходников). Щас бы нетривиальные алгоритмы писать на асме миллионами строк кода.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (93), 22-Сен-24, 17:08
	Это ты ещё скажи спасибо что этот асм код не из проприетари выдрали.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от n00by (ok), 23-Сен-24, 09:37
	>     RET > Нахера и зачем, когда это делается интринсиками? Что бы помешать транслятору заинлайнить, очевидно.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

28. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+5 +/–
Сообщение от мяв (?), 22-Сен-24, 11:18
зачем оно надо, если rust - не в POSIX? было б куда интереснее увидеть это все на с99.
Ответить | Правка | Наверх | Cообщить модератору

	32. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Rust Foundation (?), 22-Сен-24, 11:52
	> rust - не в POSIX Это досадное недоразумение. Скоро исправим.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (79), 22-Сен-24, 12:12
	Каким образом?
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (75), 22-Сен-24, 15:07
	Твой posix давно почил в бозе так же как и вся идеология юникс. Один только сустемд чего стоит.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	85. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 22-Сен-24, 15:54
	> Твой posix давно почил в бозе так же как и вся идеология юникс. Один только сустемд чего стоит. POSIX как таковой ортогонален идеологиям unix и прочим systemd.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 22-Сен-24, 23:54
	все, кому нужно написать портабельный софт, как в соответствии со стандартом писали, так и пишут. ибо альтернатив в этом поле нет.
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	86. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (86), 22-Сен-24, 16:16
	>зачем оно надо? наверное для Redox'а это надо, чтобы была POSIX-совместимость.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	169. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 22-Сен-24, 23:56
	хм.. ну если они прослойку сделают, то, может, оно даже жить будет. вон, как в fuchsia
	Ответить | Правка | Наверх | Cообщить модератору

	322. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (5), 24-Сен-24, 20:10
	скорее для винды
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

31. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
Сообщение от Аноним (31), 22-Сен-24, 11:49
То есть, они переписали их на rust не один раз, а два?
Ответить | Правка | Наверх | Cообщить модератору

	41. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (17), 22-Сен-24, 12:29
	Кто они? Это две разных команды людей.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+2 +/–
	Сообщение от Аноним (79), 22-Сен-24, 12:33
	Задачка сколько раз две разных команды людей перепишут один и тот же код.
	Ответить | Правка | Наверх | Cообщить модератору

	268. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (265), 23-Сен-24, 22:46
	Задачка со звездочкой - во сколько раз при этом повысится безопасность.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (37), 22-Сен-24, 18:29
	> То есть, они переписали их на rust не один раз, а два? А сколько раз будет с учетом bsdutils, gnu coreutils, toybox, busybox, sbase? Хотя не, это ведь си, значит другое!
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	188. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аниним (?), 23-Сен-24, 01:49
	А почему бы и нет? Тебе-то что?
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	246. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от freehck (ok), 23-Сен-24, 14:10
	> То есть, они переписали их на rust не один раз, а два? Да нет, побольше уже. Это как минимум третья попытка. О предыдущих двух на опеннете уже писали, можете поискать.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

35. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
Сообщение от Аноним (35), 22-Сен-24, 12:12
>и компилятора c99 Ну всё, теперь и компилятор си перепишут на расте!
Ответить | Правка | Наверх | Cообщить модератору

	53. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (52), 22-Сен-24, 13:55
	А безопасно нет будет.
	Ответить | Правка | Наверх | Cообщить модератору

48. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
Сообщение от Аноним (48), 22-Сен-24, 13:27
За пару месяцев освоил раст более или менее. Пилю на нем проект, пока написал около 5к строк всего. Очень мне нравится язык и экосистема. Недостатков в языке я особо не заметил, а вот в среде разработки они есть пока что, но не сильные. В итоге все очень нравится, свои проекты хоббийные я только на нем пилить далее буду, он прям хорошо подходит.
Ответить | Правка | Наверх | Cообщить модератору

	70. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+6 +/–
	Сообщение от Аноним (75), 22-Сен-24, 15:04
	> 5к строк всего Ничоси "всего". Большинство любителей шлепать формочки и прочие джаваскриптеры такого за всю жизнь не пишут.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–6 +/–
	Сообщение от Аноним (7), 22-Сен-24, 17:20
	Откуда такие познания? Я просто напомню тебе, что это 5KLOC. Средний проект _начинающих_ любителей клепать формочки и джаваскриптеров в 10-20 раз больше (считая только собственный код ессно). Это буквально проект уровня привет мир. Справедливости ради, мои привет миры на расте в пределах 1000 строк. Мои сишные привет миры были на десятки тысяч строк. Ну, тут главное не задумываться о низкой эффективности разработки с растом (и последующей необходимости переписывать всё на плюсы). Некоторые утилиты вполне неплохо себя ощущают и на расте, если забыть про высокую ресрсоёмкость и странные проблемы с тулчейном. Главное тут, чтобы было приятно использовать и обновлять компоненты.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+3 +/–
	Сообщение от zk (?), 22-Сен-24, 18:18
	Это хело ворлд на 1000 строк? Врешь собака, код в студию!
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–5 +/–
	Сообщение от Аноним (7), 22-Сен-24, 18:33
	Моя первая программа (самая первая) использовала curl с openssl, libxml2 и pcre2, висела в кроне и буквально печатала строку в лог в зависимости от ситуации. Плюс разбор аргументов, вывод сообщений и код, чтобы не падала в минимально нештатных ситуациях. Это уже тысячи строк. Ты какой-то странный.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (7), 22-Сен-24, 18:41
	Кстати, ознакомься с gnu hello.
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

	111. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (111), 22-Сен-24, 18:56
	Коммент дня! :D
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (7), 22-Сен-24, 20:54
	Не уверен, что ты хотел этим сообщить, но вот то, что местные писатели операционок в последний раз видели си в школе (и то, это был какой-нибудь борланд, с реальным общего имеющий достаточно мало), вполне вероятно. Им не помешало бы освежить в памяти, что такое си, и как он выглядит.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Прохожий (??), 22-Сен-24, 23:06
	С давным-давно морально устаревшим языком программирования Си интересно ознакамливаться разве что антропологам каким.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Проходил мимо (?), 23-Сен-24, 07:43
	Вот не надо про "морально устаревший" и про антропологов. Всякому языку свое место, есть оно и у Си, и у Раста. Пусть цветут все цветы.
	Ответить | Правка | Наверх | Cообщить модератору

	227. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (-), 23-Сен-24, 10:35
	> Всякому языку свое место Абсолютно верно! Напр. место на свалке истории. Или в клубах по интересам, как это происходит с ретрожелезом или ретроавто. Но не на миллионах серверов и миллиардах смартфонов.
	Ответить | Правка | Наверх | Cообщить модератору

	280. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Прохожий (??), 23-Сен-24, 23:28
	Почему ж не надо? Эти языки объективно не справляются с многократно возросшей сложностью ПО. Об этом все говорят, кто сколь-либо находится в теме. Понятно, что переучиваться - это огромная когнитивная нагрузка, особенно, когда речь идёт о языке, который намного более сложный, чем тот же Си (но при этом гораздо проще Плюсов), поэтому люди и сопротивляются, как могут. Иной раз Раст может действительно привнести временные неудобства в крупный проект, как в тот же Линукс. Но, к примеру, Гугл, нашёл выход, как с этим справляться (Андроид). Не вижу причин, почему другие не могут так же. Я не хочу сказать, что у языка Раст нет недостатков. Они есть, и хорошо известны тем, кто в теме. Но, увы, на этом форуме реальных аргументов, критикующих эти недостатки, до сих пор не встречалось. Обычно всё скатывается в "плохой синтаксис", дальше этого дело не идёт.
	Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

	299. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Проходил мимо (?), 24-Сен-24, 07:31
	Уважаемый Прохожий, лично по моим ощущениям Rust намного превосходит по сложности C++ и другие языки. Проблемы же с Си возникают практически только в больших проектах, где невозможно удержать все в голове. Когда кода не очень много и когда его изначально пишут с упором на безопасность результат получается очень хорошим. Поэтому я уверен, что чистый Си был, есть и будет в тех областях, где нужно относительно немного очень быстрого и компактного кода. Что касается Rust - лично у меня к самому языку есть претензия только в очень неудачном, на мой взгляд, синтаксисе указания времени жизни. А вот к его стандартной библиотеке претензий накопилось уже довольно много. Наверное это происходит потому, что в отличии от большинства хаящих Rust икспердов с OpenNET, я на нем время от времени реально что-то пишу :) Чтобы не быть голословным, приведу одну из них. У BufReader есть метод lines(), который позволяет удобно проводить итерацию по строкам. И все бы ничего, но если в одной из строк попадется не UTF8 байты (а в реальном мире они туда обязательно попадут, причем, возможно, целенаправленно), вся считанная строка, фигурально говоря, превращается в тыкву. И я так и не нашел возможности получить в обработчике ошибок доступ к ее байтовому слайсу. Т.е. этот очень удобный метод, по факту, оказывается непригодным к использованию в реальных программах, запускаемых в недружественном программном окружении.
	Ответить | Правка | Наверх | Cообщить модератору

	334. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (334), 24-Сен-24, 22:07
	> Что касается Rust - лично у меня к самому языку есть претензия только в очень неудачном, на мой взгляд, синтаксисе указания времени жизни. А что насчёт возможных вариантов условной компиляции? Которая просто необходимо для проектов, живущих десятки лет. Причем обычно уже никто на знает как работает часть кода. Просто не трогают, обкладывая ifdef'ами. Посмотрите на реализацию QTermWidget. Там часть кода выдрана из реализаций для систем прошлого тысячилетия.
	Ответить | Правка | Наверх | Cообщить модератору

	359. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 25-Сен-24, 13:17
	> Уважаемый Прохожий, лично по моим ощущениям Rust намного превосходит по сложности C++ и другие языки. Не, как писать программы на C++ я так и не смог понять. Сколько я не читал литературы и C++ кода, я не понял как это делать. Я так и не понял, к чему там наследование, тем более множественное например. В каких случаях его уместно использовать? Темплиты -- это же ужос, это макроподстановки, а с макроподстановками единственный разумный способ работы -- избегать их всеми способами, потому что когда с ними пойдёт что-то не так, время на разгребание получившегося хаоса превзойдёт время необходимое на то, чтобы копипастом и прочими средствами текстового редактора сделать то же самое, что делается макросами. Раст же я освоил легко и непринуждённо. Были проблемы с тем, что некоторые привычные паттерны программирования там не работают, но эта проблема решалась через нахождение альтернативных паттернов. > Т.е. этот очень удобный метод, по факту, оказывается непригодным к использованию в реальных программах, запускаемых в недружественном программном окружении. В недружественном окружении, если ты получаешь кривой ввод, ты отбрасываешь все уже прочитанные данные, выкидываешь ошибку, и закрываешь файловый дескриптор. Не, ну ты вдумайся, что ты ещё ты моешь сделать с этим кривым вводом, если в нём вместо utf8 ты находишь произвольные байты? И если у тебя есть какая-то разумная стратегия? Вот бери и реализуй эту стратегию. Реализовать свой BufRead не так уж и сложно, и совсем тривиально можно сделать обёртку поверх BufRead. Но я б рекомендовал поискать по crates.io, вероятно там есть что-нибудь типа bufread, но чтобы кодировку менять на ходу. Это для того же http(s) может быть полезно, потому что начинаешь ты его читать как поток ascii, но впоследствии ты вероятно захочешь читать utf8. А если ты ещё и браузер, который унижаться перед серверами и проглатывать абсолютно любые ошибки, то вероятно тебе захочется читать байты, и потом lossy способом перегонять в utf8. Но это позорная старпёрская стратегия, призывающая быть толерантным к нарушениям протоколов со стороны других. Толерантность здесь неуместна, если на том конце программисты не могут реализовать протокол, то пускай идут дворниками работать. Из-за этой дедовской стратегии мы и оказались в сегодняшней ситуации, когда даже для того, чтобы email-адрес распарсить, надо потратить неделю чтения документации и статей описывающих чужой опыт такого парсинга. И эта никому не нужная сложность -- стабильный источник багов и даже зияющих дыр в программах, которые вместо того, чтобы столкнувшись с отклонением от протокола, закрыть файловый дескриптор, начинают плясать с бубном вокруг этого файлового дескриптора и наступают на какие-нибудь грабли. Есть один хороший принцип доставшийся нам от дедов: KISS. Не надо усложнять программу, если нет горящей необходимости её усложнять. До тех пор, пока программа работает без плясок с бубном вокруг не-utf8 ввода, не надо усложнять её до способности работать с не-utf8 вводом. Не надо пытаться своей программой решить все проблемы всего огромного мира. Более того, надо усердно обрыкиваться от попыток других навязать тебе их проблемы и убедить тебя в том, что это твои проблемы. Это им же на пользу пойдёт. Я тут могу привести вполне реальный пример. uutils вваливаются в панику, столкнувшись с не-utf8 именем файла. И благодаря им я нашёл в своём хомяке файлы с koi8-r именами, которые каким-то образом остались откуда-то из +-2005 года, когда я конвертал все имена из koi8-r в utf8. Результат? Я сделал то, что ленился сделать 15 лет: я нашёл все несконвертированные имена, и перекодировал их.
	Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

	365. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Проходил мимо (?), 25-Сен-24, 14:28
	> В недружественном окружении, если ты получаешь кривой ввод, ты отбрасываешь все уже прочитанные данные, выкидываешь ошибку, и закрываешь файловый дескриптор. Не, ну ты вдумайся, что ты ещё ты моешь сделать с этим кривым вводом, если в нём вместо utf8 ты находишь произвольные байты? Кривые байты целенаправленно попадают, например, в прямые логи, которые надо проанализировать. Закрывать лог из-за того, что кто-то целенаправленно внес туда "мину" - это плохая стратегия поведения для анализирующей этот лог программы. Даже просто пропуск строчки, как это легко можно сделать с lines(), является плохой идеей. Кривой ввод нужно сохранить для возможности дальнейшего анализа. Обходные методы этого всего есть, но обидно то, что авторы стандартной библиотеки сразу не сделали по человечески.
	Ответить | Правка | Наверх | Cообщить модератору

	259. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от _ (??), 23-Сен-24, 17:56
	А ещё интереснее смотреть на собачек Павлова от программирования :) Оне тяффкают! :)
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	262. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (-), 23-Сен-24, 18:14
	> А ещё интереснее смотреть на собачек Павлова от программирования :) Оне тяффкают! Хм.. ну так не тяфкай) Никто же тебя не заставляет. (Если тебя взяли в плен и пытают - моргни 2 раза)
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Наноним (?), 22-Сен-24, 18:51
	> Справедливости ради, мои привет миры на расте в пределах 1000 строк. Лет 20 назад я операционку свою писал на Си и она уместилась в чуть менее 300 строк. Могла в менеджмент памяти и даже tcp ip. Что ты там такого нaгoвнoкoдил на 1000 строк?
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	112. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–3 +/–
	Сообщение от Аноним (7), 22-Сен-24, 18:57
	Это как раз дело не хитрое. А ты вот пробовал писать корректный код? Или там хотя бы конкатенировать строки.
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (220), 23-Сен-24, 09:47
	А у меня все программы уместились в одну строку! Правда она довольно длинная...
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	152. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Прохожий (??), 22-Сен-24, 23:03
	> Это буквально проект уровня привет мир. Эту оценку, конечно, нельзя назвать сколь-либо объективной. Потому что кроме собственных 5 тыс. строк может быть задействовано библиотек на 100 тыс. строк. И это уже очень далеко от проекта уровня "Привет, мир".
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	87. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (86), 22-Сен-24, 16:18
	>он прям хорошо подходит а для чего он хорошо подходит, если не секрет?
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	141. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Прохожий (??), 22-Сен-24, 22:44
	Да, в общем, для всего практически, кроме узкоспециализированных областей, конечно (типа запросов к реляционным базам данных, например). Это язык программирования универсального назначения.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (48), 22-Сен-24, 23:03
	У меня два хоббийных проекта. 1. Это один децентрализованный веб сервис. 2. Это транслятор одного вида специализированных текстов в другой.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	165. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (165), 22-Сен-24, 23:34
	Достаточно серьёзные программы
	Ответить | Правка | Наверх | Cообщить модератору

	323. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (5), 24-Сен-24, 20:12
	снимите себе номер
	Ответить | Правка | Наверх | Cообщить модератору

49. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
Сообщение от Аноним (-), 22-Сен-24, 13:28
>Проект сосредоточен главным образом на достижении соответствия требованиям спецификации POSIX.2024 и не планирует обеспечивать совместимость с утилитами GNU Ясно понятно. Враги Свободы.
Ответить | Правка | Наверх | Cообщить модератору

	54. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 22-Сен-24, 14:04
	Тьфу, даже переписать нормально не могут. Казалось бы держи-обводи, слабо связанный код, но нет. Никуда не годится, позор.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (75), 22-Сен-24, 15:10
	Свобода это отсутствие лицензии вообще. В остальном это не свобода, но ТЕ или ИНЫЕ ограничения.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	103. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от zk (?), 22-Сен-24, 18:20
	Свобода противоречивое слово.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (197), 23-Сен-24, 07:59
	Не, если лицензии нет, то код вообще использовать нельзя.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	218. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (-), 23-Сен-24, 09:34
	Копилефт ограничивает самоупроавство и произвол проприетарщиков и прочих копирастов. Это означает свободу для простыч программистов и пользователей.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	234. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (-), 23-Сен-24, 11:25
	> Копилефт ограничивает самоупроавство и произвол проприетарщиков и прочих копирастов. Да, то-то же оно ограничило самоуправство всяких Гуглов, Амазонов и прочих SaaS провайдеров. "облачные провайдеры создают производные коммерческие продукты и занимаются перепродаже в виде облачных сервисов, но не принимают участия в жизни сообщества и не помогают в разработке." > Это означает свободу для простыч программистов и пользователей. Мы же говорим про ЖоПЛь рак который запрещает программисту зарабатывать на продаже кода? Мозолеед в своем манифесте отлично показал свое отношение к программистам, предложениями запретить высокие зарплаты и отправить разработчиков ходить с протянутой рукой. ИЧСХ украсть емакс и продать, ему это не помешало.
	Ответить | Правка | Наверх | Cообщить модератору

	269. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (265), 23-Сен-24, 22:50
	GPL не запрещает программисту зарабатывать на продаже СВОЕГО кода. GPL запрещает программисту зарабатывать на продаже ЧУЖОГО кода.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (220), 23-Сен-24, 09:52
	>Свобода это отсутствие лицензии вообще. Нет, если лицензии нет то по закону вроде все права принадлежат написавшему код. То есть его нельзя использовать никак, только смотреть. Для свободы есть передача в общественное достояние (public domain), но оно существует не везде, поэтому есть всякие лицензии типа CC0 или Unlicense: https://en.wikipedia.org/wiki/Public_domain_equivalent_license
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

61. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
Сообщение от Аноним (-), 22-Сен-24, 14:34
> реализованы на ассемблере в виде unsafe-блоков > (задействован ассемблерный код из dav1d) Вот такое вот хреновое лето^W Rust :D
Ответить | Правка | Наверх | Cообщить модератору

63. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
Сообщение от Аноним (63), 22-Сен-24, 14:35
Спам и DDoS - это превышение полномочий (abuse). Предлагаю перевод всего и вся на rust расмстаривать как аналогичное действие.
Ответить | Правка | Наверх | Cообщить модератору

67. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
Сообщение от Аноним (75), 22-Сен-24, 14:52
Со всеми этими нейросетями могли бы просто сразу переписать в машинные коды. Зачем посредник в лице яп?
Ответить | Правка | Наверх | Cообщить модератору

	241. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от а (?), 23-Сен-24, 12:49
	сразу в машинные коды любой компилятор может, а вот на раст - тут думать надо
	Ответить | Правка | Наверх | Cообщить модератору

	270. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (265), 23-Сен-24, 22:51
	Тогда ЗП получит тоже нейросеть.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

80. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+2 +/–
Сообщение от Аноним (80), 22-Сен-24, 15:32
Опять новость, что на расте что-то ПЕРЕписывают давно и успешно работающее. Это симптомчик, потому что, как по мне, у нормального программиста есть куча идей что свое новое написать. Но видимо с нуля кодить на расте слишком сложно...
Ответить | Правка | Наверх | Cообщить модератору

	99. Скрыто модератором	+/–
	Сообщение от Аноним (37), 22-Сен-24, 17:57
	> Опять новость, что на расте что-то ПЕРЕписывают давно и успешно работающее. > Это симптомчик, потому что, как по мне, у нормального программиста есть куча > идей что свое новое написать. Но видимо с нуля кодить на > сишке слишком сложно... Ты сейчас о чем конкретно, о гнутых корутилитах, базибоксе, тойбоксе или о сибейзе? Туда тоже уже растоманы добрались? 8-O
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+2 +/–
	Сообщение от Продавец (?), 23-Сен-24, 01:58
	Дело не только в этом. Примеры чего-то сложного написанные на расти 10 лет назад сейчас уже не компилятся, и поди ещё там разбери без пол литра что в куске безсмысленного врапа там не нравится новому компилюсу. Я лично не особо по алкахе, наверно по этой причине и забросил адаптироваиь
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	271. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (265), 23-Сен-24, 22:53
	"Зато нет UB" говорили они. Потому что если нет стандарта, то нет и UB.
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (197), 23-Сен-24, 08:01
	Это проблема тех, кто постит новости, а не раста. Например, про Nushell я на опеннете вообще ниразу не видел, а это - самый крутой шелл и язык программирования на замену баша и его выпускают уже несколько лет.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	222. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (222), 23-Сен-24, 09:53
	> Например, про Nushell я на опеннете вообще ниразу не видел, А это https://www.opennet.dev/51375-shell что?
	Ответить | Правка | Наверх | Cообщить модератору

	298. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (197), 24-Сен-24, 05:30
	Один раз 5 лет назад? О чём и речь. Зато про переписывание каких-то утилит постоянно сообщают.
	Ответить | Правка | Наверх | Cообщить модератору

82. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
Сообщение от Аноним (82), 22-Сен-24, 15:33
Разве они уже не переписаны на zig?
Ответить | Правка | Наверх | Cообщить модератору

	190. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Продавец (?), 23-Сен-24, 01:59
	Ну допустим, и что?
	Ответить | Правка | Наверх | Cообщить модератору

83. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
Сообщение от Аноним (83), 22-Сен-24, 15:48
>Дополнительно можно отметить анонс проекта rav1d, развивающего высокопроизводительный декодировщик формата кодирования видео AV1, написанный на языке Rust. Разработка ведётся через портирование на Rust кода декодировщика библиотеки dav1d, отличающейся высокой производительностью Отлично, как допишут - можно будет обратно на си переписать. Будет безопасно: всё проверено растовым borrow-checkerом.
Ответить | Правка | Наверх | Cообщить модератору

	114. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 22-Сен-24, 19:03
	> Отлично, как допишут - можно будет обратно на си переписать. Будет безопасно: > всё проверено растовым borrow-checkerом. Сиплюсплюсеры в соседней новости уже о чем-то догадываются :)
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 22-Сен-24, 23:28
	> Отлично, как допишут - можно будет обратно на си переписать. Будет безопасно: всё проверено растовым borrow-checkerом. Было бы интересно посмотреть. И посчитать сколько CVE средний сишник модет сделать, при переписывании готового кода)
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	191. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Продавец (?), 23-Сен-24, 02:00
	Ну посмотри если интересно
	Ответить | Правка | Наверх | Cообщить модератору

	272. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (265), 23-Сен-24, 22:57
	Интересно, сколько при этом исправит, ведь CVE это не только ошибки памяти и гарантий от них Раст не дает. https://github.com/Speykious/cve-rs
	Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

89. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
Сообщение от Аноним (86), 22-Сен-24, 16:27
интересная фраза - "проблемы в основном возникают в высокоуровневом коде разбора формата, а не в низкоуровневых операциях с данными". Получается, что низкоуровневые язык ассемблера и С гораздо надёжнее высокоуровневых языков?
Ответить | Правка | Наверх | Cообщить модератору

	90. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (7), 22-Сен-24, 16:52
	>язык ассемблера и С Тоже высокоуровневые. Это всего лишь означает, что проблемы в основном возникают в высокоуровневом коде разбора формата, а не в низкоуровневых операциях с данными.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (79), 23-Сен-24, 08:11
	Просто в низкоуровневом коде проблем никто найти не смог.
	Ответить | Правка | Наверх | Cообщить модератору

	249. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (249), 23-Сен-24, 14:52
	> Тоже высокоуровневые. Только C.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	252. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (7), 23-Сен-24, 16:02
	Макроассемблеры довольно высокоуровневые. Но и современные наборы инструкций процессоров тоже, сложно сравнивать с программированием, как оно выглядело раньше.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–3 +/–
	Сообщение от Аноним (-), 22-Сен-24, 16:53
	> Получается, что низкоуровневые язык ассемблера и С гораздо надёжнее высокоуровневых языков? Нет. Просто намного реже ошибка совершается в функции "перемножить две матрицы", чем в "пришел пакет хз откуда, давайте его парсить не проверяя входные параметры". Хотя сишники даже сплит строки умудряются с CVE сделать.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	108. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Наноним (?), 22-Сен-24, 18:46
	От квалификации зависит. Понятие надёжность слишком расплывчатое.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	148. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–3 +/–
	Сообщение от Прохожий (??), 22-Сен-24, 23:01
	Не всё зависит от квалификации. Часто надёжность зависит от используемых инструментов, потому что человеческий мозг не может не ошибаться, каким бы квалифицированным не был его носитель.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (79), 23-Сен-24, 08:13
	Инструмент никогда не может гарантировать безопасность. Это как безопасная бензопила, концептуальна невозможна.
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 23-Сен-24, 13:04
	Но может ее существенно улучшить. Например в упомянутой бензопиле есть кнопка-стопор, которую нужно выжимать, чтобы она работала. Отпустил - сработал цепной тормоз. Плюс вторая рукоятка, которая тормозит пилу при обратном ударе. И это еще не все! Для работы нужны щиток и наушники, а если дело происходит в местах, где человеческая жизнь ценится - то еще и специальные защитные костюмы от порезов (EN 381 или аналог). Но такое конечно только для профи.
	Ответить | Правка | Наверх | Cообщить модератору

	273. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (265), 23-Сен-24, 23:00
	Можно и маникюр в бронекостюме делать, а то вдруг пилочкой уколешся.
	Ответить | Правка | Наверх | Cообщить модератору

	282. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Прохожий (??), 23-Сен-24, 23:37
	Если палочка отравлена смертельным ядом - вполне разумно. Хотя речь не о маникюре в таком случае будет идти, разумеется.
	Ответить | Правка | Наверх | Cообщить модератору

	307. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 24-Сен-24, 16:23
	> а то вдруг пилочкой уколешся. Разумеется)) А еще можно требовать нормальной стерилизации инструментов. Кто ценит свое здоровье и свою жизнь. Не всем же нравится делать маникюр или тату  в какой-то рыгаловке, где инструмент в лучшем случаем помоют под краном после предыдущего клиента. Ну а ты можешь продолжать))
	Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

	170. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–3 +/–
	Сообщение от Аноним (-), 23-Сен-24, 00:00
	> От квалификации зависит. Не только. Инструмент тоже решает. Вот в ядре линукс есть некий Theodore Ts'o, который лабает ext4. Пишет линукс с 90х. Просто море опыта у кадра. И что? В 2013 году он закоммитил вот такую портянку github.com/torvalds/linux/commit/dc6982ff4db1f47da73b1967ef5302d6721e5b95. Через 9 лет (2022 год) тысячи глаз наконец-то рассмотрели там уязвимость CVE-2022-1184. Которую смогли исправить только со второй попытки. > Понятие надёжность слишком расплывчатое. Разумеется. Но назвать кучу повторяющих из года в год однотипных дыреней нельзя назвать надежность ни в какой ситуации))
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	303. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Серб (ok), 24-Сен-24, 13:37
	> Через 9 лет (2022 год) тысячи глаз наконец-то рассмотрели там уязвимость CVE-2022-1184. Зачем ты с этим CVE везде носишься? Там был код, который рассчитывал на правильные данные в описании каталога. Если данные повреждались где либо на стороне, то могли перезаписаться другие блоки и потом было двойное освобождение. Добавили проверку на правильность данных перед добавлением новых блоков. К чему ты это привел? В расте нельзя считать данные с файла и не проверить их достоверность?
	Ответить | Правка | Наверх | Cообщить модератору

	309. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (-), 24-Сен-24, 16:59
	> К чему ты это привел? Это прекрасный пример отличной квалификации ядрописак и шикарных инструментов. Просто близкий к эталону. Таких примеров конечно море, но именно Тсэ один из тех, кто копротивляется внедрению раста и заявил "вы не заставите учить раст". Хотя он шикарный сишник и какой-то анон кидал список его CVE за последние пару лет. И там типичные сишные дырени - use-after-free, выход за границы буфера, double free, переполнение. > В расте нельзя считать данные с файла и не проверить их достоверность? Разумеется можно. А вот что будет дальше - вопрос)) Вот будет ли use-after-free, а?
	Ответить | Правка | Наверх | Cообщить модератору

	314. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Серб (ok), 24-Сен-24, 18:30
	>> К чему ты это привел? > Это прекрасный пример отличной квалификации ядрописак и шикарных инструментов. Просто > близкий к эталону. > Таких примеров конечно море, но именно Тсэ один из тех, кто копротивляется > внедрению раста и заявил "вы не заставите учить раст". > Хотя он шикарный сишник и какой-то анон кидал список его CVE за > последние пару лет. > И там типичные сишные дырени - use-after-free, выход за границы буфера, double > free, переполнение. И таки да. Он является отличным примером. Его слушают и слышат. В отличии от тебя. >> В расте нельзя считать данные с файла и не проверить их достоверность? > Разумеется можно. А вот что будет дальше - вопрос)) > Вот будет ли use-after-free, а? В расте можно хранить данные и и макроданные описывающие эти данные отдельно? В разных коллекциях? Что произойдет, когда макроданные будут показывать одно а данные будут другими? Паника? И чем паника в ядре лучше use-after-free?
	Ответить | Правка | Наверх | Cообщить модератору

	316. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 24-Сен-24, 18:34
	> Что произойдет, когда макроданные будут показывать одно а данные будут другими? Паника? > И чем паника в ядре лучше use-after-free? Тем что у тебя просто упадет ядро. И это будет видно! И ты увидишь трейс и возможно починишь. А не "у нас тут 10 лет жил бекдор, с получением рута.. всем конечно было плевать". Явная проблема всегда лучше, чем неявная.
	Ответить | Правка | Наверх | Cообщить модератору

	327. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (334), 24-Сен-24, 20:54
	> Явная проблема всегда лучше, чем неявная. А чего она вдруг явная? Для ее срабатывания надо заранее сформировать файловую системы с кривыми данными. Кто и когда это сделает?
	Ответить | Правка | Наверх | Cообщить модератору

	319. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (319), 24-Сен-24, 18:57
	> Он является отличным примером Необучаемого и не хотящего учиться? Который годами повторяет одни и те же ошибки? И в состоянии только давить авторитетом? Да, он отличный пример)) Именно поэтому его и привел. > Его слушают и слышат. А это мы еще посмотрим, т.к. история пока не закончилась. Сейчас придет лесник и поставит на место зарвавшегося дида. Незаменимых людей нет. > И чем паника в ядре лучше use-after-free? Там выше уже ответили, но и я повторюсь. Чтобы не заметить панику нужно очень-очень постараться. Это будет явная проблема. Более того, в логе должно будет указано что и где запаниковало. А так у вас уязвимости живут годами (вот эта - 9 лет) и никто ничего не видел))
	Ответить | Правка | К родителю #314 | Наверх | Cообщить модератору

	328. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (334), 24-Сен-24, 20:58
	> Необучаемого и не хотящего учиться? Поэтому он и разработал файловые системы? > Который годами повторяет одни и те же ошибки? А те кто на расте пишут делают каждый раз разные? > И в состоянии только давить авторитетом? А вот это только ваше вранье. Он в состоянии разрабатывать, в отличии от. > Да, он отличный пример)) Именно поэтому его и привел. И только делает ему рекламу. Ибо ваша некомпетентность великолепный пример того, с чем он борется. > Чтобы не заметить панику нужно очень-очень постараться. Это будет явная проблема. > Более того, в логе должно будет указано что и где запаниковало. > А так у вас уязвимости живут годами (вот эта - 9 лет) и никто ничего не видел)) Не будет лога. Файловая система отвалится. Да и будет это где и когда захочет атакующий.
	Ответить | Правка | Наверх | Cообщить модератору

	329. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 24-Сен-24, 21:08
	> А те кто на расте пишут делают каждый раз разные? Обычно да, потому чаще всего это логические ошибки. Но сейчас, к сожалению, еще не изобрели простого способа верификации кода. Как только это сделают - раст можно и нужно будет закапывать, т.к. новый язык будет на голову его выше. > А вот это только ваше вранье. Он в состоянии разрабатывать, в отличии от. Угу, и мы видим его послужной список CVE. > Ибо ваша некомпетентность великолепный пример того, с чем он борется. А он с чем-то борется? Ну, кроме теплого местечка. Он за все эти годы не в состоянии перестать делать ошибки с памятью) Отличная реклама! > Не будет лога. Файловая система отвалится. Да ну)) А у вас всегда одна единственная ФС? Да неужели?) Или несколько? И она волшебнейшим образом совпала с той, куда пишутся логи? Вот вы так можете это гарантировать?
	Ответить | Правка | Наверх | Cообщить модератору

	330. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (334), 24-Сен-24, 21:47
	> Обычно да, потому чаще всего это логические ошибки. Шедевр. Каждый раз разные ошибки. Вы столько не придумаете. Некомпетентность во всей красе. > Угу, и мы видим его послужной список CVE. Ничего не значащий побочный эффект реального послужного списка. Как пример. Для разработки фс важно что бы она заработала. Искать и ликвидировать CVE можно уже после. Неработающая фс без CVE никому не нужна. > А он с чем-то борется? Ну, кроме теплого местечка. С религиозными фанатиками. Условную ограниченную безопасность ставят выше работоспособности. > Он за все эти годы не в состоянии перестать делать ошибки с памятью) > Отличная реклама! Именно. Ибо фанатики ищущие проблему так где ее нет - прекрасная иллюстрация проблемы религиозного фанатизма. > Да ну)) А у вас всегда одна единственная ФС? Да неужели?) Или несколько? И она волшебнейшим образом совпала с той, куда пишутся логи? Вот вы так можете это гарантировать? Какие логи при панике? Стеки поломаны. Попытка записать что-либо может привести к порче еще сохранившихся данных. Вы вообще хоть один драйвер в жизни отлаживали?
	Ответить | Правка | Наверх | Cообщить модератору

115. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+2 +/–
Сообщение от Вы забыли заполнить поле Name (?), 22-Сен-24, 19:11
> В настоящее время 55 развиваемых проектом утилит соответствуют POSIX и находятся на стадии покрытия тестами, в 22 утилитах обеспечена необходимая функциональность (но пока не реализовано покрытие тестами), 20 находятся на стадии чернового варианта, а работа над 44 утилитами ещё не начата. И эти люди в ядро лезут...
Ответить | Правка | Наверх | Cообщить модератору

	163. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–2 +/–
	Сообщение от Аноним (-), 22-Сен-24, 23:30
	> И эти люди в ядро лезут... ̶Н̶у̶р̶г̶а̶л̶и̶е̶в̶ Торвальдс разрешил (с) И вообще, разве кого-то нужно спрашивать куда можна лезть или нет? Ядро это помойка, в которой даже базовый менеджмент памяти без ошибок сделать не смогли. Бедный Линус в прошлом интервью жаловался.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 23-Сен-24, 00:13
	> Ядро это помойка, в которой даже базовый менеджмент памяти без ошибок сделать > не смогли. > Бедный Линус в прошлом интервью жаловался. Вопрос остается. Ну и зачем тогда лезть туда?) Взяли бы да рядом сделали как надо. Но видимо есть нюанс...
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 23-Сен-24, 07:50
	так делают ведь. вон, есть монолитная kerla. очень даже ничего, как по мне. проект развивается, заинтересованные есть. если б мне были интересны ядрописание с растом, скорее всего, тоже б туда пошла. хотя, черт его знает, как они код там пишут, прошлась только беглым взглядом.
	Ответить | Правка | Наверх | Cообщить модератору

	228. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (228), 23-Сен-24, 10:42
	> Вопрос остается. Ну и зачем тогда лезть туда?) Может людям не нравится когда намусарено и нарыгано, вот они решили убраться. Ядро же в куче мест используется, значит надо его сделать лучше. Я понимаю что есть индивиды которым жить в овне и сраче нормально, но не все люди такие. > Взяли бы да рядом сделали как надо. Но видимо есть нюанс... Так деляют. Вот тут чел в одиночку пилит ядро opennet.ru/opennews/art.shtml?num=60391 И результат, как для одиночки, весьма достойный "реализован 31% (135 из 437) системных вызовов Linux, чего достаточно для загрузки консольного окружения на базе bash и стандартной Си-библиотеки Musl". И редокс тоже пилится, причем у него просто тонна своих низкоуроневых и не очень штук. Свой бутлоадер, relibc, init (а линуксятникам кормят системмд с лопаты), свои binutils, uutils и еще куча других низкоуровневых вещей. А еще графический тулкит и оболочка на нем, шелл, пакетный менеджер, сетевой стек, аудио... Но запретить приходить и улучшать ядро вы никак не можете. Так что продолжайте копротивляться и ныть))
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

	290. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+2 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 24-Сен-24, 00:14
	>> Вопрос остается. Ну и зачем тогда лезть туда?) > Может людям не нравится когда намусарено и нарыгано, вот они решили убраться. Сильные утверждения. Но проверять я их, конечно, не буду (с). >> Взяли бы да рядом сделали как надо. Но видимо есть нюанс... > Так деляют. > Вот тут чел в одиночку пилит ядро opennet.ru/opennews/art.shtml?num=60391 > И результат, как для одиночки, весьма достойный "реализован 31% (135 из 437) > системных вызовов Linux, чего достаточно для загрузки консольного окружения на базе > bash и стандартной Си-библиотеки Musl". Ну Дрю Деволт тоже ядро написал на hare и дальше что? Какое отношение эти огрызки имеют к рабочему ядру? > И редокс тоже пилится, причем у него просто тонна своих низкоуроневых и > не очень штук. > Свой бутлоадер, relibc, init (а линуксятникам кормят системмд с лопаты), > свои binutils, uutils и еще куча других низкоуровневых вещей. > А еще графический тулкит и оболочка на нем, шелл, пакетный менеджер, сетевой > стек, аудио... Пишешь из под редокса? Пользуешься чем-то из перечисленного. Сомневаюсь. > Но запретить приходить и улучшать ядро вы никак не можете. > Так что продолжайте копротивляться и ныть)) По твоей манере речи видно, что ты привык сидеть на всем готовом и жаловаться. И судя по комментариями - это типичные фанбои раста.
	Ответить | Правка | Наверх | Cообщить модератору

	231. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–2 +/–
	Сообщение от Советский инженер (ok), 23-Сен-24, 10:58
	>Но видимо есть нюанс... нюанс в том, что платиновые, золотые и прочие спонсоры линукс фундейшон уже потратились на сотни миллионов денег и не желают тратится вновь. Поэтому они продолжат внедрять в ядро тот функционал, какой им надо, невзирая на всхлипывания всяких непонятных экспертов.
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

	291. Скрыто модератором	+3 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 24-Сен-24, 00:15
	>>Но видимо есть нюанс... > нюанс в том, что платиновые, золотые и прочие спонсоры линукс фундейшон уже > потратились на сотни миллионов денег и не желают тратится вновь. Поэтому > они продолжат внедрять в ядро тот функционал, какой им надо, невзирая > на всхлипывания всяких непонятных экспертов. То есть большинство разработичков ядра (которые против внедрения раста) - это кучка "непонятных экспертов"?
	Ответить | Правка | Наверх | Cообщить модератору

	311. Скрыто модератором	+/–
	Сообщение от Аноним (-), 24-Сен-24, 17:01
	> большинство разработичков ядра > большинство Пруфы будут? Или ты как обычно?
	Ответить | Правка | Наверх | Cообщить модератору

	313. Скрыто модератором	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 24-Сен-24, 18:23
	>> большинство разработичков ядра >> большинство > Пруфы будут? Или ты как обычно? Я понимаю, что тебе как эксперту больно признавать свою неправоту, но стоит хотя бы почитать рассылку, а не жить одними желтыми новостями.
	Ответить | Правка | Наверх | Cообщить модератору

	318. Скрыто модератором	–3 +/–
	Сообщение от Аноним (-), 24-Сен-24, 18:45
	> Я понимаю, что тебе как эксперту больно признавать свою неправоту, но стоит > хотя бы почитать рассылку, а не жить одними желтыми новостями. Т.е ссылки на рассылку где "большинство разработичков ядра против внедрения раста" не будет? Как же так! Чего ты так позорно сливаешься? Да и по поводу большинства. Это то самое большинство которое не хотело видеть системмд?)) В ядре демократии нету, диктатор скажет - так и будет.
	Ответить | Правка | Наверх | Cообщить модератору

	325. Скрыто модератором	+4 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 24-Сен-24, 20:53
	>> Я понимаю, что тебе как эксперту больно признавать свою неправоту, но стоит >> хотя бы почитать рассылку, а не жить одними желтыми новостями. > Т.е ссылки на рассылку где "большинство разработичков ядра против внедрения раста" не > будет? > Как же так! Чего ты так позорно сливаешься? Просто хочу чтобы ты поработал маленько. Как накидывать без пруфов вы первые. В эту игру можно играть вдвоем оказывается. > Да и по поводу большинства. Это то самое большинство которое не хотело > видеть системмд?)) > В ядре демократии нету, диктатор скажет - так и будет. Как скажешь. Можешь нарисовать на трусиках у себя еще один крестик за победу в комментариях.
	Ответить | Правка | Наверх | Cообщить модератору

124. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
Сообщение от Аноним (-), 22-Сен-24, 20:53
Они тоже оценили pest, я вижу, bc и awk на нём. И прально, лучший генератор парсеров. Меня чёт понесло последнее время в написание интерпретаторов, и pest это что-то.
Ответить | Правка | Наверх | Cообщить модератору

	139. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 22-Сен-24, 22:34
	> Они тоже оценили pest, я вижу, bc и awk на нём. И > прально, лучший генератор парсеров. Меня чёт понесло последнее время в написание > интерпретаторов, и pest это что-то. Как вы яхту назовете... название больно уж говорящее, не обижайтесь когда дустом спрыснут :))
	Ответить | Правка | Наверх | Cообщить модератору

	275. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (265), 23-Сен-24, 23:05
	Некоторым нравится оригинальничать и переизобретать велосипеды из уже хорошо работающих вещей.
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	317. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 24-Сен-24, 18:38
	Что ты называешь "хорошо работающими вещами"? Скажи, пожалуйста, что ты имеешь в виду flex/bison, чтобы я мог над тобой поглумиться.
	Ответить | Правка | Наверх | Cообщить модератору

128. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
Сообщение от nume (ok), 22-Сен-24, 21:13
Подобные проекты и испортили репутацию языка...
Ответить | Правка | Наверх | Cообщить модератору

	143. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+5 +/–
	Сообщение от Аноним (-), 22-Сен-24, 22:51
	Репутацию конкретно этого языка портит его сообщество. Оно настолько таксичное, что подобное поведение некоторых товарищей среди апологетов других языков ещё нужно поискать.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–8 +/–
	Сообщение от Прохожий (??), 22-Сен-24, 22:56
	Причём здесь сообщество или отдельные его представители? Заслуга языка не в сообществе, а в его возможностях.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (-), 22-Сен-24, 22:58
	> Заслуга языка не в сообществе, а в его возможностях. Если ты один пишешь для себя то может и так. Но любой тот кто пишет что-то более серьезное хеллоуврота с тобой не согласится.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–2 +/–
	Сообщение от Прохожий (??), 22-Сен-24, 23:30
	Гм. Амазон, Гугл, Клаудфлэр пишут что-то боолее серьёзное. И что-то не слышал от них, чтобы они чем-то были недовольны. Дашь ссылку на их недовольство на этот счёт?
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (79), 23-Сен-24, 08:14
	Ничего серьёзного там не написано только раздутый фанатиками хайп.
	Ответить | Правка | Наверх | Cообщить модератору

	283. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Прохожий (??), 23-Сен-24, 23:40
	Дай определение слову "серьёзный". Например, в моём понимании, прокси-сервер, которым ежедневно пользуются сотни миллионов людей по всему миру - вполне себе серьёзный софт. Или ОС, которая установлена на примерно миллиарде смартфонов (на самом деле, пока цифра намного меньше, но через несколько лет  порядок будет примерно таким).
	Ответить | Правка | Наверх | Cообщить модератору

	292. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 24-Сен-24, 00:17
	> Ничего серьёзного там не написано только раздутый фанатиками хайп. Этот эксперт в каждой новости про раст упоминает эти конторки.
	Ответить | Правка | К родителю #209 | Наверх | Cообщить модератору

	310. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от Аноним (-), 24-Сен-24, 17:00
	>> Ничего серьёзного там не написано только раздутый фанатиками хайп. > Этот эксперт в каждой новости про раст упоминает эти конторки. Щито поделаешь десу (с) ¯\_(ツ)_/¯ Если Воины супротив Раста в каждой теме говорят "на нем ничего не написано!111", то приходится спускаться до их уровня и тыкать мордочкой в конкретные примеры. Нравится тебе или нет, тот же cloudflare никуда не исчезнет)
	Ответить | Правка | Наверх | Cообщить модератору

Часть нити удалена модератором

	335. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 24-Сен-24, 22:13
	> То-то на расте за 14 лет О! очередной свидетель 14 лет. Учитывая что раст 1.0 вышел в 2015, а сейчас 2024.. То у тебя с математикой примерно как и с другими областями знаний. > все вокруг уже переписали без глюков и падений. Хотя подождите те ка, что тут у нас в новости Конечно нет. Язык в ядро приняли вот-вот. Копротивление дидов еще даже не достигло своего экстремума. (я предполагаю что это будет через год-два) > Это другое надо понимать? Да, прикинь. У них где-то написано "вот готовый проект?" Или твое скудоумие не позволяет понять даже такие простые вещи? А вот драйвер от Асаши - это уже готовый проект. Он прошел сертификацию Кроноса и даже получил личную благодарку от Торвальдса. Я понимаю что дыряшники любят вываливать полуфа/b/рикаты и назвать это готовым, но не все же такие.
	Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

	297. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+2 +/–
	Сообщение от Продавец (?), 24-Сен-24, 02:47
	Строгости ради, эти конторы поднялись не на расте. Да и на чем там только не пишут. И ведроид далеко не на расте написан. Ни гугл движок ни прочее
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

	306. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 24-Сен-24, 16:20
	> Строгости ради, эти конторы поднялись не на расте. Эм... разумеется, они все старше раста. Но почему-то они признали его пригодным для себя. > Да и на чем там только не пишут. Тоже верно. Вот гугл целый Го придумал > И ведроид далеко не на расте написан. Но тем не менее новый код они пишут в том числе на расте, а также активно переписывают старый (в основном с си)
	Ответить | Правка | Наверх | Cообщить модератору

	320. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Продавец (?), 24-Сен-24, 20:00
	Я думаю там всё эволюционно, они пробуют всё подряд а потом смотрят - покатило не покатило. Когда есть ресурс можно и на расте паписать и на ерланге или вообще отправить на свалку с десяток проектов написанных на любых брейнфаках, которые всегда появляются и исчезают. Ну написали они что-то на расте, ну работает, ну и на здоровье. В принципе, не суть важно, главное дизайн хороший намутить
	Ответить | Правка | Наверх | Cообщить модератору

	164. Скрыто модератором	+4 +/–
	Сообщение от Аноним (-), 22-Сен-24, 23:33
	> Репутацию конкретно этого языка портит его сообщество. Оно настолько таксичное, что подобное поведение некоторых товарищей среди апологетов других языков ещё нужно поискать. А можно примеры? Пока я вижу как адепты и писаки дыряшки и плюсов ноют, что "на раст переписывают". Да какое вам дело? Каждый может писать на том языке, на котором пожелает.
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	144. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–3 +/–
	Сообщение от Прохожий (??), 22-Сен-24, 22:55
	> испортили репутацию языка Её, репутации, никогда и не было в головах многих, присутствующих здесь "экспертов". Потому что язык они осилить не смогли (или вообще даже не начинали). Поэтому по привычке списали всё на плохой синтаксис, хотя на самом деле проблема в них самих. А так, если говорить о мире, то до сих пор Rust - один из самых любимых языков на том же StackOverflow, судя по последнему опросу. То есть, его репутация в мире по-прежнему высока, кто бы что здесь не утверждал.
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	263. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от _ (??), 23-Сен-24, 18:15
	> Rust - один из самых любимых языков на том же StackOverflow Ржака :) Детишки, вам уж за 25 небось, а своих мозгов всё ещё нет :) Взрослейте! Ну и как говорят сами SoF - 'есть "любимые" языки, а есть языки на которых и в правду пишут...' (С) :-р
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 23-Сен-24, 18:36
	> Ну и как говорят сами SoF - 'есть "любимые" языки, а есть языки на которых и в правду пишут...' (С) :-р Срочно беги к гуглу, рассказывай что они з̶а̶б̶ы̶л̶и̶ ̶п̶р̶о̶ ̶к̶о̶с̶м̶и̶ч̶е̶с̶к̶у̶ю̶ ̶р̶а̶д̶и̶а̶ц̶и̶ю̶ совершиаю непоправимую ошибку! И к редхату с нвидией и драйвером Nova. В обьщем настало время тебе показать свою кекспертность!
	Ответить | Правка | Наверх | Cообщить модератору

	286. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Прохожий (??), 23-Сен-24, 23:57
	Мне уже за 50. Так, к слову. И я давно уже своей головой думаю, хотя, бывает, к чужому мнению тоже прислушиваюсь, особенно, когда умные и компетентные (на мой взгляд) люди говорят о чём-то, что мне интересно. Часто полезно слушать и чужое мнение тоже. Расширяет кругозор. Так, к слову, раз уж тут пошёл обмен жизненным опытом. Тут аноним выше позволил себе усомниться в репутации. Я всего лишь опроверг его мнение, сославшись на проведенный опрос. Этот опрос, по любым меркам, куда более объективный показатель репутации, нежели мнение одного человека. Не думаешь? Если же взглянуть на результаты опроса (судя по всему, ты их явно не видел, хотя мог бы, просто чтобы убедиться, что я не лгу), то выяснится, что этом языке и пишут уже довольно интенсивно. Не так много, как на Джаваскрипт, конечно, но это потому только, что ниша у Rust пока (?) уже.
	Ответить | Правка | К родителю #263 | Наверх | Cообщить модератору

	276. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (265), 23-Сен-24, 23:07
	>Rust - один из самых любимых языков на том же StackOverflow Так мы узнали, что StackOverflow не умеет боротся с накрутками.
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	285. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Прохожий (??), 23-Сен-24, 23:51
	Ладно, популярность политика накручивать, или какой-нибудь певички. Но языка программирования?!
	Ответить | Правка | Наверх | Cообщить модератору

134. Скрыто модератором	+2 +/–
Сообщение от Аноним (134), 22-Сен-24, 22:07
Берём библиотеку на C/C++, пишем на Rust unsafe вставку на Asm, Asm код вызывает функции из этой библиотеки :) Эта новость прям доказательство того, что Rust - говно. Вот что нейросети смогут делать в ближайшем будущем так это проверять весь код и полностью на все возможные дыры в безопасности и Rust умрёт. А современный код на C++ и так уже безопасный, и быстрый в отличии от Rust.
Ответить | Правка | Наверх | Cообщить модератору

	155. Скрыто модератором	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 22-Сен-24, 23:05
	> Вот что нейросети смогут делать в ближайшем будущем так это проверять весь код и полностью на все возможные дыры в безопасности и Rust умрёт Ну только алгоритм борова прост, а что там будет у нейросети вопрос. Можно ли ей доверять в вопросах безопасности?
	Ответить | Правка | Наверх | Cообщить модератору

203. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
Сообщение от мяв (?), 23-Сен-24, 08:04
кстати, аноним, вон, выше написал про нейронки. а ведь действительно, если подумать, то кучу вещей в С проверить можно статически. я вот недавно столкнулось с некорректным поведением при сборке с -О3 на кланге(в gcc окей все было). дело было в выходе за пределы массива. только функция не сегфолтилась, а возвращала 3. чатгпт помог, кинула код, сказала, что черт-те что происходит и он сказал вместо <=, влепить <. и если так задумать - нет ведь сложного ничего делать это оффлайн. условно, в качестве процедуры тестирования, собираешь парой уомпиляторов с -О{1..3}, запускаешь тесты и если что-то не то - показываешь анализатору, который нащупает у тебя, например, выход за пределы массива(в моем случае это легко было, ибо просто не та проверка в while(). если происхождение аргумента неизвестно - то просто юзеру ткнуть туды) и там уж починить. или, еще проще: -fsanitize=undefined в компиляторах, поддерживающих это + тесты. я сейчас оба варианта и использую, но с нейронкой, ибо пока такого магического анализатора не подвезли. можно сказать "а зачем все это, если rust?", но ведь: 1. С99 в POSIX 2. раст ничего предложить кроме паники в UB не может. а паниковать не проблема и в С, да еще и код мой работать везде будет. более того, с -fsanitize=undefined, gcc точно так же сует везде проверок. поэтому для обеспечения определенного поведения, в целом, достаточно обычного юнит-тестирования  всвязке со сборкой парой компиляторов. мне вот писал кто-то здесь не так давно про UB в С и то шо задетектить нереально, приводя в качестве примера переполнение signed номеров. но, честно сказать, так и не дошло, на кой их пользовать где-то за пределами четко известных ретерн-кодов и тд. я себе typedef с long unsigned int на uint сделала и проблем вроде пока не вижу.
Ответить | Правка | Наверх | Cообщить модератору

	223. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+2 +/–
	Сообщение от Аноним (220), 23-Сен-24, 09:54
	Откройте для себя статические анализаторы.
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–1 +/–
	Сообщение от n00by (ok), 23-Сен-24, 10:02
	Часть таких ошибок ловятся запретом применять < и >, когда достаточно == или !=.
	Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

	250. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 23-Сен-24, 15:24
	в контексте выхода за границы массива как это поможет? в любом случае нужно делать ++Iter и сравнивать с размером. иль я туплю?
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (254), 23-Сен-24, 16:27
	насколько я знаю, в современных высокоуровневых языках предлагается вообще не использовать индексы и итераторы. Обрабатывать коллекции предикатом, строить конвейеры данных и т.д.
	Ответить | Правка | Наверх | Cообщить модератору

	294. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 24-Сен-24, 00:56
	было б неплохо, если бы "современные высокоуровневые языки" предложили что-то bash'евских массивов и for. написал for Name in "${ArrName[@]}" и делаешь с Name шо угодно. и проще, и довольно гибко.
	Ответить | Правка | Наверх | Cообщить модератору

	302. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от n00by (ok), 24-Сен-24, 09:22
	for_each есть в Си++ со времён библиотеки "Степанов и Ли". Но и итераторы там вроде бы не считаются дурным тоном.
	Ответить | Правка | Наверх | Cообщить модератору

	343. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (343), 25-Сен-24, 00:00
	Вот именно! Например, в СОВРЕМЕННОМ языке D: foreach (index, flag; flags) Это цикл по флагам, где каждый флаг появляется в flag + дополнительно имеем значение индекса в index! Вообще никаких гемороев по отслеживанию конца массива! Но нет, все как сcыклuвые лемминги повторяют ахинею про "Ди не устоялся", зато на Ржу бегут толпами! *facepalm*
	Ответить | Правка | К родителю #254 | Наверх | Cообщить модератору

	301. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от n00by (ok), 24-Сен-24, 09:17
	> в контексте выхода за границы массива как это поможет? > в любом случае нужно делать ++Iter и сравнивать с размером. > иль я туплю? Вот том и фокус: если при написании кода возникают такие вопросы, они помогают призадуматься и выявлять ошибки, когда глаз замылился и <= пишется на автомате, а код после автора никто не смотрит. Прединкремент - это давнее требование к стилю в Си++, что бы в общем случае избежать лишней копии итератора. Оттуда же и ограничение на operator==(). Если с индексами, то и там в общем случае достаточно проверить граничное условие, т.е. !=. В том случае можно ведь заменить < на != ? В остальных зависит от конструкции цикла, иногда приходится потратить 5 минут на переоформление, но в сумме это экономнее по времени, чем позже ловить ошибки.
	Ответить | Правка | К родителю #250 | Наверх | Cообщить модератору

	341. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (343), 24-Сен-24, 23:50
	Довольно тупой рулез. У меня как раз такой хардкодинг с == != нещадно вырезается!! Пример: функция возвращает -1 при ошибке или 0...индекс. Вызывающий код - если его писал зелёный салага, то будет так: if (fn() == -1) паника! Но что если завтра я добавлю -2 в качестве индикатора ДРУГОЙ ошибки?! Тут его недальновидный код и сел в лужу (и ни один стат.анализатор это не отловит, т.к. по сути для него возвращаемое целое просто стравнивается с другим целым). Умный код будет такой: if (fn() < 0) паника!
	Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

	346. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 25-Сен-24, 05:21
	тут Вы в лужу сели - для этого есть errno.
	Ответить | Правка | Наверх | Cообщить модератору

	353. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от n00by (ok), 25-Сен-24, 10:49
	> Довольно тупой рулез. Судя по баззворду, влез тот самый назойливый эксперт, не читающий тему. Советую почитать, хотя бы до слова "массив". > У меня как раз такой хардкодинг с == != нещадно вырезается!! Как видно, моё предложение делает даже больше заявленного. Отшить левых от проекта - задача необходимая для выживания.
	Ответить | Правка | К родителю #341 | Наверх | Cообщить модератору

	232. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 23-Сен-24, 11:10
	> условно, в качестве процедуры тестирования... > более того, с -fsanitize=undefined, gcc точно так же сует везде проверок. поэтому > для обеспечения определенного поведения, в целом, достаточно обычного юнит-тестирования всвязке со сборкой парой компиляторов. В общем случае - не поможет. Возможно у тебя код проще. А может ты просто пишешь лучше, чем среднестатистический писака ядра или каких-то серьезных либ. Вот пример: целая куча дыреней в OpenSSL/LibreSSL www.opennet.ru/opennews/art.shtml?num=58622 чтение из области вне границ буфера, use-after-free, double-free, разыменование указателя NULL (x2) и тд. А теперь смотрим на проект. У них в тестах санитайзерами обмазано по самое не хочу: и address_ub_sanitizer, и memory_sanitizer, и threads_sanitizer, и ворниги компиляторов разнообразных, и фаззинг даже. Но не помогло. > 2. раст ничего предложить кроме паники в UB не может. а паниковать не проблема и в С, да еще и код мой работать везде будет. Запускаться будет (возможно). А работать будет только при правильной версии компилятора. Т.к UB позволяет вертеть поведением и делать его непредсказуемым. Если СИ может паниковать, то чего ж он не паникует, а портит соседнюю память? > мне вот писал кто-то здесь не так давно про UB в С и то шо задетектить нереально, приводя в качестве примера переполнение signed номеров. Да, к сожалению такая ошибка уже "одна из классических". > но, честно сказать, так и не дошло, на кой их пользовать где-то за пределами четко известных ретерн-кодов и тд. Возможно, потому что в книжках полувековой давности был такой пример. Он и кочует из кода в код) > я себе typedef с long unsigned int на uint сделала и проблем вроде пока не вижу. Адепты скорости осудят тебя. Потому что u long int - это минимум 64 бита, а uint это минимум 16. В проектах иногда пихают по 2 куска данных в одну переменную, чтобы побыстрее было. Проблема с UB в том, что даже одно убивает конформанс программы. А их слишком много. Получается, что практически любая программ, кроме простейшей, согласно стандарта СИ не будет strictly conforming. А мы говорим про супер сложные кода, надежность которых должна быть маскимальной. Но вместо этого берут кривой-косой инструмент((
	Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

	251. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 23-Сен-24, 15:55
	из ссылки, как я поняла, основную опасность представляет какой-то косяк с типами. >Если СИ может паниковать, то чего ж он не паникует, а портит соседнюю память? можно ж сделать, что б паниковал, нет? я себе к проекту в добавок бойлерплейт пишу небольшой. все что плохо лежать может - в доп. функцию и в ней сразу отлавливать ошибки. в связке с #define _POSIX_C_SOURCE, работать даже почти везде будет. по поводу работы с памятью, ошибки *alloc'ов - это всегда не более, чем проверка errno, free() усмирить можно через проверку указателя на NULL и последующую установку на него же после очистки. с разименованием нулевых тоже все относительно легко - в мане по каждой функции libc в разделах Return Values, Errors и Standards описано, кто кого и как возвращает. я к своим подобное пишу в хедер-файлах пока. если написано, что в случае неудачи функция сама не вызывает панику, дергаешь проверялку указателя(обязательно в if-условии, ибо иначе компилятор может порядок исполнения сменить) и либо самостоятельно шото с этим делаешь, либо дергаешь ту версию, что вместо, условно, возврата false, будет паниковать. но это да, довольно неудобно бывает, поэтому такого по максимуму стараюсь не допускать. если что-то где-то как-то фейлится - оно ставит errno. а вызывающий просто errno проверяет. в связке с небольшими косметическими макросами и бойлерплейтом, выглядет все довольно хорошо, читаемо(на мой взгляд и взгляд еще пары человек). можно, например, передать вызов в макрос, он сам и код проверит, и панику вызовет. + в некоторых случаях, вызывающий может указать причину паники и функция, дергающая спец. "паникер", упадет не потому что "Runtime Error: ...", а потому что "File Not Found". еще было б классно иметь что-то вроде питоновского with-блока. может, это реально реализовать как-то, неуверена пока. >Он и кочует из кода в код как, к слову, и Iter++ вместо ++Iter. даже в коде systemd Iter++ делают. сама недавно только узнала об этом. >Адепты скорости осудят тебя. Потому что u long int - это минимум 64 бита, а uint это минимум 16. я еще понять могу, когда за излишнюю дин. аллокацию ругают, а байты экономить не в коде для ембеддеда явно смысла нет. тем более, в условиях, где "шаг влево/вправо - расстрел". при чем тут скорость вообще? это ж только на жручесть влияет, нет? >Но вместо этого берут кривой-косой инструмент(( он в спеке от IEEE и скомпилиться почти на любой микровалновке. а раст.. он скорее как замена С++.
	Ответить | Правка | Наверх | Cообщить модератору

	255. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (254), 23-Сен-24, 16:35
	конечно, если всё делать аккуратно, то никаких ошибок и не будет. Но, видимо, не все люди одинаково ответственные и дисциплинированные.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (-), 23-Сен-24, 18:12
	> можно ж сделать, что б паниковал, нет? > я себе к проекту в добавок бойлерплейт пишу небольшой. Но если оно не обязательно, то можно же не делать)? Мы ж тут профи, это зеленые джуны будут так ошибаться (с) > по поводу работы с памятью, ошибки *alloc'ов - это всегда не более, чем проверка errno, free() усмирить можно через проверку указателя на NULL и последующую установку на него же после очистки. То что ты описала это двольно сложно, если код многопоточный. Например относительно недавнее отверстие в ХОргʼе (opennet.ru/opennews/art.shtml?num=58612) - там не занулили переменную и наткнулись на UB. Значение указателя после вызова free() является неопределённым. Причем даже не само значение памяти, которое по этому указателю, а даже само значение указателя. - The value of a pointer that refers to space deallocated by a call to the free or realloc function is used (7.20.3). > с разименованием нулевых тоже все относительно легко - в мане по каждой функции libc в разделах Return Values, Errors и Standards описано, кто кого и как возвращает. Если это зависить от компилятора (а еще круче, от его версии) то код получается нифига не переносимый. > если написано, что в случае неудачи функция сама не вызывает панику, дергаешь проверялку указателя(обязательно в if-условии, ибо иначе компилятор может порядок исполнения сменить) и либо самостоятельно шото с этим делаешь, либо дергаешь ту версию, что вместо, условно, возврата false, будет паниковать. Взять бы тебя... и отправить ядро писать) А то там по какой-то причине с подобными проверками не заморачиваются. Наверное слишком уверенны в себе :D > как, к слову, и Iter++ вместо ++Iter. > даже в коде systemd Iter++ делают. > сама недавно только узнала об этом. А если не секрет, сколько ты уже пишешь? Потому что в си и плюсах есть куча таких "неявных особенностей", которые больше известны как "100500 способов отстрелить себе ногу") > он в спеке от IEEE и скомпилиться почти на любой микровалновке. К сожалению, я читал стандарт СИ и он меня очень печалит. Особенно раздел conformance. Т.к согластно нему, получить strict conformance практически невозможно. Если добавить к этому то, что реализация стандарта не обязательна и каждый компиятор может просто не реализовывать какие-то куски стандарта (en.cppreference.com/w/c/compiler_support).. То вопрос "а почему это вообще называется стандартом" остается открытым. Например в С23 добавали UB на код, который раньше был ID. Как поведет в этом случае написанный код низнает никто. > а раст.. он скорее как замена С++. Пока его пытаются добавать в ядро, а плюсы туда не пустили (хотя мне кажется что зря). В андроиде гугл заменяет кода на си и плюсах на раст - значит оно подходит и для первого, и для второго.
	Ответить | Правка | К родителю #251 | Наверх | Cообщить модератору

	287. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 23-Сен-24, 23:58
	>Но если оно не обязательно, то можно же не делать)? а как? мне надо posix'y следовать, ни раст, ни с++ не катят. >The value of a pointer that refers to space deallocated by a call to the free or realloc function is used (7.20.3). это откуда инфа? в 7.20.3 из спеки с99 только: >The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs. Otherwise, if the argument does not match a pointer earlier returned by the calloc, malloc, or realloc function, or if the space has been deallocated by a call to free or realloc, the behavior is undefined. в последнем там вообще "limits of int types". в posix по этой теме ничего. никакой критики в сторону установки на NULL не нашла. в любом случае, никто не мешает сделать все то же самое, но с доп. структурой и набором макросов. >даже само значение указателя так если его поставить на NULL, он ж и будет NULL. то что кто-то обнулить забыл - это дело уже десятое. хотя, не знаю, как можно забыть обнулить, если очистка делается только через функцию, которая и ставит, и проверяет. может быть, конечно, такое, что, к примеру, кто-то новый закоммитил и использовал free(), но тогда вопрос, почему free() еще не заглушен чем-нибудь(условно, в главном хедере либы включать в первую очередь то, что отвечает за обработку памяти, а потом сразу же файл с заглушками, я так и сделала)? в новости-то именно обнулить забыли, а не "обнулили и получили из-за этого баг". >Если это зависить от компилятора и поведение компилятора, и повидение компонентов libc, описано в POSIX. >А то там по какой-то причине с подобными проверками не заморачиваются. так и не дошло, почему. скорее всего замедления боятся или что-то в этом роде? но как будто бы просто пару раз значение int-переменной проверить не так уж много времени отъедает. тем более, часто можно в кол.-ве проверок именно за счет errno выиграть. тоже хз, почему его не используют, слышала только мнение, что он "исключительно для компонентов libc", но как бы .. заведи себе другую переменную и проблем не знай. почему в systemd всем плевать - я не знаю. еще не знаю что за афигенная привычка у некоторых товарищей давать имена в стиле "imyamoyeyperemennoy". хотела недавно код из dash подсмотреть, так и не поняла, о чем там. >А если не секрет, сколько ты уже пишешь? где-то месяца полтора. >т.к согластно нему, получить strict conformance практически невозможно. для этого есть posix. куча вещей описывается, куча форсируется. в результате, можно ожидать вполне предсказуемой реализации. >Например в С23 добавали UB на код, который раньше был ID. это тоже posix решает. да и пишут обычно под конкретную версию стандарта, а не с99+, например. >Пока его пытаются добавать в ядро, а плюсы туда не пустили (хотя мне кажется что зря). В андроиде гугл заменяет кода на си и плюсах на раст - значит оно подходит и для первого, и для второго. что-то мне подсказывает, что им "молодой крови" не хватает. и, пропустив шанс ее завлечь с с++, сейчас пытаются не опростоволоситься. ну и раст пока почище плюсов будет.
	Ответить | Правка | Наверх | Cообщить модератору

	296. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 24-Сен-24, 02:38
	>это откуда инфа? не то в цитату выделила, подумала, что речь о "установка на NULL и проверка - UB".
	Ответить | Правка | Наверх | Cообщить модератору

	305. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 24-Сен-24, 16:17
	> это откуда инфа? > в 7.20.3 из спеки с99 только Это улучшения в С23. Жить стало лучше, жить стало веселей (с) Причем мотивация комитета просто гениальная. В стиле "раньше было плохо, а мы сделаем еще хуже". Т.к POSIX и реализации для realloc(ptr, 0) ведут себя по-разному, Classifying a call to realloc with a size of 0 as undefined behavior would allow POSIX to define the otherwise undefined behavior however they please. то давайте сделаем не ID (т.е конкретный список возможных вариантов), а UB - т.к ХЗ что. Making this behavior undefined continues to allow existing implementations to do as they please, but provides a clear warning to developers to guard against zero-byte reallocations. По поводу NULL я наверное не очень понятно выразился. В стандарте СИ есть такое The behavior is undefined in the following circumstances: ... The value of a pointer that refers to space deallocated by a call to the free or realloc function is used (7.20.3). Т.е код int *А = malloc(16); printf("%p\n", А); free(А); то любое взаиможействие с А - это будет UB. Например повторный printf("%p\n", А); Раз программа содержит UB, то о strictly confirm можно забыть. Корретность кода становится под вопросом. А такой код написать ну очень просто.
	Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

	347. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 25-Сен-24, 05:27
	жесть. в коммитете забыли, что posiх их дальше 99й версии не признает? >любое взаимойдействие с A будет UB поэтому при получении указателей от вызывающего - проверка, проблемы особо не вижу.
	Ответить | Правка | Наверх | Cообщить модератору

	308. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 24-Сен-24, 16:46
	>>А то там по какой-то причине с подобными проверками не заморачиваются. >так и не дошло, почему. Мне кажется, что по причине "мы уверенны в своем коде и своем опыте". Ну и в том, что нужна скорость любой ценой. В старых программах очень любили использовать (не|слабо)документированные хаки ради ускорения. Например когда (2021) ядро стало собираться с Werror по умолчанию, то тонны хаков отвалились. phoronix.com/news/Linux-5.15-Werror-Pain Настолько, что даже попытались п̶р̶о̶в̶е̶р̶н̶у̶т̶ь̶ ̶ф̶а̶р̶ш̶ ̶о̶б̶р̶а̶т̶н̶о̶ сделать реверт patchwork.kernel.org/project/linux-kbuild/patch/20210907183843.33028-1-ndesaulniers@google.com/#24432767 > скорее всего замедления боятся или что-то в этом роде? но как будто бы просто пару раз значение int-переменной проверить не так уж много времени отъедает. > тем более, часто можно в кол.-ве проверок именно за счет errno выиграть. Иногда мне попадались мнения, что присваивать NULL после free это вредно, тк тратятся лишние такты процессора. Так что ты права, люди хотят экономить максимально, даже там где это не нужно. Просто по привычке или из-за карго культа. > еще не знаю что за афигенная привычка у некоторых товарищей давать имена в стиле "imyamoyeyperemennoy". хотела недавно код из dash подсмотреть, так и не поняла, о чем там. Без капитализации выглядит не очень. Но зависит от принятых стандартов в проекте. В моих идет camelCase, где переменные вида iAndMyCodeIsAvesome. Но я абсоkютно спокойно отношусь и к some_stupid_variable. Это все вкусовщина и за много лет просто привыкаешь. Ну типа как "есть брюнетки и блондинки.. both, both is good (c)" > для этого есть posix. куча вещей описывается, куча форсируется. > в результате, можно ожидать вполне предсказуемой реализации. К сожалению нет. В прошлом сообщении я как раз писал, что реализации и стандарты это очень разные вещи. > что-то мне подсказывает, что им "молодой крови" не хватает. О, интересное мнение, которое очень не популярно на этом форуме)) Тут любят гнобить "смузихлебов" и "снежинок", ну и политься на дидов. > ну и раст пока почище плюсов будет. Плюсы вообще делались как надстройка над СИ. И Страуструп в своем недавнем интервью вообще заявил "У меня не было знаний, чтобы создать с нуля язык программирования". >>А если не секрет, сколько ты уже пишешь? > где-то месяца полтора. Тогда удачи. У тебя будет еще много интересных и неожиданных открытий.
	Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

	348. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 25-Сен-24, 05:50
	>К сожалению нет. В прошлом сообщении я как раз писал, что реализации и стандарты это очень разные вещи. так нет ведь. в POSIX с UB/ID куда осторожнее, любая неопределенность(как правило, довольно некритичная) решается обычной проверкой этого состояния в бойлерплейте. ну и там уж делать что-то на свое усмотрение. если же реализация стандарту не следует, или реализует другой - то это уже и не моя проблема, ибо работа была заявлена в окружении, реализующем конкретный стандарт конкретной версии. >Плюсы вообще делались как надстройка над СИ. так а раст? только там даже не над С, а во многом над кишками llvm.
	Ответить | Правка | Наверх | Cообщить модератору

	354. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 25-Сен-24, 11:29
	Даже POSIX имеет много версий. И меня терзают смутные сомнения, что код для ISO/IEC 9945-1:1990 будет работать с 2017 (последний стандарт). Даже на сайте ISO старые считаются отозванными iso.org/standard/17840.html. Новый POSIX.1-2024 предлагает вообще тонну новых функций и удаление старых, причем довольно много. Как поведет себя некрософт вопрос, подозреваю что плохо (sortix.org/blog/posix-2024/) А профили 1003.13 вообще не поддерживают все ОС. > так а раст? > только там даже не над С, а во многом над кишками llvm. Неа) Тут ты не права. У Раста есть фронт и бек, как у многих языков которые делались под llvm Изначально компилятор писался на окалме, а потом переписали на сам раст (rustc). Но это фронт. А бек у него был с использованием llvm (который написан на С++). Но есть и альтернатива в виде cranelift - бекенд написанный полностью на расте. Т.е есть у нас есть рабочий вариант "rust front + rust back".
	Ответить | Правка | Наверх | Cообщить модератору

	361. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 25-Сен-24, 13:27
	>поведет себя некрософт вопрос, у него, как правило, #define _POSIX_C_SOURCЕ на таргет-версию. и времени на переписывание у разрабов минимум лет 7. под 2018й и то без опасок до сих пор писать нельзя, потому, все в основном пишут под 2008й. сейчас, конечно, почти везде 2018й стандарт реализован, но некоторые окружения с 2008ым есть еще. в случае с утилитами, да, действительно, можно огрести, способа получить версию реализованного стандарта, например, в шелле - нельзя. справедливости ради, все удаления предварительно помечаются как deprecated(лет эдак на.. 20? скольо там $[] для математики держат?), и часто там же предоставляется новый способ, особо проблем не создающий. поэтому даже переписывать мало что нужно при мажорных изменениях в стандарте и использовании deprected-функционала программой. при том, благодаря "рекурсивной" поддержке, стандарт не превращается особо в помойку, а все, что использовать нинада, четко выделено. >Неа) хм.. глянула, действительно. а мне в чате в матрице один человек пару месяцев назад рассказывал, что раст полностью на интристиках llvm'а. тем не менее, кто код-то генерирует и какой? cranelift что делает? С-код компилит? или там свой байткод уже?
	Ответить | Правка | Наверх | Cообщить модератору

	369. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (369), 25-Сен-24, 20:35
	>кто код-то генерирует и какой? https://blog.rust-lang.org/2016/04/19/MIR.html Вроде как компилятор Rust переводит программу в свою собственную промежуточную форму mir, а её уже в llvm или wasm
	Ответить | Правка | Наверх | Cообщить модератору

	336. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 24-Сен-24, 22:13
	> по поводу работы с памятью, ошибки *alloc'ов - это всегда не более, чем проверка errno, errno сам по себе привносит возможностей наступить на грабли, поскольку это статическая переменная. Грабли от конкурентности вроде победили сделав errno thread-local, но реентерабельности как не было, так и нет и не будет никогда. Поэтому надо очень внимательно следить за тем, чтобы между выставлением errno в значение ошибки и проверкой этого значения не влез бы ещё какой-нибудь код, который тоже захочет errno поменять. С учётом того, что между выставлением значения errno и кодом проверки как правило несколько стековых фреймов, то не наступить на эти грабли становится довольно сложно. Достаточно сложно, чтобы на них регулярно кто-нибудь наступал. > free() усмирить можно через проверку указателя на NULL и последующую установку на него же после очистки. Кек. Это если ты знаешь все места, где этот адрес хранится. Тогда да, тогда можно все их занулить после free. Или лучше, на всякий случай, сначала их все занулить, а потом сделать free на значение взятое из локальной переменной. Но это если ты можешь перечислить все места, где адрес хранится. Программисты очень часто упускают какую-нибудь локацию. Вот тут занулили, free вызвали, а там указатель остался ждать, когда какой-нибудь код наступит на use-after-free. Но при этом бывают ещё более интересные ситуации, когда пытаясь наэкономить аллокаций, пытаешься выделять на стеке, но не всегда получается, и в какой-то момент понимаешь, что не знаешь куда указатель указывает, на стек или в кучу, потому то в зависимости от предыдущих ветвлений может быть либо то, либо это. И это ещё хорошая ситуация, когда понимаешь, что не знаешь, можно разрулить ситуацию. Хуже бывает, когда думаешь что знаешь, но ошибаешься. Именно подобные ситуации легко могут привести к возврату из функции указателя на локальный массив. Или к free на стековый адрес, или к мемлику, или к use-after-free, или к double-free. Именно поэтому сишный код пишется довольно консервативно, без особого старания избегать аллокаций любой ценой, потому что цена легко может стать неподъёмной. > с разименованием нулевых тоже все относительно легко - в мане по каждой функции libc в разделах Return Values, Errors и Standards описано, кто кого и как возвращает. Это отстой же. Никакого контроля за программистом, что он прочитал ман и не забыл обработать ошибку. То ли дело Maybe/Option/Result: возвращаемым значением не воспользоваться, не обработав ошибку. Зачем писать в комментах и манах то, что можно описать заголовком функции, и пускай дальше компилятор энфорсит использование функции согласно заголовку. > байты экономить не в коде для ембеддеда явно смысла нет. Ну это смотря где. Загляни в sparse[1], ты увидишь как там Торвальдс в парсере C _биты_ экономил. Один лишний байт в структуре -- это не проблема, до тех пор, пока ты не создашь миллиона таких структур, превратив этот лишний байт в лишний мегабайт. Или в несколько мегабайт, если размер структуры выравнивается до кратного 8, и этот дополнительный байт как раз перевалил через эту границу. Но Торвальдс, я подозреваю, больше заботился о том, чтобы структуру можно было бы по значению передавать везде, и чтобы она при этом минимум регистров занимала бы, оставляя как можно больше регистров под другие аргументы. Ситуация может ещё усугубиться (не в случае sparse, а в общем случае), если многопоток, причём особенно если юзерспейс многопоток, позволяющий миллионы тредов гонять с минимумом оверхеда: чем больше структуры, тем больше стека выделять надо под каждый тред, стек надо выделять с запасом, и... нутыпонел. Если ожидаемый размер стека вырос на N байт, но мы не можем посчитать точно, значит надо накинуть 2*N или может 10*N, так чтобы наверняка. В целом, конечно, байтом больше, байтом меньше, какая разница. И часто это работает. А иногда получаются электроны, которые выжирают несколько сотен мегабайт даже если программа на электроне ничего не делает. [1] https://git.kernel.org/pub/scm/devel/sparse/sparse.git
	Ответить | Правка | К родителю #251 | Наверх | Cообщить модератору

	349. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 25-Сен-24, 06:29
	>errno сам по себе привносит возможностей наступить на грабли об этом в разделе NOTES в мане написано описан правильный путь обхода. я так делаю: Call1(); catch {   catchExact(EINVAL){     printf("%s\n", "EINVAL!");     exit(3);   }   exit(1); } catch - сохраняет errno в локальную переменную, ставит на 0, потом проверяет локальную. catchExact - так же смотрит в локальную. поэтому достаточно просто catch совать сразу после вызова, а там уж делать, что угодно. ставится errno через throw(Code, FailReturn), но он и завершение сразу дергает, поэтому ситуаций, когда отправленный код кто-то перебьет, не возникает. >Вот тут занулили, free вызвали, а там указатель остался ждать, когда какой-нибудь код наступит на use-after-free. ну, во-первых, вызвали не free, а бойлерплейт, который сразу все занулит. во-вторых, перед использованием "левого" указателя(того, который передал вызывающий, например), дергаем уже другой бойлерплейт, который указатель проверит и запаникует в случае чего. <...>PointVerify(point1, point2) {   // Process point1, point2 } но тут важно: бойлерплейт должен дергать if и взаимодействовать с указателем только если все окей, вещи вроде   if (!<...>) { exit(1); } не пойдут, т.к. компилятор может спокойно порядок исполнение поменять. >из функции указателя на локальный массив. это обычно компилятор контроллирует, без примера я тут мало что скажу. >Это отстой же. это цена портабельности же. никто, опять же, не мешает вокруг стандартных функций добавить бойлерплейт для авто-отлова. я так и делаю сейчас. в голове в итоге держать приходится не очень мнрго, ибо знаю, что в случае чего будет паника и я это увижу в любом случае. > ли дело Maybe/Option/Result ну будет Maybe/Option/Result в общепринятом стандарте - тогда и будет "то ли дело". я момент с posix'ом специально выделила. не было б такой задачи - я б и дальше на cs писала. >Загляни в мне в каждый файл в репе заглянуть? по ссылке - summary репозитория.
	Ответить | Правка | Наверх | Cообщить модератору

	352. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 25-Сен-24, 09:45
	> об этом в разделе NOTES в мане написано описан правильный путь обхода. Мало ли что там написано, язык доверяет программисту, что тот не забудет это сделать. Но весь опыт программирования показывает, что программисту нельзя доверять. Есть подход "доверяй, но проверяй", но он работает только тогда, когда проверка работы программиста как минимум на порядок проще чем работа программиста. errno не отличается таким свойством: чтобы убедиться что работа с ним корректна, придётся обойти всё дерево вызовов, найти все места где errno может меняться теоретически, убедиться что во всех местах где errno может практически меняться совершены все необходимые ритуалы, чтобы не затереть ещё необработанное значение errno. Проще самому написать программу с нуля, чем проверять все эти вещи. > ну, во-первых, вызвали не free, а бойлерплейт, который сразу все занулит. Ты о чём сейчас? Что за бойлерплейт? Представь, у тебя наворочаны какие-то структуры данных, и где-то в них есть три указателя хранящих адрес, который ты хочешь занулить. При этом, возможно, этот адрес есть ещё где-то в локальных переменных выше по стеку. Как ты будешь это делать? А теперь представь ещё, что ты ошибаешься, и в твоих структурах этот адрес сохранён в пяти местах, а не трёх. Хочешь ещё усложнений? У тебя многопоточная программа, и к тому адресу обращаются другие потоки, то есть у них на стеках тоже может хранится этот адрес. А, ещё там может хранится не сам адрес на объект, а адрес на какую-то часть объекта, например, не адрес заголовка списка, а адрес какого-то элемента внутри списка. Если это всё кажется слишком абстрактным, я тебе могу конкретный сценарий нарисовать. Он не демонстрирует всего вышеперечисленного (всё сразу вряд ли возможно продемонстрировать одним примером), но создаёт некий контекст. Например, допустим у нас есть функция log: void log(enum LogLevel level, char* format, ...); И допустим, что этот log собирает свои аргументы в структурку и заталкивает её в очередь, чтобы когда логирующий поток доберётся до этого сообщения, он бы его отформатировал и отправил бы во все места куда логи ведутся. И допустим, я делаю так: do_smth_with_file(char* fname) {     FILE *f = fopen(fname, "r");     log(LogLevelNotice, "successfuly opened file {}, got {}", fname, f); потом я что-то делаю с файлом, а потом:     log(LogLevelNotice, "I'm going to close the file {}", f);     fclose(f); Упс. Я получил датарейс ведущий к use-after-free. Если log не успеет передать в логирующий поток всё, чтобы тот успел бы извлечь из f все нужные ему поля, чтобы отформатировать сообщение, прежде чем будет вызвана fclose, то тут use-after-free. Пример кажется высосанным из пальца? Давай я накину возможную мотивацию для такой архитектуры логирования. Логирующий поток может хранить один буфер под все сообщения и форматировать их туда, что даст нам вместо O(N) аллокаций, где N это количество сообщений в логе, O(1) аллокаций, когда логирующий поток выделяет и перевыделяет буфер небольшое количество раз (<10) за время жизни программы, нащупывая самую большую используемую длину сообщения. При этом, хочется логирование в отдельный поток засунуть, чтобы не повреждать себе latency дополнительно: логирующий поток может блокироваться на вводе/выводе, и пускай он блокируется, но эти блокирования не будут мешать основной программе. Там есть ещё один датарейс, если ты не заметил: первый вызов log передаёт указатель из локальной переменной-аргумента. Эта локальная переменная прекратит существовать когда функция завершится. Строка, на которую она указывает переживёт функцию (если та не делает free(fname)), но сколько она проживёт ещё? А никто не знает. Может быть после вызова нашей дебильной функции в вызывающем коде сразу освобождение памяти. Или может строка на стеке лежит, и после очередного return она будет лежать вне стека. Тут не важно, какой бойлерплейт ты наворачиваешь поверх free, проблема в том, что надо перебрать все места, где адрес хранится и запросто может оказаться, что не все места достижимы для твоего кода которому вдруг приспичило удалить объект. Стек другого потока недостижим, стековые фреймы кроме текущего недостижимы, все сложные разветвлённые структуры состоящие из миллиардов объектов недостижимы, если указатель на них не передан аргументом и не хранится в глобальной переменной. То есть даже зайти подходом консервативного сборщика мусора не удастся. В целом, если тебе кажется, что проблема правильно расставить malloc/free -- это тривиальная проблема, то это говорит только о том, что ты не понимаешь проблемы. Ты можешь использовать это правило в качестве детектора людей далёких от программирования, рассуждающих об управлении памятью. > это обычно компилятор контроллирует, без примера я тут мало что скажу. C не контролирует или контролирует в тривиальных случаях. Добавь чутка осложнений... char *foo(char *in) {     char *local_str = "1234";     return longest_string_of_two(in, local_str); } ... и компилятор не справится. > это цена портабельности же. Плевал я на портабельность, которая хочет от меня, чтобы я такую цену платил. > никто, опять же, не мешает вокруг стандартных функций добавить бойлерплейт для авто-отлова. Если этим заняться серьёзно, а не на полшишечки, то ты получишь rust. > ну будет Maybe/Option/Result в общепринятом стандарте - тогда и будет "то ли дело". > я момент с posix'ом специально выделила. не было б такой задачи - я б и дальше на cs писала. Ой, да ладно, что ты к этому позикс прицепился. fn posix_open(fname: Path) -> Result<FileDescr, IOError> {     let ret = unsafe { syscall::open(         fname.as_osstr(),         syscall::OpenFlags::default(),         syscall::OpenMode::default(),     )};     if ret < 0 {         IOError::from_syscall_ret(ret)     } else {         FileDescr::from_int(ret)     } } И всё, и нет никакого позикс. То есть он как бы и есть, со всеми его недостатками, но мы его спрятали, и теперь его недостатки нам по-барабану. Нет, например, errno, потому что ядро возвращает код ошибки значением. Нет C'шных enum'ов, которые позволяют любое значение int'а просунуть, помимо перечисленных в enum. errno это legacy из 80-х. В C неудобно пользоваться другими способами, тот же tagged enum создавать, который сможет хранить либо возвращаемое значение функции, либо ошибку, можно, но при отсутствии параметризации, придётся на каждую пару типов возвращаемого значения и ошибки создавать новый enum. Из-за этих неудобств программисты начали халявить со статической переменной. И даже если это posix, то это не пример для подражания, более того зашквар этим пользоваться для современного программиста. С позиксовыми функциями часто иначе не удастся, ок, но зависимость от errno должна прекращаться на границе позиксового кода и твоего. > мне в каждый файл в репе заглянуть? Зачем же в каждый. Начни с main.c, и посмотри как программа обходится с передачей подстрок в функции и возврату их из функций. Но я б рекомендовал не останавливаться на этом, а читать эти сорцы на сон грядущий вместо того комиксов, которые ты читаешь. Это очень неплохой пример, как надо писать на C, плюс это пример recursive descent парсера. > по ссылке - summary репозитория. Ну, главная страница репа. Она напрашивается как выбор точки входа. Можно было ещё homepage взять такой точкой входа, но... уже как получилось, так получилось.
	Ответить | Правка | Наверх | Cообщить модератору

	363. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 25-Сен-24, 14:12
	>Ты о чём сейчас? о том, что негоже напрямую все кишки вываливать. проще, безопаснее все в define'е/функции спрятать. >И допустим, я делаю так: пример, как абстрактным был, так таковым и остался. ибо Вы проблемную функцию спрятали. я не поняла ничего, честно сказать, все так же не могу ничего ответить, ибо не вижу, что у Вас там в log(). мне так же не ясно, зачем Вы логгеру передаете  FILE* ? он в него писать будет? почему тогда открывает вызывающий, а не глав. поток логгирования? и почему он как vararg передается? шо вообще там происходит? >longest_string_of_two #include <stdio.h> char *getLongestStr(char *str1, char *str2){   if (strlen(str1)>strlen(str2)){     return str1;   }   else {     return str2;   } } char *foo(char *in) {     char *local_str = "1234";     return getLongestStr(in, local_str); } int main(void){   printf("%s\n", foo("12")); } вот с реализацией. UB нет. или я поняла Вас неверно? >Плевал я на портабельность держете в курсе? ладно. надо было с этого начать. >И всё, и нет никакого позикс действительно. ведь Вы реализовали черт-те что на нестандартизированном языке. если бы "POSIX-совместимость" предполагала "реализовать функции из POSIХ libc на любом языке", я бы это все не писала :) >errno это legacy из 80-х. я Вам выше про него написала. Вы ничего "по факту" не сказали, только про легаси. > даже если это posix, то это не пример для подражания, более того зашквар этим пользоваться для современного программиста ну, уж извините, IEEE в этом мире больше решает, чем мнение анонима на опеннете. касаемо Линусовского кода - мое заявление было скорее про случаи, когда "по 2 значения в переменную пихают", на NULL ставить указатели бояться, экономя "такты процессора".
	Ответить | Правка | Наверх | Cообщить модератору

	368. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 25-Сен-24, 17:12
	> я не поняла ничего, честно сказать, все так же не могу ничего ответить, ибо не вижу, что у Вас там в log(). Пфф... Например она может выглядеть так: static InterThreadChannel log_channel; void log(enum LogLevel level, char *fmt, ...) {     va_list args;     va_start(args, fmt);     ChannelMsg msg = {         .level = level,         .fmt = fmt,         .args = collect_ellipsis_args(args),     };     log_channel.send(msg); } Так понятнее стало? Или надо пояснить, что на том конце channel'а? Что-то типа: char *buf = NULL; size_t bsize; while(true) {     ChannelMsg msg = log_channel.get();     logger_format(&buf, &bsize, msg); // представь себе, что идейно это что-то типа asprintf, только вместо varargs аргументы получает структурой и свой синтаксис форматной строки реализует     write_msg_to_log_file(buf);     write_msg_to_loggin_server(buf);     write_msg_to_whatever(buf); } Теперь понятно? > вот с реализацией. > UB нет. или я поняла Вас неверно? Глаза разуй. Вот представь себе, я пишу код, который вызывает foo: char *s = foo(); // тут я делаю много полезных вещей с s // ещё немного полезных вещей // ... // дело подходит к концу функции, s нам больше не нужен, и я такой: free(s); return; } Теперь ты видишь UB? Или может я должен поступить так: // ... // дело подходит к концу функции, s нам больше не нужен, и я такой: return; } Как думаешь? Что лучше: memleak или повреждение кучи? > действительно. ведь Вы реализовали черт-те что на нестандартизированном языке. Стандарт позикс не накладывает никаких ограничений на язык, мною используемый, и на то, что я на нём буду писать. Если бы он накладывал, то это был бы не позикс, а Apple. Таким образом, моя программа полностью соответствует стандарту POSIX. > Вы ничего "по факту" не сказали, только про легаси. То, что я сказал, для тебя "ничего"? Если ты требуешь от программиста пропрыгивать через кольца для того, чтобы получить надёжный код, но оставляешь ему лазейку, как получить видимо работающий код без всех этих сложностей, то глупо рассчитывать на то, что в результате выйдет надёжный код. Если ты этого не понимаешь, то это от отсутствия опыта работы с другими программистами.
	Ответить | Правка | Наверх | Cообщить модератору

	372. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от n00by (ok), 27-Сен-24, 10:58
	>>longest_string_of_two > ... > вот с реализацией. > UB нет. или я поняла Вас неверно? Со "строками" - это был наброс от тролля: 1. В Си нет string. 2. Когда два массива char имеют равную длину, что может вернуть предполагаемая функция? longest_string_of_two - сферический конь в вакууме и на деле не имеет смысла возвращать указатель. 3. Когда программе требуется много чего делать с текстом, то строки хранятся в специально для того придуманном виде. Например, в NT это UNICODE_STRING, а у остальных своё.
	Ответить | Правка | К родителю #363 | Наверх | Cообщить модератору

	351. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 25-Сен-24, 09:41
	> Ну это смотря где. Загляни в sparse[1], ты увидишь как там Торвальдс в парсере C _биты_ экономил. Один лишний байт в структуре -- это не проблема, до тех пор, пока ты не создашь миллиона таких структур, превратив этот лишний байт в лишний мегабайт. Интересно, насколько это увеличивает вероятность ошибки. И как оно потом выглядит после оптимизаций. > Или в несколько мегабайт, если размер структуры выравнивается до кратного 8, и этот дополнительный байт как раз перевалил через эту границу. Но Торвальдс, я подозреваю, больше заботился о том, чтобы структуру можно было бы по значению передавать везде, и чтобы она при этом минимум регистров занимала бы, оставляя как можно больше регистров под другие аргументы. Предположу, что это было актуально для техники 91 года, когда писалось ядро. А это были темные времена, даже до первого пентиума. Насколько оно актуально сейчас? (когда кеш в современной ряжанке, больше чем оператива моего первого компа). Может такие сверх оптимизации нужны только для 8битных микроконтроллеров?
	Ответить | Правка | К родителю #336 | Наверх | Cообщить модератору

	360. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 25-Сен-24, 13:26
	> Интересно, насколько это увеличивает вероятность ошибки. Это уменьшает допустимые размеры для токенов, там поля типа size вовсе не u64, и даже не u32, то есть идентификатор на 4 гигабайта sparse не сможет прожевать. > Предположу, что это было актуально для техники 91 года, когда писалось ядро. > А это были темные времена, даже до первого пентиума. > Насколько оно актуально сейчас? Актуально. Но тут тебе придётся верить мне на слово, потому что у меня нет ссылки, я не сохранял её в закладках, потому что не думал, что кому-нибудь она будет полезна. Я пару лет назад читал разбор полётов, в котором чувак пытаясь разобраться в том, куда сжираются гигабайты оперативки, доковырялся до используемых им структур, и переупорядочив поля там, эти самые гигабайты сэкономил. Там была именно ситуация зиллионов инстансов этих структур. Чувак очень радовался своим обретённым познаниям о том, как упаковываются C'шные структуры, и о том, как эти структуры лучше всего писать. Это знания, которые при программировании под DOS считались азами программирования на C, которые усваивались вместе с синтаксисом C, но видимо свежим поколениям программистов это уже дают элективным курсом, и некоторые пропускают. Плюс ты упускаешь из виду то, что каким бы твой кеш не был большим, в него не лезет всё. И если ты впихнёшь в него на десять процентов больше инстансов структур, то твой код будет работать примерно на 10% быстрее. Тут уже работает даже не абсолютное снижение размера, а относительное.
	Ответить | Правка | Наверх | Cообщить модератору

	366. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 25-Сен-24, 14:33
	>> Насколько оно актуально сейчас? > Актуально. Но тут тебе придётся верить мне на слово, потому что у меня нет ссылки, я не сохранял её в закладках, потому что не думал, что кому-нибудь она будет полезна. Да, без проблем. У меня познания в настолько низкоуровневом программинге не слишком большие. Поэтому и спрашиваю) > Там была именно ситуация зиллионов инстансов этих структур. Мои познания оказались еще хуже чем я думал) Насколько я понимаю, это утилита для стат. анализа кода. Т.е она проверяет корректность кода и какие-то синтаксические ошибки. Но стат анализаторов для СИ дофига, чем это настолько крут? Что будет если она замедлится? Ядро будет тормозить или просто дольше собираться? > Это знания, которые при программировании под DOS считались азами программирования на C, которые усваивались вместе с синтаксисом C, но видимо свежим поколениям программистов это уже дают элективным курсом, и некоторые пропускают. Так на СИ молодым ИМХО особо нет смысла даже учиться. Только если идти в эмбедедщину или пилить ядро и прочие легаси. > твой код будет работать примерно на 10% быстрее. Тут уже работает даже не абсолютное снижение размера, а относительное. Вот это меня и напрягает. В таком коде ошибиться очень легко. Стоит ли ускорение аж на 10% повышения шанса поймать какую-то бяку? Вон интел наускорял +5%, а потом отгреб со спектрами и мелтдаунами. Ps а что ты думаешь про последнее интервью Торвальдса и его заявление "You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management."
	Ответить | Правка | Наверх | Cообщить модератору

	344. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (343), 25-Сен-24, 00:05
	> по поводу работы с памятью, ошибки *alloc'ов - это всегда не более, чем проверка errno Господи, 21 век на дворе! Проверка errno :)) (скупая слеза пробежала по лицу сишаописта) Почему ты не пишешь на C#? Отличный язык, громаднейшая библиотека, корпорация за плечами, признание рынка... это ж мечта! Но нет, луддиты нихьт! Будут сипипискать, растаманить, даже пестонить, но на неправославном C# писать не будут! :))
	Ответить | Правка | К родителю #251 | Наверх | Cообщить модератору

	350. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от мяв (?), 25-Сен-24, 09:11
	зпочему ты так уверен в своих экстрасенсорных способностях? проект изначально на cs и был) но, как, надеюсь, сишарпист, понимаешь, clr нигде, кроме винды, макоси и линукса не пашет. стояла задача следовать POSIX'у.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+1 +/–
	Сообщение от Аноним (238), 23-Сен-24, 12:35
	$cat test.cc int main(int argc, char **argv) {   int k = 0x7fffffff;   k += argc;   return 0; } $clang++ -fsanitize=undefined test.cc ./a.out test.cc:3:5: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int' Проект Clang также делает статический анализатор, наверное в нём этот самый пресловутый искусственный интеллект уже есть. А вообще, с Clang надо осторожней, столкнулся с ошибками в компиляторе и отладчике. Ещё бывает что Clang генерирует совершенно левый код, бессмысленный, который только замедляет работу. По-правильному, нельзя доверять ни одному компилятору, надо дизассемблировать все свои программы и проверять.
	Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

	253. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 23-Сен-24, 16:07
	статический - это когда Вы файл кидаете и он Вам тыкает сразу. а тут - скомпиль, запусти и молись еще, что на свою ошибку наткнешься. иногда довольно сложно это все отлавливать, даже с ubsan'ами
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (254), 23-Сен-24, 16:44
	Может тогда лучше использовать не С, а С++ ? С++ настолько ненадёжный , что валится от любой ошибки. Программа на С++ строится на невидимом каркасе обработки исключений (даже если в программе нет кода выброса и ловли исключений). этот каркас очень хрупкий, и ломается почти от любой ошибки, хоть с памятью, хоть с потоками. Ошибку будет невозможно не заметить, потому что выдаст странное исключение или abort. Если что, можно и valgrind'ом проверить.
	Ответить | Правка | Наверх | Cообщить модератору

	274. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 23-Сен-24, 23:01
	так тогда б я раст предпочла. стоит задача posiх'у следовать
	Ответить | Правка | Наверх | Cообщить модератору

229. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
Сообщение от Анониматор (?), 23-Сен-24, 10:53
uucp, m4... некрофилия какая-то
Ответить | Правка | Наверх | Cообщить модератору

	340. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (343), 24-Сен-24, 23:45
	Зато это родные трупы! :)) На них завязаны какие-нть перделки (на m4 точно). Хотя мне слабо верится, что с 70-го года рынок юникса настолько остался тухлым. Вернее, сама ИТ отрасль! Появилась мультимедия - звук, видосы, всякая биг дата, блокчейны, сошиал-сервисы... а линynсисты всё текст по пайпам гоняют! Это же глупо и устарело лет 30 назад. Набор утилит уже давно должен быть другой, с переосмыслением под современность.
	Ответить | Правка | Наверх | Cообщить модератору

245. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	–2 +/–
Сообщение от freehck (ok), 23-Сен-24, 14:07
> не планирует обеспечивать совместимость с утилитами GNU, функциональность которых воспринимается авторами как необоснованно раздутая мало ли, что они и как воспринимают если не обеспечат полную совместимость, то пользователи сами не поменяют один инструмент на другой и если нет административного ресурса в лице red hat, то не светит им нифига
Ответить | Правка | Наверх | Cообщить модератору

	247. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Фнон (-), 23-Сен-24, 14:31
	> если не обеспечат полную совместимость, то пользователи сами не поменяют один инструмент на другой Если их не будет устраивать новый. Например - они не работают с некрософтом. > и если нет административного ресурса в лице red hat, то не светит им нифига Именно для этого нужна красношапка - чтобы выкидывать устаревший мусор. Т.к если неколюбов слушать - то до сих пор на телеге с лошадь передвигались.
	Ответить | Правка | Наверх | Cообщить модератору

	288. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 24-Сен-24, 00:04
	так-то POSIX'овая реализация старше гнутой.
	Ответить | Правка | Наверх | Cообщить модератору

	289. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 24-Сен-24, 00:05
	полную совместимость обеспечивают со стандарнтом, а не с докой левой реализации.
	Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

	355. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 25-Сен-24, 11:38
	А почему тогда у нас есть POSIX-certified и Formerly POSIX-certified (хотя автотесты эти ʼбывшиеʼ проходят) ? Но еще есть Mostly POSIX-compliant - наверное 'POSIX на полшишечки'. Причем в последних вполне распространенные системы типа Android, Darwin и тадам Linux (кроме нескольких дистрибутивов). Так что обеспечение полной совместимости, на мой взгляд бесполезная фигня. Но я конечно не знаю какую задачу ты решаешь, может там это обязательно, что прям кровь-из-носу.
	Ответить | Правка | Наверх | Cообщить модератору

	358. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 25-Сен-24, 13:08
	потому что у одних есть сомвместимость и бумажка, а у других - бумажки нет. >наверное 'POSIX на полшишечки'. "POSIX на 90+% шышечки" в основном. зависет от реализации. вообще, я к тому вела, что не ясно, чем и как реализовывать GNU-расширения: ни стандарта, ни процедуры принятия, ничерта. только доки от авторов, не гарантирующие и не принятые формально никем.
	Ответить | Правка | Наверх | Cообщить модератору

	362. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 25-Сен-24, 13:28
	> вообще, я к тому вела, что не ясно, чем и как реализовывать > GNU-расширения: ни стандарта, ни процедуры принятия, ничерта. только доки от авторов,  не гарантирующие и не принятые формально никем. Здорово, правда! (с) От так и живем. Но если вернуться к сабжу - то на фоне всего остального "отсутствие совмести с ГНУ" это будут проблемы ГНУшников) А кому надо - тот будет использоватью
	Ответить | Правка | Наверх | Cообщить модератору

	356. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от freehck (ok), 25-Сен-24, 12:01
	> полную совместимость обеспечивают со стандарнтом, а не с докой левой реализации. очевидно, что Вы никогда не задумывались о том, откуда появляются стандарты почитайте на досуге, Вас ждёт много интересных открытий
	Ответить | Правка | К родителю #289 | Наверх | Cообщить модератору

	357. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от мяв (?), 25-Сен-24, 13:02
	как, очевидно, и 100500 систем, реализующих POSIX. поэтому совершенно наплевать.
	Ответить | Правка | Наверх | Cообщить модератору

364. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
Сообщение от мяв (?), 25-Сен-24, 14:19
потратила только что 30 мин на написание 2х комментариев. ве, короче,ухожу с опеннета, ловите на слове!
Ответить | Правка | Наверх | Cообщить модератору

	367. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (-), 25-Сен-24, 14:35
	> потратила только что 30 мин на написание 2х комментариев. > ве, короче,ухожу с опеннета, ловите на слове! Ну с тобой хотя бы поговорить как с человеком можно. Напоминает темы на ЛОРʼе где могут 10 страниц обсуждать особенность UB в С++. Но работать тоже приходится))
	Ответить | Правка | Наверх | Cообщить модератору

	370. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от Аноним (369), 25-Сен-24, 21:21
	Женщины так всегда, сначала ворвутся в душу ... то есть, я хотел сказать, в чат, а потом убегут, оставив в недоумении: что это было?
	Ответить | Правка | К родителю #364 | Наверх | Cообщить модератору

	375. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
	Сообщение от freehck (ok), 03-Окт-24, 13:54
	> ве, короче,ухожу с опеннета, ловите на слове! Слова хватило аж на неделю. =)
	Ответить | Правка | К родителю #364 | Наверх | Cообщить модератору

371. "Набор POSIX-утилит и декодировщик AV1, написанные на Rust"	+/–
Сообщение от Аноним (-), 26-Сен-24, 07:48
А как быстро это работает на Raspberry Pi?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема