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

"Уязвимость в подсистеме io_uring, позволяющая получить привилегии root"	+/–
Сообщение от opennews (ok), 01-Апр-24, 11:23
В интерфейсе асинхронного ввода/вывода io_uring, предоставляемом ядром Linux, выявлена уязвимость (CVE-2024-0582), позволяющая непривилегированному пользователю получить права root в системе. Для эксплуатации уязвимости достаточно обычного локального доступа к системе, без необходимости манипуляций с пространствами имён. В настоящее время публично доступен работающий эксплоит, а также подробно описана вторая техника эксплуатации уязвимости... Подробнее: https://www.opennet.me/opennews/art.shtml?num=60891
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Bklrexte (ok), 01-Апр-24, 11:23	+6 +/–
Немного не понимаю, почему с io_uring так много уязвимостей.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #18, #22, #65, #87

4. Сообщение от Аноним (4), 01-Апр-24, 11:28	+/–
Автора этого поделия давно пора взять на карандаш: не первая его уязвимость и что-то мне подсказывает, что не последняя.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #24, #30, #44

5. Сообщение от Аноним (11), 01-Апр-24, 11:29	+/–
Наверное, имеет смысл отключать сабж, вроде нигде кроме qemu и не используется (хотя ускорение обещают приятное в теории). Лично я давно отключил -- если я не использую, никакого смысла держать этот бэкдор ядре. Ну а кто там дистрибутивные ядра со всеми бэкдорами использует, тем только страдать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #101

6. Сообщение от Аноним (-), 01-Апр-24, 11:36	+2 +/–
Сначала подумал, что это шутка, ведь сегодня День Дурака. А потом решил, это же use-after-free и получение рута, и с таким не шутят) В общем классическая уязвимость "позволяющая непривилегированному пользователю получить права root в системе" да еще и с рабочим эксплойтом. Хорошо, что это совсем-словсем не связанно с используемым языком, и возможностями по отстрела ног которые он дает.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19

7. Сообщение от Аноним (11), 01-Апр-24, 11:36	+/–
Правда, в libuv собирались добавить, и вот это поделие ускорить бы неплохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от Аноним (8), 01-Апр-24, 11:38	+/–
Какого лешего io_uring можно отключить только переконпеляцией? Почему не сделают аргумент командной строки, чтоб можно было продолжать использовать дистрибутивные ядра, но без io_uring?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10

10. Сообщение от НяшМяш (ok), 01-Апр-24, 11:48	+4 +/–
https://docs.kernel.org/next/admin-guide/sysctl/kernel.html#... Должен быть доступен с версии ядра 6.6
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #13

11. Сообщение от Аноним (11), 01-Апр-24, 11:50	+2 +/–
Как я слышал, это от того, что ядро не разрабатывалось поддерживать такие вещи, и пихают невпиху3мое. А на модернизацию уйдёт ещё не одно десятилетие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

12. Сообщение от Аноним (-), 01-Апр-24, 11:51	+2 +/–
Можешь автора этого поделия брать хоть за карандаш, хоть за что угодно. А толку, все равно у тебя нет замены для этой лабуды. Конечно ты мог бы взять и написать свой вариант асинк И/О, и я думаю, что у тебя бы получилось без ошибок, но это не точно) Гугл, который собственно и нашел уязвимость, пишет что 60% of the submissions exploited the io_uring component of the Linux kernel https://security.googleblog.com/2023/06/learnings-from-kctf-... Возможно поэтому они эту лажу отключили и в андроиде, и в хромоси. А лапчатые пусть сидят на бекдорах)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

13. Сообщение от Аноним (8), 01-Апр-24, 11:53	+1 +/–
Спасибо, мил-человек!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

18. Сообщение от Аноним (18), 01-Апр-24, 12:15	–17 +/–
> use-after-free Дело скорее в языке, чем в самом io_uring (но надо признать, что автор эпично прошел по всем граблям сишечки).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #21, #108

19. Сообщение от Аноним (19), 01-Апр-24, 12:17	–1 +/–
Да господи, язык тот тут причем? Если программист не хочет или не может банально обнулить указатель после освобождения памяти, то увы, вина того, кто пишет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #23, #26, #27, #51, #70, #83, #103

21. Сообщение от Аноним (21), 01-Апр-24, 12:34	+/–
Ага ага https://github.com/Speykious/cve-rs
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #25, #28, #41, #45, #143

22. Сообщение от Аноним (22), 01-Апр-24, 12:34	+3 +/–
Мне кажется система io_ring немного переусложнена там слишком много флагов, опций и режимов. Им нужно было начинать как-то попроще с минимум опций, а когда уже точно протестировано хорошо добавлять свои опции понемногу. Ну и сама конструкция с  shared memory и кольцевыми буферами в ней не совсем уж простая в реализации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #57

23. Сообщение от Аноним (-), 01-Апр-24, 12:35	+2 +/–
Хм, а я что сказал что "виноват язык"? Понятно что програмер если захочет, то может сделать и один free, и два, и десять. А потом попробовать обратиться к мертвому объекту. Но представь у тебя есть две дороги, одна двухполосная без отбойника, а другая такая же но с отбойником. Как думаешь, где плохих аварий будет больше?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

24. Сообщение от Аноним (22), 01-Апр-24, 12:38	+/–
Просто он как-то переусложнил всё, там миллион разных флагов, поэтому и уязвимости сыпятся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

25. Сообщение от Аноним (-), 01-Апр-24, 12:44	–3 +/–
К чему твой висер типа "а у вас негров линчуют"? Тред для растохейта на две тамы выше, дружок-пирожок. У нас тут тема про то, что очередной погромист, любитель дыряшек, выдавил из себя такой код, что RCE в ядре была почти год. И спасибо гуглу и его программистам, что они делают опенсорс лучше, а то тыщящи глаз как-то ничига не видят
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #54, #55

26. Сообщение от Аноним (26), 01-Апр-24, 12:49	–1 +/–
> Да господи, язык тот тут причем? При том, что он не должен не должен пропускать подобные банальные штуки. Если язык не может, значит нужно использовать чекеры, санитайзеры и прочие утилиты для обнаружения детских ошибок. Если ни язык, ни экосистема этого языка не позволяют создать 100% защиту от подобных ошибок, значит виноват язык. Здесь часто говорят, что "проблем нет, надо просто использовать простой советский...", но что-то в больших проектах никак не найдёт способ избавиться от детских болезней. Вывод очевиден - это невозможно, и виной - язык.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #33, #43

27. Сообщение от Аноним (27), 01-Апр-24, 12:53	–3 +/–
В нормальных же языках такое в принципе нельзя сделать. Памятью там управляет не программист, а сборщик мусора.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #32, #34

28. Сообщение от Аноним (28), 01-Апр-24, 12:53	+6 +/–
> Ага ага > https://github.com/Speykious/cve-rs Ну давай посмотрим, че там: pub fn segfault() -> ! {        let null = crate::null_mut::<u8>();         *null = 42; Смотрим, че эт за самописный null_mute: /// Equivalent to [`std::ptr::null()`], but returns a null reference instead. pub fn null<'a, T: 'static>() -> &'a T {         crate::transmute(0usize) } далее оно уходит в велосипедно-обфусцированный transmute, в общем раз "equivalent", то заменяем на оригинал: +++ b/src/segfault.rs @@ -7,7 +7,7 @@ /// /// See [`crate::transmute()`] pub fn segfault() -> ! { -       let null = crate::null_mut::<u8>(); +       let null = std::ptr::null_mut::<u8>();         *null = 42; и вуаля: cargo build    Compiling cve-rs v0.6.0 (/tmp-build/seg/cve-rs) error[E0133]: dereference of raw pointer is unsafe and requires unsafe function or block   --> src/segfault.rs:11:2    | 11 |     *null = 42;    |     ^^^^^^^^^^ dereference of raw pointer    |    = note: raw pointers may be null, dangling or unaligned; they can violate aliasing rules and cause data races: all of these are undefined behavior For more information about this error, try `rustc --explain E0133`. error: could not compile `cve-rs` (lib) due to previous error В общем, опеннетный Военов Супротив Раста опять развели, как кроликов ... Главное, повторять почаще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #76

29. Сообщение от Аноним (29), 01-Апр-24, 12:55	+/–
Что такое этот io_uring и можно ли его отключить? И да, кто-то тестил у себя этот эксплоит? Что он делает с системой?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #42

30. Сообщение от Аноним (22), 01-Апр-24, 13:10	+1 +/–
В любом случае если его правильно реализовать это выходит самый эфиктивный способ i/o общения с ядром.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #38

32. Сообщение от Аноним (22), 01-Апр-24, 13:17	+4 +/–
При написании ядра сборщики мусора обычно неработают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #48

33. Сообщение от ИмяХ (ok), 01-Апр-24, 13:18	+/–
>>значит нужно использовать чекеры, санитайзеры и прочие утилиты для обнаружения детских ошибок Но почему-то никто этого не сделал перед тем, как принять код в ядро. Ни комитет, который принимает патчи, сам Линус, ни мейнтейнеры, ничего не сделали, чтобы предотвратить это. Либо делали, но намерено скрывали, чтобы продать информацию троянописателям.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #35, #60

34. Сообщение от Аноним (11), 01-Апр-24, 13:29	+2 +/–
Ты хотел сказать в игрушечных языках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #50, #144

35. Сообщение от Аноним (-), 01-Апр-24, 13:32	+/–
> Но почему-то никто этого не сделал перед тем, как принять код в ядро. Ни комитет, который принимает патчи, сам Линус, ни мейнтейнеры, ничего не сделали, чтобы предотвратить это. Либо делали, но намерено скрывали, чтобы продать информацию троянописателям. Давай воспользуемся бритвой Хэнлона и попытаемся не приписывать "злому умыслу то, что вполне можно объяснить глупостью". То, что пограмисты на СИ зачастую не пользуются санитайзерами и даже иногда не пишут тесты, это распространненная проблема. Думаю причин тут много, начиная от лени: 'ну я уже написал код, он компилируется и даже рабоатет, чего вы от меня еще хотите!', заканчивая непомерным ЧСВ: 'СИ программмеры это же илита! они в само ядро свой код навыпрограммировали. это же профи, как они могут ошибаться!' Еще можно вспомнить классные аргументы от самых знающих анонимов "автотесты долго бегут, я нехочу ждать даже 10 минут!", "настоящие программисты таких глупых ошибок не делают", и "я просто проверяю код и все работает" от Профессор Навигатор. А то что это 'приняли в ведро'? Ну так у тебя есть выбор, или взять что есть, или сидеть без нужных компонентов, тк писать это некому, или писать самому. Как ты думаешь почему драйвер от самсунг приняли? Ну тот в котором потом нашли кучу уязвимостей и который, как выяснилось, писал бедный раб с галеры, тянувший то ли 3, то ли 4 проекта одновременно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #122

38. Сообщение от Аноним (38), 01-Апр-24, 13:41	+1 +/–
Действительно, надо всего лишь правильно реализовать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

39. Сообщение от Аноним (-), 01-Апр-24, 13:41    Скрыто ботом-модератором	–1 +/–
Как важно использовать SELinux, который обеспечивает контроль и аудит io_uring.
Ответить | Правка | Наверх | Cообщить модератору

40. Сообщение от uis (??), 01-Апр-24, 13:45	+/–
Многопоток опять гадит
Ответить | Правка | Наверх | Cообщить модератору

41. Сообщение от Аноним (18), 01-Апр-24, 14:10	+5 +/–
Эпичный тред, в котором это пытаются заставить работать - https://github.com/Speykious/cve-rs/issues/4 Если для случайного выстрела в ногу, как в сишечке, нужен консилиум из нескольких программистов и несколько дней упорных попыток выйти за границы буфера - то это эпик фейл растохейтров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

42. Сообщение от Аноним (-), 01-Апр-24, 14:10	+1 +/–
> Что такое этот io_uring man io_uring или хотя бы wikipedia.org/wiki/Io_uring > и можно ли его отключить? В ядра 6.6+ можно. https://docs.kernel.org/next/admin-guide/sysctl/kernel.html#... >Что он делает с системой? Он получает рут и больше ничего не делает. Потому что пруф, а не зловред. А в реальности он бы делал что хотел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

43. Сообщение от Витюшка (?), 01-Апр-24, 14:16	+/–
В ядре часто код который в main попадает тупо банально даже не компилируется!!! На это раз жаловался сам Линус. Так что до стадии "виновата С дыряшка" там просто не дошли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #46

44. Сообщение от iPony129412 (?), 01-Апр-24, 14:18	+1 +/–
А кто останется?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

45. Сообщение от Анонин (-), 01-Апр-24, 14:24	+3 +/–
Ой, да ладно вам гнать на этот проект. Он и аналогичные очень полезны! Благодаря им можно найти в расте soundness и исправить. Потому что бездумно верить что багов нет - просто преступление. Так что пусть чуваки развлекаются разными извращениями и в итоге делают раст еще лучше и надежнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

46. Сообщение от Анонин (-), 01-Апр-24, 14:27	+/–
> в main попадает тупо банально даже не компилируется Серьезно? А можно ссылки на PR или обсуждения? Потому что это... это даже не неуважение к участникам, а какая-то профнепригодность какая-то. У нас бы такого разраба бы просто уволили, если бы не исправился. PS: как вообще можно залить некомпилируемый код? Его же CI не пропустит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #61, #75

47. Сообщение от Аноним (19), 01-Апр-24, 14:36    Скрыто ботом-модератором	–1 +/–
Похоже пора переписывать ядро!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #64

48. Сообщение от Аноним (27), 01-Апр-24, 14:38	+/–
Ответ был на фразу "да причем здесь языки вообще". Что стоит использовать или нет в ядре - это существенный вопрос конечно, но другой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

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

50. Сообщение от Аноним (27), 01-Апр-24, 14:42	–2 +/–
Ок, продолжайте использовать неигрушечные, позволяющие заинтерисованным лицам всегда иметь незакрытые дыры в линуксах
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

51. Сообщение от Аноним (-), 01-Апр-24, 14:48	+/–
Ну обнулишь ты указатель, можешь даже сделать memset(ptr, 0, len), а сишечка возьмет да и выбросит твое обнуление. О - оптимизация. https://wiki.sei.cmu.edu/confluence/display/c/MSC06-C.+Bewar...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #69, #98

54. Сообщение от Стив Балмер (?), 01-Апр-24, 14:59	+5 +/–
так гугл как и мягкие это часть тысячеглаза, ты что не знал ? у них же куча продуктов на линь завязана, вот и стараются
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #102, #149

55. Сообщение от Аноним (55), 01-Апр-24, 15:06	+/–
Тот же гугл не стал завозить Rust в Chrome, а решил свои проблемы с безопасностью памяти активным использованием санитайзеров включая MiraclePtr. Так что да, они делают опенсорс лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #68

57. Сообщение от Аноним (-), 01-Апр-24, 15:22	+/–
Не, не сработает. Сразу начнется вой и нытье, что 'именно это флажок мне нужен', 'добавьте немедленно', 'работало, а вы все сломали', 'вы мне обязаны, 'я вашим ио-рингом пользуюсь' Уже такое проходили с вейландом, когда с нуля начали создавать и реализовывать протоколы, так  фанаты иксов ноют до сих пор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #105

60. Сообщение от Аноним (60), 01-Апр-24, 15:27	+/–
Сам Линус как был замшалым финским студентом с версией 0.1, так и остался им на всю жизнь. Отсюда и все беды Linux. В академических осях инновации более осмысленные. Как следствие, проблемы намноооого реже. Линуса от управления разработкой ядра надо давно смещать. Сейчас в ядро тянется все подряд, а Линус, как собачка на торпеде, одобрительно на всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #90

61. Сообщение от User (??), 01-Апр-24, 15:27	+1 +/–
> PS: как вообще можно залить некомпилируемый код? Его же CI не пропустит. Хе-хе-хе. Какой-такой си-ай хен-тай? Мы такого не знай - вон, оно в почту пролезай - фигли еще надо?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

64. Сообщение от Аноним (60), 01-Апр-24, 15:35	+/–
Так уже есть почти готовый Hurd или Plan9. Пора кому-то авторитетному закопать у себя Linux. Глядишь и другие потянутся к новому.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #66, #85, #89

65. Сообщение от Аноним (65), 01-Апр-24, 15:42	+/–
По той же причине, что и в BPF, nftables. Не отловили ещё всех багов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

66. Сообщение от Аноним (65), 01-Апр-24, 15:44	+/–
А они тоже на Сишке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

67. Сообщение от Аноним (67), 01-Апр-24, 15:45	+1 +/–
> Проблема проявляется начиная с выпуска ядра Linux 6.4 Новые выпуски ядра должны решать проблемы, а не создавать их
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #71, #74

68. Сообщение от Анонин (-), 01-Апр-24, 15:54	+/–
> Тот же гугл не стал завозить Rust в Chrome Точно не стал? А то тут chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/rust.md#Rust-in-Chromium какие-то чуваки пишут: "The Rust toolchain is enabled for and supports all platforms and development environments that are supported by the Chromium project. The first milestone to include full production-ready support was M119. Rust is approved by Chrome ATLs for production use in certain third-party scenarios." MiraclePtr себя не оправдал. Там улучшение ~57% при значительном потреблении ресурсов. https://www.opennet.me/opennews/art.shtml?num=60482
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

69. Сообщение от Аноним (19), 01-Апр-24, 16:08	+/–
Ну тогда asm volatile заинлайнить, где тупо xor делается, такое по идее не должно никакой оптимизацией аннигилироваться Да, это добавляет супер лоулевел зависимость от конкретной архитектуры, но не вижу в этом проблемы вообще Вообще конечно забано читать и наблюдать этот хейт в сторону си и всевозможное облизывание раста Причем, я лично склонен считать что все эти фишки растовские, с безопасной работой с памятью, в целом и на далекую переспективу очень слабо способны как-то повытить культуру написания безопасного кода, если вообще способны Вот я о чем: если раст такое позволяет из коробки делать, то велик шанс того, что такие концепции работы с памятью вообще могут стереться из общественного сознания через пару поколений Ведь все и так работает, то в сознании большинства так будет работать и на любом другом языке
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #73, #81, #84

70. Сообщение от fidoman (ok), 01-Апр-24, 16:14	–1 +/–
Угу, а также найти все прочие указатели на эту область памяти, и тоже обнулить. И ядру сказать, вот я передавал указатель при вызове асинхронной функции, его тоже обнули. Если бы всё так просто решалось...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

71. Сообщение от Аноним (73), 01-Апр-24, 16:20	+1 +/–
>> Проблема проявляется начиная с выпуска ядра Linux 6.4 > Новые выпуски ядра должны решать проблемы, а не создавать их Если бы так было, то ядро стало бы мегастабильным. И тогда вся орава писак просто стала бы ненужна. А как бродатый комми говорил? "на GPL коде можно заработать только на поддержке и/или исправлении уязвимостей". Вот они и стараются)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #80

73. Сообщение от Аноним (73), 01-Апр-24, 16:33	+1 +/–
> Да, это добавляет супер лоулевел зависимость от конкретной архитектуры, но не вижу в этом проблемы вообще Странно, обычно адепты СИ просто писаются от осознания сколько платформ поддерживается и насколько код переносимый. > Вообще конечно забано читать и наблюдать этот хейт в сторону си и всевозможное облизывание раста А чего СИ хейтить? Это просто как рагаться на пенсионера с деменцией. А вот тех, кто его посадил за руль автобуса.. > Причем, я лично склонен считать что все эти фишки растовские, с безопасной работой с памятью, в целом и на далекую переспективу очень слабо способны как-то повытить культуру написания безопасного кода, если вообще способны Ну культуры написания кода вообще и безопасной работы с памятью, в частности, СИ программимсты не развили и за 50 лет. Так что в худшем случае ничего не поменяется. А в лучшем, станет меньше тупых ошибок вида "я выщел за границы буфера, вот тебе руть!" > Вот я о чем: если раст такое позволяет из коробки делать, то велик шанс того, что такие концепции работы с памятью вообще могут стереться из общественного сознания через пару поколений Хахаха, а сейчас типа эти концепции есть? Вот вроде каждый погромист-дыряшечник знает "выделил память, очисти, только один раз", а толку? Одни и те же ошибки use-after-free, double-free и out-of-bounds из года в год. > Ведь все и так работает, то в сознании большинства так будет работать и на любом другом языке В сознании большинства компутер работает на магии)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

74. Сообщение от BorichL (ok), 01-Апр-24, 16:39	+3 +/–
Да надо просто работать из-под учётки root, тогда на все эти уязвимости насрать  ;-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #86, #91, #92, #94

75. Сообщение от Витюшка (?), 01-Апр-24, 16:40	+/–
Естественно я сейчас не найду. Там очень много чего не работает на других архитектурах. Те код (общий) не компилируется под какую-то архитектуру, не то что не тестируется. На это Линус и жаловался. Какая-то там архитектура не помню, но не прямо какая-то экзотическая, risc-v типа того. Он в итоге завернул этот код (он прилетел из веток linux-next или какой-то подсистемы). Те он решил что-то сам ручками потестить, а оно даже не скомпилировалось :)) Ни про какие CI я не слышал в Linux kernel.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #79

76. Сообщение от Аноним (76), 01-Апр-24, 17:03	+1 +/–
Ну что-то вроде того ироничного репозитория с хэллоу ворлдом на расте на тысячи строк, собирающийся 5 часов. Не видел чтобы кто-то делал такое же на си, но думаю 5 часами компиляции они не отделались бы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #134, #148

79. Сообщение от Анонин (-), 01-Апр-24, 17:33	+2 +/–
Спасибо за пояснение. Нашел. То что на это сагрился сам Торвальдс всё существенно упростило)) "Your testing is seriously lacking. This doesn't even build." lore.kernel.org/dri-devel/CAHk-=wgPJttFz8yrdpPTN-ypMmDXHOKw9yi1nZSEq+7+tGftZA@mail.gmail.com/ Хорошо живут разрабы ядря. Вот мне, смузихлебу, нужно чтобы прошел линтер, код скомпилился под все целевые таргеты и прошли все тесты. И только тогда оно попадает на ревью. А если что-то меняешь - то тесты бегут заново. И ревью тоже сбрасывается(( С другой стороны, разрабы ядра люди занятые, на них большая ответственность. Поэтому они могут ответственно сказать "LGFM" и замерджить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

80. Сообщение от Аноним (80), 01-Апр-24, 17:34	+/–
> И тогда вся орава писак просто стала бы ненужна. А как бродатый комми говорил? "на GPL коде можно заработать только на поддержке и/или исправлении уязвимостей". Ссылку на цитату не приведёшь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #82

81. Сообщение от Аноним (-), 01-Апр-24, 17:47	+/–
> если раст такое позволяет из коробки делать, то велик шанс того, что такие концепции работы с памятью вообще могут стереться из общественного сознания через пару поколений Если будут не нужны, то сотрутся так же, как навыки разведения огня без зажигалки, или умение считать в уме без калькулятора. Если будут востребованы, то никуда они не денутся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

82. Сообщение от Аноним (-), 01-Апр-24, 17:59    Скрыто ботом-модератором	+2 +/–
> А как бродатый комми говорил? "на GPL коде можно заработать только на поддержке и/или исправлении уязвимостей". > Ссылку на цитату не приведёшь? О, я рад что ты спросил) Это очень просто. Находим тот всер, с которого началася ГНУ рак, а именно ГНУ Манифест. Вот его официальный перевод на русский на сайте сектантов. gnu.org/gnu/manifesto.ru.html Читаем: "Должны же программисты чем-то жить! На первый взгляд, это верно. Однако, есть множество способов, которыми программисты могли бы заработать на жизнь без продажи права пользоваться программой. ... Если вы захотите, то легко найдёте другие пути. Вот несколько примеров. Предприятие, предоставляющее услуги по обучению, помощи и поддержке, могло бы также нанять программистов. Люди с новыми идеями могли бы поставлять бесплатные программы, принимая дары от довольных пользователей или продавая услуги по помощи. Пользователи со сходными нуждами могут образовывать союзы пользователей и платить взносы. ... " Но кроме этого он еще много чего говорил. Например про налог на болванки, т.е я хотел сказть на ПО. "Допустим, каждый, кто покупает компьютер, должен платить N процентов стоимости как программный налог. Правительство передаёт его агентству вроде Национального научного фонда для вклада в развитие программ." Ну и еще пару цитат из того же документа "Платить программистам не перестанут, просто плата станет меньше." "Низкооплачивающие организации проигрывают высокооплачивающим, но они могли бы быть на том же уровне, если бы высокооплачивающие были запрещены." Комунякций выкидышь, любительлюбителей лолей хочет не только запретить высокие зарплаты, отправить программистов побираться подачками, но еще и всю индустрию положить под государство.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #113, #129

83. Сообщение от Аноним (-), 01-Апр-24, 18:06	+/–
> Да господи, язык тот тут причем? В этой уязвимости я б сказал язык действительно не при чём. > Если программист не хочет или не может банально обнулить указатель после освобождения памяти, то увы, вина того, кто пишет Но тут ты не прав коренным образом. Какой указатель ядро забывало обнулять? Оно освобождало память, в смысле помечало как освобождённую. Но не снимало маппинг и более того не хранило достаточно информации, чтобы знать, когда надо анмапить, а когда нет. Но и в целом, обнуление указателей -- это так себе защита от use-after-free, потому что он сценарий этого примерно такой:     free(p);     p = NULL; // давай положим в p ноль, как ты настаиваешь, чтобы не было use-after-free.     int *next_p = get_some_buffer();     *next_p = 42; // вот здесь этот next_p оказывается равен тому значению, которое уходило во free 3 строки назад, и вся твоя "защита" оказалась бесполезной Это сценарий упрощённый, с тем чтобы проще понять было. В реальности же значение адреса может быть было где-то сохранено нечаянно, и оно потом будет лежать три месяца, пока вдруг процесс не решит сделать что-нибудь такое, что он раз в полгода делает, и вот тогда он то значение извлечёт и наступит на грабли use-after-free. Чтобы не было use-after-free тебе надо перед тем, как делать free для адреса, найти _все_ указатели в памяти, хранящие этот адрес, обнулить все эти указатели кроме одного _локального_, после этого на последнем указателе вызывается free, и делается return. Последний указатель уже нет нужды обнулять. Но найти все указатели хранящие данный адрес в общем случае может только сборщик мусора. В специальном случае программист может следить за тем, чтобы адреса такого рода хранились бы каждый в единственном экземпляре, что делает поиск ненужным. Иногда программист знает, что адрес хранится здесь и (может быть) ещё там, и соответственно он проверяет это перед free. Но когда программа работает со сложными структурами данных в памяти, и когда она ещё жмётся выделять память из кучи, и постоянно пытается обойтись указателями на существующие объекты (типа подстрок например), то _нечаянно_ от простых правил поиска всех копий адреса в памяти, можно придти к необходимости полного mark-and-sweep. Что хуже, это "нечаянно" легко может остаться незамеченным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #112

84. Сообщение от Аноним (-), 01-Апр-24, 18:08	+1 +/–
> Вот я о чем: если раст такое позволяет из коробки делать, то велик шанс того, что такие концепции работы с памятью вообще могут стереться из общественного сознания через пару поколений Они либо полезные, либо их не так уж жалко. Родители рассказывали как картошку копать, в поездках в колхоз от университета. Моя бабаушка рассказывала как стирать белье в проруби и как косить корм скотине. Думаю ее родител могли бы рассказать как чистить примус или разжигать дровяную печку. Я уже молчу про древних-древних предков, которые рассказали бы (при помощи 50 звуков и нескольких жестов) как сделать надежную палку-копалку, выбрать кремнь для каменного наконечника и как свалить мамонта. Но мне эти навыки нафиг не упали. И я надеюсь, что и не понадобятся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

85. Сообщение от Аноним (-), 01-Апр-24, 18:13	+/–
GNU Hurd устарел ещё больше, а Plan 9 под лицензией MIT и мало кто будет в него вкладывать и потом это открывать. Но есть уже готовые L4, они успешно используются сейчас в миллиардах устройств, от микроконтроллеров и модемов до автомобилей. Вы можете попробовать их в Genode.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

86. Сообщение от Аноним (-), 01-Апр-24, 18:20	+/–
????? Поясни мысль. ты хотел сказать, что "не надо просто работать из-под учётки root".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #88

87. Сообщение от vitalif (ok), 01-Апр-24, 18:25	+3 +/–
Асинхронщина. А ядро хронически писали как синхронное тредовое г**но. Вылезают проблемы синхронизации :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #104

88. Сообщение от BorichL (ok), 01-Апр-24, 18:42	+1 +/–
> ????? Поясни мысль. ты хотел сказать, что "не надо просто работать из-под > учётки root". Нет, не надо быть зассыхой и надо работать из-под учётки root, тогда все уязвимости в получении прав root'а теряют смысл   ;-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

89. Сообщение от Аноним (89), 01-Апр-24, 19:13	+1 +/–
И съехать на 32 битные системы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

90. Сообщение от Аноним (65), 01-Апр-24, 19:20	+/–
Только вот академический Minix имеет практических использований раз (IntelME)... и всё, в отличие от неакадемического.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #99

91. Сообщение от Аноним (65), 01-Апр-24, 19:27	+2 +/–
Привет, чудный мир POSIX-DOS!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

92. Сообщение от вася (??), 01-Апр-24, 19:33	+/–
Нужно просто из квартиры выпилить входную дверь и тогда на все эти проблемы со взломом замков будет нacpaть
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

93. Сообщение от Андрей (??), 01-Апр-24, 19:41	+/–
 gcc exploit.c exploit.c:5:10: фатальная ошибка: liburing.h: No such file or directory     5 | #include "liburing.h"       |          ^~~~~~~~~~~~ компиляция прервана.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #95

94. Сообщение от Аноним (65), 01-Апр-24, 19:43	+/–
Просто заходи в /bin, /usr/bin, /sbin, /usr/sbin и свободно модифицируй любые файлы там. Да хоть все. И в чём прелесть, что для этого не надо ничего ломать. Вот тогда вирусам для Linux точно цвесть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

95. Сообщение от Аноним (95), 01-Апр-24, 19:50	+4 +/–
Не знаешь как подключить liburing.h? Фатальная ошибка!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #96

96. Сообщение от Андрей (??), 01-Апр-24, 20:52	+/–
выброс дофаминов получил ?:)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #97

97. Сообщение от Аноним (89), 01-Апр-24, 20:56	+/–
apt install liburing-dev
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

98. Сообщение от Аноним (98), 01-Апр-24, 21:24	+/–
Не совсем по теме, но очень нравится, как там взяли решение из документа комитета[1], но поменяли слова "некоторые компиляторы выкидывают volatile в нарушение стандарта" на "выкидывают в строгом соответствии со стандартом". "should work on any standard-compliant platform. There has been recent notice that some compilers violate the standard by not always respecting the volatile qualifier." ==> "calling functions and accessing volatile-qualified objects can still be optimized out (while maintaining strict conformance to the standard)" [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1381.pdf
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

99. Сообщение от Аноним (-), 01-Апр-24, 22:19	+/–
Подумаешь, сотни миллионов процессоров по всему миру. Вот тебе и академический код) А еще можно вспомнить всякие нетфликсы и амазоны. И старую маоксь... О, вспомнил еще про ThreadX, которая сейчас Azure RTOS - 20 лет в проде, более 12 миллиардов устройств, успешный коммерческий проект. Это тебе не дырявое ядро впаривать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

100. Сообщение от sena (ok), 01-Апр-24, 22:37	+/–
не компилируется cc     exploit.c   -o exploit exploit.c: In function ‘hppa_br_setup’: exploit.c:81:12: error: ‘struct io_uring_buf_reg’ has no member named ‘flags’    81 |         reg.flags = IOU_PBUF_RING_MMAP;       |            ^ exploit.c:81:21: error: ‘IOU_PBUF_RING_MMAP’ undeclared (first use in this function)    81 |         reg.flags = IOU_PBUF_RING_MMAP;       |                     ^~~~~~~~~~~~~~~~~~ exploit.c:81:21: note: each undeclared identifier is reported only once for each function it appears in exploit.c:90:15: error: ‘IORING_OFF_PBUF_RING’ undeclared (first use in this function); did you mean ‘IORING_OFF_CQ_RING’?    90 |         off = IORING_OFF_PBUF_RING | (unsigned long long) bgid << IORING_OFF_PBUF_SHIFT;       |               ^~~~~~~~~~~~~~~~~~~~       |               IORING_OFF_CQ_RING exploit.c:90:67: error: ‘IORING_OFF_PBUF_SHIFT’ undeclared (first use in this function); did you mean ‘IORING_CQE_BUFFER_SHIFT’?    90 |         off = IORING_OFF_PBUF_RING | (unsigned long long) bgid << IORING_OFF_PBUF_SHIFT;       |                                                                   ^~~~~~~~~~~~~~~~~~~~~       |                                                                   IORING_CQE_BUFFER_SHIFT
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #117

101. Сообщение от vitalif (ok), 01-Апр-24, 22:46	+/–
Я в витасторе юзаю))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

102. Сообщение от Минона (ok), 01-Апр-24, 22:59	+/–
Нет, Стиви, Гугл и Ко это другого типа "тыщиглаз", эти смотрят в код и видят баги, а те другие "тыщиглаз" смотрят в код а видят фигу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #110

103. Сообщение от Аноним (103), 02-Апр-24, 00:16	+/–
Шутите? Это вина только языка. Язык такие вещи должен как минимум предотвращать, как максимум не требовать. А C - это по современным меркам и не яп вовсе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

104. Сообщение от 1апреля (?), 02-Апр-24, 00:47	+2 +/–
А как надёжно отладить все возможные ситуации в асинхронке? Это не F5 в браузере нажать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

105. Сообщение от Аноним (105), 02-Апр-24, 01:13	+/–
Ну так может не надо с нуля переписывать то, что уже работает и чем люди пользуются? Говно же каждый раз выходит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #126

106. Сообщение от Аноним (-), 02-Апр-24, 03:12	+/–
>и доступа к соседним физическим страницам памяти опять RowHammer?
Ответить | Правка | Наверх | Cообщить модератору

108. Сообщение от adolfus (ok), 02-Апр-24, 09:41	+/–
Агент Байдена? Работаешь в команде дискредитации C и C++?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

109. Сообщение от Tron is Whistling (?), 02-Апр-24, 09:56	+1 +/–
Что, опять (tm) Ну вот зачем это в ядре по умолчанию, а. Кому оно нужно кроме полутора мегамонстров?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #145

110. Сообщение от Стив Балмер (?), 02-Апр-24, 10:29	+3 +/–
да не, вырви уже из себя это раболепие, тысячеглаз это уже давно не тока отшельники в замызганных свитерах, это также и галстучники работающие на разные компании. Проблемы в коде замечают и те и другие, но твой ум зачем-то акцентирует внимание тока на вторых выделяя их в особую касту.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #111

111. Сообщение от Аноним (-), 02-Апр-24, 10:55	+/–
> Проблемы в коде замечают и те и другие, но твой ум зачем-то акцентирует внимание тока на вторых выделяя их в особую касту. Ага, вроде зачечают и те, и те, но почему-то заметил чел из майкрософта)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #114, #135

112. Сообщение от n00by (ok), 02-Апр-24, 11:44	+/–
> Но найти все указатели хранящие данный адрес в общем случае может только > сборщик мусора. В частном хватает std::shared_ptr<>. > В специальном случае программист может следить за тем, чтобы > адреса такого рода хранились бы каждый в единственном экземпляре, что делает > поиск ненужным. Это делает std::unique_ptr<>. А Rust что делает? unique_ptr выполняет на этапе компиляции, а в остальных случаях просто бьёт по руками и не позволяет написать код? Или там свой std::shared_ptr<> для неопределённого на этапе трансляции количества указателей?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #118, #141

113. Сообщение от n00by (ok), 02-Апр-24, 11:51	+/–
> но еще и всю индустрию положить под государство. Вот это единственно, что неверно. Он хотел государство (на нём обязательство собирать налог) положить под Фонд (на ком привилегия распоряжаться средствами).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #115, #119, #132

114. Сообщение от Аноним (-), 02-Апр-24, 11:56	+1 +/–
Так ведь заметил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

115. Сообщение от Аноним (-), 02-Апр-24, 11:58	+/–
Прямо как НТИ ИТ Роса, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #120

117. Сообщение от n00by (ok), 02-Апр-24, 12:26	+/–
Потому что в 2.5 этого нет https://github.com/axboe/liburing/commit/9c6689848ebf79a5830... Брать надо из git
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

118. Сообщение от Аноним (-), 02-Апр-24, 12:26	+/–
> unique_ptr выполняет на этапе компиляции Если очень-очень упрощенно - то да. Только unique_ptr нужно проверять на empty, а тут не нужно. > а в остальных случаях просто бьёт по руками Да, и соответствующими ошибками компиляции намекает что нужно исправить код или использовать другие примитивы. > и не позволяет написать код Не позволяет писать заведомо невалидируемый код. Но у раст есть свои аналоги shared_ptr: Rc - Single-threaded reference-counting pointer (doc.rust-lang.org/std/rc/struct.Rc.html) Arc - Thread-safe reference-counting pointer (doc.rust-lang.org/std/sync/struct.Arc.html)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #123

119. Сообщение от Аноним (-), 02-Апр-24, 12:29    Скрыто ботом-модератором	+/–
> Вот это единственно, что неверно. Единственно?? Т.е. ввести уравниловку по зарплатам это верно? Их уменьшение - тоже? И наказание за закрытый код тоже верно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #121

120. Сообщение от n00by (ok), 02-Апр-24, 12:42	+/–
У Столлмана никогда не было той власти, как у владельца того "Центра". Да и последний в одиночку вряд ли бы рискнул столь опасную игру с казной затеять, потому и вылетел из правительства не один (но, похоже, пока ещё не со всеми эээ... партнёрами).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

121. Сообщение от n00by (ok), 02-Апр-24, 12:44	+/–
>> Вот это единственно, что неверно. > Единственно?? > Т.е. ввести уравниловку по зарплатам это верно? > Их уменьшение - тоже? > И наказание за закрытый код тоже верно? "Верно", в смысле, намерения определены верно. То, что сама затея гнилая - это уже другой вопрос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

122. Сообщение от ProfessorNavigator (ok), 02-Апр-24, 12:54	+/–
> Еще можно вспомнить классные аргументы от самых знающих анонимов "автотесты долго бегут, я нехочу ждать даже 10 минут!", "настоящие программисты таких глупых ошибок не делают", и "я просто проверяю код и все работает" от Профессор Навигатор. Профессор всё видит. На экзамене встретимся)) А касательно проверки - единственная гарантия того, что код будет работать, как задумано - полное и тщательное тестирование всех функций и сценариев работы. Всё. Остальное никаких гарантий не даёт. Точнее даёт - что вы напихаете ещё больше ошибок. Если на тестировании код не работает, как задумывалось, и вы не может понять, в чём причина, только тогда можете воспользоваться системами автоматической проверки. Чтобы выявить проблемный участок. Затем переписать, и снова на тест. Повторять до получения приемлего результата.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

123. Сообщение от n00by (ok), 02-Апр-24, 13:02	+/–
>> и не позволяет написать код > Не позволяет писать заведомо невалидируемый код. > Но у раст есть свои аналоги shared_ptr: > Rc - Single-threaded reference-counting pointer (doc.rust-lang.org/std/rc/struct.Rc.html) Не подходит, код ядра выполняется в произвольном потоке. > Arc - Thread-safe reference-counting pointer (doc.rust-lang.org/std/sync/struct.Arc.html) The type Arc<T> provides shared ownership of a value of type T, allocated in the heap. В ядре в общем случае нет кучи. If you need to mutate through an Arc, use Mutex, RwLock, or one of the Atomic types. То есть выбор сводится к: 1. Написать заведомо невалидируемый код. 2. Висеть в примитивах синхронизации, как и в наивной реализации std::shared_ptr.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #125, #142

125. Сообщение от Аноним (-), 02-Апр-24, 14:51	+/–
Для ядра возможно есть специальные конструкции. Но какие именно не скажу, это нужно лезть в соответствующую ветку rust-for-linux и смотреть что нового. Или в ядро, если кода уже перенесли. Но т.к. я ни разу не ядерщик, то умываю руки)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #137

126. Сообщение от Василий (??), 02-Апр-24, 14:53	–1 +/–
> Ну так может не надо с нуля переписывать то, что уже работает и чем люди пользуются? Говно же каждый раз выходит. Это же ты про X windows system  написал, который переписывали и форкали за его историю множество раз?. И всё равно дырявое получилось как ни старались.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

129. Сообщение от Аноним (-), 02-Апр-24, 15:56    Скрыто ботом-модератором	+/–
Смесь лжи, выдёрганных из контекста цитат. Жалок ты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #130

130. Сообщение от Аноним (-), 02-Апр-24, 16:05	+/–
> Смесь лжи, выдёрганных из контекста цитат. Жалок ты. Т.е просто ты просто высарл свое сообщение без аргументов, зато с оскорблениями? Даже по делу ничего не скажешь? Правда глазенки колет? Поехавший комми прямо говорит "давайте запретим большие зарплаты! давайте введем налог на железо", а ты его тут выгораживешь 'вы не понимаете контекста! шмук-пляк!' Да тебе все будет божья роса)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

132. Сообщение от Аноним (-), 02-Апр-24, 16:22	+/–
>> но еще и всю индустрию положить под государство. > Вот это единственно, что неверно. > Он хотел государство (на нём обязательство собирать налог) положить под Фонд (на ком привилегия распоряжаться средствами). Не соглашусь, тк он в пример приводит агенство "вроде Национального научного фонда". А этот самый фонд NSF в штатах является вроде независимым и его стратегия даже определяется определяют 24 членами Национального научного совета. Но! Непосредственно работой фонда руководят правление и директор, которых назначает президент США и утверждает в должности Сенат. Может борода хотел чтобы его назначили на хлебную должность, не думаю что мы этого не узнаем. Но то, что получившийся орган был бы государственным это, ИМХО, однозначно. Что интересно в СССР в 70х (с 66 года) создавался ГосФАП (Государственный фонд алгоритмов и программ). Не отправляли тогда еще молодого студента из сша в союз, осваивать практику "отнять и поделить"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #136

134. Сообщение от Аноним (134), 02-Апр-24, 16:28	+1 +/–
> Не видел чтобы кто-то делал такое же на си Правильно. Потому что программисты на Си работают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

135. Сообщение от Стив Балмер (?), 02-Апр-24, 17:15	+/–
>Ага, вроде зачечают и те, и те, но почему-то заметил чел из майкрософта) чел из крупной ИТ компании бесплатно "поработал" тысячеглазом на общее дело, честь и хвала ему. или может у тебя особый паитет перед членами из майкрософта ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

136. Сообщение от n00by (ok), 02-Апр-24, 17:35	+1 +/–
Что Столлман срисовал идею с ГосФАП - вполне возможно. Есть и версия по этому поводу, что ЦРУ посчитали хранимый там объём исходников под PDP11, сравнили со своим, а в итоге DEC совершенно случайно приказала долго жить. Некоторые на такую версию вешают ярлык "конспирология", но при этом забывают, что DEC поднялась на госзаказах (как и IBM, но от другого ведомства). Разница в том, что в СССР была одна партия, а в США - две. И кто стабильно голосует за победителя на выборах, тому и достаётся финансирование в случае победы. Единый центр получил бы там слишком много власти, вплоть до возможности навязывать свою волю производителям железа, а через них и вообще задавить республиканцев.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

137. Сообщение от n00by (ok), 02-Апр-24, 17:49	+/–
Суть в том, что если всё это переносится в рантайм, то преимущества перед плюсами теряются. Да и на плюсах пришлось бы писать в стиле Си с голыми указателями, когда важна скорость и минимум блокировок. По-хорошему, следует архитектуру пересматривать, но ещё не известно, что из этого получится. Микрософт вон закопала Singularity.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #139

139. Сообщение от Анонин (?), 02-Апр-24, 18:17	+/–
> когда важна скорость и минимум блокировок Вообще новость как раз про то, что корректность важнее скорости. Потому что какая разница насколько быстро ты даришь рут)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #140

140. Сообщение от n00by (ok), 02-Апр-24, 18:59	+/–
А главное, что комментировать новость может всякий. Даже не имея представления, когда возможно использовать мютексы, а когда остаётся лишь спинлок, и то, если никто не увидит и не настучит по рукам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

141. Сообщение от Аноним (-), 02-Апр-24, 19:44	+/–
> В частном хватает std::shared_ptr<>. Ты сейчас говоришь про случай описанный в новости, или просто произносишь общую фразу о том, что иногда все эти сложности решаются при помощи shared_ptr? Если первое, то там оно не решается при помощи shared_ptr. Там память была освобождена, но не была отмаплена. Если второе, то да, иногда shared_ptr помогает, а иногда оказывается таким тормозом, постоянно сбрасывая кеши, то лучше бы его и не было. > А Rust что делает? unique_ptr выполняет на этапе компиляции Неее... В расте есть аналог shared_ptr -- то ли Rc, то ли Arc, я не уверен, не знаю как себя shared_ptr ведёт в многопоточном окружении. Но вот аналога unique_ptr в расте нет. Есть что-то похожее на это, но это только если смотреть жопой и с большого расстояния. Если тип не Copy (что дефолтом вешается на новые типы), то он как бы позволяет иметь не больше одного mutable указателя на значение. Во всяком случае, если верить маркетингу. Реально ситуация сложнее, глянь на код: fn foo(v_foo: &mut Vec) { ... } fn bar(v_bar: &mut Vec) { foo(v_bar); } fn main() {     let mut v = Vec::new();     bar(&mut v); } Когда на стеке оказывается стековый фрейм foo, одновременно существуют три указателя на этот несчастный Vec. Точнее в main он как бы и не указатель вовсе, он присутствует значением (в отличие от unique_ptr, который именно что ptr), но тем не менее это мутабельная переменная позволяющая менять Vec, и в стековых фреймах foo и bar в каждом по мутабельному указателю. Три мутабельных ссылки на одно значение! Это не приводит к нарушениям гарантий раста, если подумать, но маркетингу это очень сложно объяснять, поэтому он продолжает говорить о том, что не более одной мутабельной ссылки бывает за раз. Ещё пачка отличий unique_ptr от положения дел в расте вызвана тем, что в расте move'ы просчитываются статически, в C++ они насквозь динамичны, они по-определению shallow copy, и хрен заставишь оптимизатор выкинуть все эти ненужные копирования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #147

142. Сообщение от Аноним (-), 02-Апр-24, 20:07	+/–
> Не подходит, код ядра выполняется в произвольном потоке. Это может быть не важно, в каком потоке он выполняется. Главное чтобы к Rc не было бы попыток конкурентного доступа из разных потоков. >> Arc - Thread-safe reference-counting pointer (doc.rust-lang.org/std/sync/struct.Arc.html) > The type Arc<T> provides shared ownership of a value of type T, allocated in the heap. Ага, это аналог atomic<shared_ptr<T>> > В ядре в общем случае нет кучи. 1. А в ядре никто и не использует std. Под ядро написана замена std, которая во многом похожа, но всё же заметно различается, например Vec::new() возвращает Result<Vec, _>, а не Vec. Я не разглядывал её, но подозреваю что все эти разговоры про Rc и Arc туда слабо применимы, потому что в ядре очень востребованы обёртки над сишными типами с рефкаунтами, и для создания таких обёрток Rc и Arc бесполезны. 2. Если в ядре нет кучи, то нет никакого смысла говорить про shared_ptr, use-after-free, и пр. Когда троллишь, следи за толщиной, потому что тут ты явно перебрал. > То есть выбор сводится к: > 1. Написать заведомо невалидируемый код. > 2. Висеть в примитивах синхронизации, как и в наивной реализации std::shared_ptr. Да, он в C++ сводится к тому же, если код пишет вменяемый программист. Потому что мутабельный конкуретный доступ к данным -- это гарантия получить пачку дата-рейсов. Бывают иногда ситуации, когда разумные люди на это идут сознательно, но простите в таких случаях они пишут на ассемблере, выверяя чёткую последовательность команд для каждой конкретной архитектуры. На C/C++/Rust нельзя полагаться в этих ситуациях, потому что те когда оптимизируют творят такую хрень, что чёткую последовательность команд получиться не удастся никак. Подход раста в этом отношении отличается от подхода C++ только тем, что он не позволяет неразумным программистам организовать датарейс несознательно. Неразумный споткнётся об ошибки компиляции, которые он может одолеть при помощи unsafe, но это, простите, уже случай сознательного и целенаправленного создания датарейса. Никакие аппеляции к бритве Хэнлона не позволят ему отмазаться после такого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #146

143. Сообщение от namenotfound (?), 03-Апр-24, 03:00	+/–
я вообще не врубаюсь что это доказывает ну типа, да, нынешняя реализация трейтов в rustc - чистый ужас, и ее нужно переделывать, это уже и так известно достаточно давно но это же не проблема в спеке, спек сам уже формально доказан это как ткнуть в баг в gcc или clang и сказать, что это весь си неправильный
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

144. Сообщение от Аноним (144), 03-Апр-24, 03:47	+/–
игрушечных? то, что они не предназначены для системного программирования/embedded/жесткого реального времени не мешает языкам со сборкой мусора доминировать во всех остальных областях, так как в абсолютном большинстве случаев конечному потребителю ПО плевать на задержки, пока они от нескольких десятков до пары сотен миллисекунд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

145. Сообщение от платиновый спонсор (?), 03-Апр-24, 11:36	+/–
> Ну вот зачем это в ядре по умолчанию, а. Кому оно нужно кроме полутора мегамонстров? Ядро-то ? Правильно, никому оно ненужно. В смысле - настолько чтобы платить вашему б-жку с пальцем по ляму долларов в месяц. Поскреби по кармашкам - может, найдешь? Хахаха! Вот поэтому мы этот дэушка и будим танцыват. Ну и кое что после танцев.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

146. Сообщение от n00by (ok), 03-Апр-24, 11:44	+/–
>> Не подходит, код ядра выполняется в произвольном потоке. > Это может быть не важно, в каком потоке он выполняется. Главное чтобы > к Rc не было бы попыток конкурентного доступа из разных потоков. Такие попытки как раз и будут. Приложение вызвало syscall, далее поток работает в ядре и лезет куда-то в структуры примонтированной ФС. Они общие для всех? Сколько ещё других приложений делают тот же syscall - неизвестно. >[оверквотинг удален] > 1. А в ядре никто и не использует std. Под ядро написана > замена std, которая во многом похожа, но всё же заметно различается, > например Vec::new() возвращает Result<Vec, _>, а не Vec. Я не разглядывал > её, но подозреваю что все эти разговоры про Rc и Arc > туда слабо применимы, потому что в ядре очень востребованы обёртки над > сишными типами с рефкаунтами, и для создания таких обёрток Rc и > Arc бесполезны. > 2. Если в ядре нет кучи, то нет никакого смысла говорить про > shared_ptr, use-after-free, и пр. Когда троллишь, следи за толщиной, потому что > тут ты явно перебрал. Я использовал в ядре умные указатели, потому и говорю об этом. placement new не нужна куча. Вопрос в том, как именно реализовать shared_ptr - на двусвязном списке, со счётчиком ссылок или придумать что-то с lock-free. >> То есть выбор сводится к: >> 1. Написать заведомо невалидируемый код. >> 2. Висеть в примитивах синхронизации, как и в наивной реализации std::shared_ptr. > Да, он в C++ сводится к тому же, если код пишет вменяемый > программист. Потому что мутабельный конкуретный доступ к данным -- это гарантия > получить пачку дата-рейсов. Бывают иногда ситуации, когда разумные люди на это > идут сознательно, но простите в таких случаях они пишут на ассемблере, > выверяя чёткую последовательность команд для каждой конкретной архитектуры. На C/C++/Rust > нельзя полагаться в этих ситуациях, потому что те когда оптимизируют творят > такую хрень, что чёткую последовательность команд получиться не удастся никак. Можно ставить барьер. > Подход раста в этом отношении отличается от подхода C++ только тем, что > он не позволяет неразумным программистам организовать датарейс несознательно. Неразумный > споткнётся об ошибки компиляции, которые он может одолеть при помощи unsafe, > но это, простите, уже случай сознательного и целенаправленного создания датарейса. Никакие > аппеляции к бритве Хэнлона не позволят ему отмазаться после такого. Так вот проблема в том, что неразумным программистам в ядре делать вообще нечего, кроме как что-то сломать. С одной стороны Rust - это хорошо, а с другой, хорошо бы как-то отсеять неразумных. Когда Линус называл программистов на плюсах нетолерантным словом, он как раз это и делал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #150

147. Сообщение от n00by (ok), 03-Апр-24, 12:23	+/–
>>> Но найти все указатели хранящие данный адрес в общем случае может только >>> сборщик мусора. >> В частном хватает std::shared_ptr<>. > Ты сейчас говоришь про случай описанный в новости, или просто произносишь общую > фразу о том, что иногда все эти сложности решаются при помощи > shared_ptr? Вот прямо сейчас я начну говорить о том, что не стоит вырезать контекст (вернул фразу, на которую отвечал). > Если первое, то там оно не решается при помощи shared_ptr. Там память > была освобождена, но не была отмаплена. Значит решается другим частным случаем RAII, где освобождение всех ресурсов происходит в одной точке? > Если второе, то да, иногда shared_ptr помогает, а иногда оказывается таким тормозом, > постоянно сбрасывая кеши, то лучше бы его и не было. Это понятно, особенно если он внутри косвенный и с подсчётом ссылок (что не является единственно возможной реализацией). >> А Rust что делает? unique_ptr выполняет на этапе компиляции > Неее... В расте есть аналог shared_ptr -- то ли Rc, то ли > Arc, я не уверен, не знаю как себя shared_ptr ведёт в > многопоточном окружении. Arc, судя по соседней ветке, точно так же тормозит как и shared_ptr. Как его вообще можно сделать, что бы не тормозил?) > Но вот аналога unique_ptr в расте нет. Есть что-то > похожее на это, но это только если смотреть жопой и с > большого расстояния. Его там и не должно быть, насколько понимаю гарантии с передачей владения. Грубо говоря, unique_ptr засунули в borrow checker. >[оверквотинг удален] > fn main() { >     let mut v = Vec::new(); >     bar(&mut v); > } > Когда на стеке оказывается стековый фрейм foo, одновременно существуют три указателя на > этот несчастный Vec. Точнее в main он как бы и не > указатель вовсе, он присутствует значением (в отличие от unique_ptr, который именно > что ptr), но тем не менее это мутабельная переменная позволяющая менять > Vec, и в стековых фреймах foo и bar в каждом по > мутабельному указателю. Три мутабельных ссылки на одно значение! Это без оптимизации. С оптимизацией bar() в принципе должна исчезнуть. > Это не приводит к нарушениям гарантий раста, если подумать, но маркетингу это > очень сложно объяснять, поэтому он продолжает говорить о том, что не > более одной мутабельной ссылки бывает за раз. Маркетингу стоит добавить бззворды типа control flow и data flow.) > Ещё пачка отличий unique_ptr от положения дел в расте вызвана тем, что > в расте move'ы просчитываются статически, в C++ они насквозь динамичны, они > по-определению shallow copy, и хрен заставишь оптимизатор выкинуть все эти ненужные > копирования. В аналогичном варианте с std::vector оптимизатор плюсов всё выкидывал ещё во времена MSVC 7-й версии, но иногда приходилось его пинать и писать __forceinline.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #151

148. Сообщение от 12yoexpert (ok), 03-Апр-24, 13:10	+/–
где-то проводили конкурск на самый короткий и долгокомпилирующийся код на си. там чел каким-то кривым include-ом отправил компилятор на вечную компиляцию
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

149. Сообщение от aname (?), 03-Апр-24, 13:23	+/–
ЧСХ, из тысячеглаза, только одна пара нашла лютейший ад, который готовился в liblzma. Так и живём
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

150. Сообщение от Аноним (-), 03-Апр-24, 15:40	+/–
> Такие попытки как раз и будут. Приложение вызвало syscall, далее поток работает в ядре и лезет куда-то в структуры примонтированной ФС. Они общие для всех? Сколько ещё других приложений делают тот же syscall - неизвестно. Представь себе ситуацию: let global_structures = Mutex::new(GlobalStructures::new()); Если твой обработчик сделал: if let Ok(gs) = global_structures.lock() {     // то здесь у него есть эксклюзивный доступ к этим структурам через gs } Подобный подход наверное не очень хорош, когда речь идёт о файловой системе, но файловая система это лишь один из возможных примеров. А если ты уже получив гарантии эксклюзивности доступа будешь использовать атомарный Arc, вместо Rc, то тебе наплевать на производительность щтоле? > placement new не нужна куча. А, ты хвастаться знаниями пришёл и докапываешься к словам, ожидая когда я начну комплименты твоему интеллекту и познаниям отпускать? Ты очень умный. И много знаешь. Молодей чувак, круто. Но для ясности, давай заменим слово "куча" на динамический аллокатор памяти, будь он кучей, ареной, или чем ещё. > Можно ставить барьер. Как один из способов, да. > Так вот проблема в том, что неразумным программистам в ядре делать вообще нечего, кроме как что-то сломать. Это наивный идеализм, закрывающий глаза на реальное положение дел, при котором неразумные программисты встречаются везде. В частности потому, что ряд задач решаемых программистом упираются в проблему останова, и поэтому сколько бы он не думал о коде, он никогда не может быть уверен в том, что код безбажен. Программисты выходят из этой ситуации накладывая ограничения на код, так чтобы проблемы останова не возникало, чтобы можно было бы доказать про код его безбажность (пускай и неформальной логикой), но эти ограничения отличаются тем, что они вовсе не очевидны по коду, нет способа получить для каждой строки кода список действий запрещённых для этой строки. В таких условиях 100% разумным может быть только Бог, потому что только он всеведущий. > хорошо бы как-то отсеять неразумных Это контрпродуктивно, потому что единственный долгосрочно работающий способ получать разумных программистов, это брать неразумных и воспитывать в них разум. Надеясь на то, что они сами наплодятся и придут тебе помогать, ты рискуешь остаться один. Рано или поздно ты останешься один, последним из могикан.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #153

151. Сообщение от Аноним (-), 03-Апр-24, 16:12	+/–
>> Если первое, то там оно не решается при помощи shared_ptr. Там память >> была освобождена, но не была отмаплена. > Значит решается другим частным случаем RAII, где освобождение всех ресурсов происходит в одной точке? Это решается интеллектом, который должен остановиться и подумать, что речь идёт о двух уровнях динамической аллокации. Аллокация виртуальной памяти отдельно, аллокация физической памяти, чтобы пополнить виртуальую, тоже отдельно. Ты можешь видеть это в любой реализации кучи, которая отдельно следит за маппингом памяти, отдельно за занятыми виртуальными адресами. В данном частном случае, я отмечу, всё было сделано так, что в момент, когда страницы надо было анмапить, было невозможно решить надо ли анмапить или не надо, потому что владельцем этих страниц мог быть юзерспейс, если он мапил, или кернелспейс, если мапил он. То есть в ядре было понятно, что можно (и нужно) реклаймить виртуальную память из-под буферов и помечать свободной, а вот что делать с физической памятью уже было не ясно, потому что ключевая для принятия решения информация была утеряна к тому моменту. > Это без оптимизации. С оптимизацией bar() в принципе должна исчезнуть. Может исчезнуть, но может и нет. В данном примере код написан так, что он заинлайнится. Но не весь код инлайнится. Плюс оптимизации -- это оптимизации, они не меняют семантики, а семантически есть промежуток времени выполнения, когда три валидные мутабельные ссылки мирно сосуществуют. > Маркетингу стоит добавить бззворды типа control flow и data flow.) Он тогда перестанет быть маркетингом. Маркетинг -- это хлёсткие и сильные утверждения, а не нердовское бла-бла-бла на полчаса. > В аналогичном варианте с std::vector оптимизатор плюсов всё выкидывал ещё во времена MSVC 7-й версии, но иногда приходилось его пинать и писать __forceinline. Я тут связался с C++ кодом, и чёт меня дёрнуло builder pattern присобачить. Типа: let mytype = MyType::builder()    .size(42)    .color(Color::Green)    .kind(Engine::Diesel)    .build(); Я до сих пор не уверен, что мне удалось избавиться от _всех_ семантически подразумеваемых shallow copy всех мувов. Я поленился отдельный минимальный пример создавать, и поэтому приходилось продираться через наслоения asm'а, и вроде я избавился от большинства копирований, но у меня там флаг был в одной структуре и (согласно комментам -fverbose-asm) в него значение клалось дважды. move-конструктор в C++ получает ДВА указателя, и работает с обоими. Чтобы эти копии выкинуть, оптимизатор должен быть в состоянии отследить весь контрол-флоу, понять что память из под старого значения не используется больше, вернутся назад и повторно использовать память. И из-за этого невозможно просто присунуть в деструктор отладочную печать, и потом считать сколько раз деструктор вызывается, потому что наличие отладочной печати показывает оптимизатору, что память используется потом, и он не оптимизирует. Арггх, я ненавижу C++, его идея смешивать семантику с оптимизациями -- это просто слов у меня нет для описания идиотизма тех, кто это придумал. Они явно на каких-то тяжёлых веществах сидели в этот момент.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #152

152. Сообщение от n00by (ok), 03-Апр-24, 18:46	+/–
>[оверквотинг удален] > в любой реализации кучи, которая отдельно следит за маппингом памяти, отдельно > за занятыми виртуальными адресами. > В данном частном случае, я отмечу, всё было сделано так, что в > момент, когда страницы надо было анмапить, было невозможно решить надо ли > анмапить или не надо, потому что владельцем этих страниц мог быть > юзерспейс, если он мапил, или кернелспейс, если мапил он. > То есть в ядре было понятно, что можно (и нужно) реклаймить виртуальную > память из-под буферов и помечать свободной, а вот что делать с > физической памятью уже было не ясно, потому что ключевая для принятия > решения информация была утеряна к тому моменту. Вот эту последнюю проблему и решает RAII. Всё освобождается в одном месте - деструкторе (а что именно освобождается - это вообще дело десятое). Но может так оказаться, что всё это затруднительно завернуть в одну обёртку. Потому что архитектуру проектировали под язык Си и без расчёта на такое. То есть я веду вовсе не к тому, что плюсы чудесным образом смогут гарантировать отсутствие ошибок. А к тому, что ради возможности обеспечения таких гарантий придётся переписывать вообще всё. И это язык очень близкий к Си технически, но вот такой нюанс немножко всё портит. Я не знаю, насколько верно из этого частного случая индуцировать обобщение на Rust, но оптимизма по этому поводу у меня нет. Особенно после того как местные знатоки языка честно признаются "а как в ядре, я не знаю". >> Это без оптимизации. С оптимизацией bar() в принципе должна исчезнуть. > Может исчезнуть, но может и нет. В данном примере код написан так, > что он заинлайнится. Но не весь код инлайнится. Плюс оптимизации -- > это оптимизации, они не меняют семантики, а семантически есть промежуток времени > выполнения, когда три валидные мутабельные ссылки мирно сосуществуют. Ссылки эти просто висят в памяти, поскольку процессор сам собой её не зануляет. Они могут сыграть роль в фантастическом случае - руткит останавливает поток исполнения и начинает рыться в стеке, что бы найти там указатель и по нему что-то ещё модифицировать. >[оверквотинг удален] > move-конструктор в C++ получает ДВА указателя, и работает с обоими. Чтобы эти > копии выкинуть, оптимизатор должен быть в состоянии отследить весь контрол-флоу, понять > что память из под старого значения не используется больше, вернутся назад > и повторно использовать память. И из-за этого невозможно просто присунуть в > деструктор отладочную печать, и потом считать сколько раз деструктор вызывается, потому > что наличие отладочной печати показывает оптимизатору, что память используется потом, > и он не оптимизирует. Арггх, я ненавижу C++, его идея смешивать > семантику с оптимизациями -- это просто слов у меня нет для > описания идиотизма тех, кто это придумал. Они явно на каких-то тяжёлых > веществах сидели в этот момент. Я не уверен, что в плюсы обязательно тащить всё, что хорошо себя зарекомендовало в ООП-языках. Все эти константы просятся в специализацию шаблона. Вот это действительная проблема плюсов - когда свалили все парадигмы в кучу, а метапрораммирование умел один Александреску, но почему-то ушёл в D.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

153. Сообщение от n00by (ok), 03-Апр-24, 19:39	+/–
>[оверквотинг удален] > let global_structures = Mutex::new(GlobalStructures::new()); > Если твой обработчик сделал: > if let Ok(gs) = global_structures.lock() { >     // то здесь у него есть эксклюзивный доступ > к этим структурам через gs > } > Подобный подход наверное не очень хорош, когда речь идёт о файловой системе, > но файловая система это лишь один из возможных примеров. А если > ты уже получив гарантии эксклюзивности доступа будешь использовать атомарный Arc, вместо > Rc, то тебе наплевать на производительность щтоле? Подобный подход вообще не очень хорош, потому что все вызвавшие syscall приложения кроме одного дружно остановились в одном месте. О какой производительности говорить, когда мютекс вызвал планировщик и процессор принялся исполнять какие-то другие потоки? Сравнивать перезагнузку контекстов с каким-то счётчиком? >> placement new не нужна куча. > А, ты хвастаться знаниями пришёл и докапываешься к словам, ожидая когда я > начну комплименты твоему интеллекту и познаниям отпускать? Ты очень умный. И > много знаешь. Молодей чувак, круто. > Но для ясности, давай заменим слово "куча" на динамический аллокатор памяти, будь > он кучей, ареной, или чем ещё. Мне пока не ясно, зачем вообще аллокатор. На этом "ещё чём" хранится счётчик ссылок и голый указатель на объект? Или объект рядом со счётчиком ссылок? Для shared_ptr такая реализация не обязательна. >[оверквотинг удален] > программисты встречаются везде. В частности потому, что ряд задач решаемых программистом > упираются в проблему останова, и поэтому сколько бы он не думал > о коде, он никогда не может быть уверен в том, что > код безбажен. Программисты выходят из этой ситуации накладывая ограничения на код, > так чтобы проблемы останова не возникало, чтобы можно было бы доказать > про код его безбажность (пускай и неформальной логикой), но эти ограничения > отличаются тем, что они вовсе не очевидны по коду, нет способа > получить для каждой строки кода список действий запрещённых для этой строки. > В таких условиях 100% разумным может быть только Бог, потому что > только он всеведущий. Реальное положение дел таково, что ядро разрослось и теряется контроль, от чего многие ядерщики вдруг хором заговорили про выгорание, а новых почему-то прибавляется несоизмеримо росту сложности мало. Например, потому что Си вышел из моды в прошлом веке. Этот вопрос принялись решать вполне понятным способом - привлечь свежие силы модным языком. На какое-то время это даст видимый подъём, но далее выгорание у первых ускорится, и учить окажется некому. Это пессимистичный сценарий, но вероятный. Может быть, там дальше в планах появление перспективного ученика самого Линуса со словами "смотрите, я тут переписал ключевые подсистемы на Rust", что спасёт положение. >> хорошо бы как-то отсеять неразумных > Это контрпродуктивно, потому что единственный долгосрочно работающий способ получать > разумных программистов, это брать неразумных и воспитывать в них разум. Надеясь > на то, что они сами наплодятся и придут тебе помогать, ты > рискуешь остаться один. Рано или поздно ты останешься один, последним из > могикан. Так это надо на Си учить писать и бить по рукам линейкой, что ли? Вон в новости прилетела очередная. А народ говорит, давайте её уберём. Или есть, кому учить на Rust? Из Redox перетянули людей?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150

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

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