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

"Линус Торвальдс не исключил возможность интеграции поддержки Rust в ядро Linux 5.20"	+/–
Сообщение от opennews (ok), 22-Июн-22, 09:28
На проходящей в эти дни конференции Open-Source Summit 2022 в секции ответов на вопросы Линус Торвальдс упомянул о возможности скорой интеграции в ядро Linux компонентов для разработки драйверов устройств на языке Rust. Не исключается, что патчи с поддержкой Rust будут приняты в ближайшем окне приёма изменений, формирующем состав ядра 5.20, намеченного на конец сентября... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57391
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Fracta1L (ok), 22-Июн-22, 09:28	+9 +/–
Прагматичный мужик, с таким лидером Linux будет успешно развиваться, вбирая в себя лучшие новшества.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #19, #32, #92, #96

2. Сообщение от Аноним (2), 22-Июн-22, 09:37	+15 +/–
Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #7, #15, #20, #37, #38

3. Сообщение от Аноне (?), 22-Июн-22, 09:37	+1 +/–
А как же так, неужели не надо всё ядро выбрасывать и на расте переписывать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #6, #11

4. Сообщение от Аноним (4), 22-Июн-22, 09:38	+4 +/–
Дочитай новость до конца, может тогда поймёшь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #10, #500

5. Сообщение от Аноним (5), 22-Июн-22, 09:40	+13 +/–
Всё читал смехушечки про ужасный синтаксис Rust. Потом сам столкнулся. Да даже C++ более читаемым выглядит. fn main -> std::io::Result<()>{ Вот чем думали разработчики языка? Удобно такое набирать? Нет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #17, #23, #36, #78, #136, #225, #244

6. Сообщение от Аноним (6), 22-Июн-22, 09:41	+16 +/–
Вряд ли он страдает юношеским максимализмом, тем более в его-то возрасте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #24, #58, #117

7. Сообщение от Юрий (??), 22-Июн-22, 09:42	+9 +/–
Линус не любит плюсы. И правильно делает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

8. Сообщение от Аноним (8), 22-Июн-22, 09:44	–24 +/–
дада, тебя забыли спросить
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #16, #208

10. Сообщение от Александр (??), 22-Июн-22, 09:44	+3 +/–
так плюсы тоже умеют это, если ручку приложить. Он на простой Ся без всякой безопасности жил до этого вполне уверенно. просто дядька невзлюбил плюсы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #13, #56, #87

11. Сообщение от Fracta1L (ok), 22-Июн-22, 09:45	+/–
Москва не сразу строилась
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #46

13. Сообщение от Fracta1L (ok), 22-Июн-22, 09:46	–2 +/–
> плюсы тоже умеют это, если ручку приложить Если ручку приложить - можно из буханки хлеба сделать троллейбус, только зачем
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #63

15. Сообщение от Аноним (15), 22-Июн-22, 09:47	+2 +/–
Так в C++ Exception и это богомерзко и нельзя. А в Rust panic и это только ай-ай-ай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #105

16. Сообщение от Аноним (5), 22-Июн-22, 09:48	+/–
Это комментарий, а не ответ. В следующий раз пробуй потоньше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

17. Сообщение от Аноним (17), 22-Июн-22, 09:52	–2 +/–
Разработчики уже все для тебя придумали: use, use as, type.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #21

19. Сообщение от Аноним (19), 22-Июн-22, 09:54	+4 +/–
ну, графический пинг написали, можно и за ядро взяться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #27

20. Сообщение от freehck (ok), 22-Июн-22, 09:54	+5 +/–
> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++? Потому что Линус в гробу видал C++. Его потом дебажить замучаешься. И сломается в самый неподходящий момент. А это ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #60, #67, #81

21. Сообщение от Аноним (21), 22-Июн-22, 09:56	+1 +/–
Ладно, передумал не любить rust. Включайте в ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #64

23. Сообщение от Аноним (23), 22-Июн-22, 09:57	–2 +/–
Такое только в hello world бывает. В реальных программах обычно функции возвращают просто Result<()>, потому что подключен anyhow или свой тип Error и "type Result<T> = std::result::Result<T, Error>;"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #30

24. Сообщение от Менеджер по поддержке ржавчины (?), 22-Июн-22, 10:02	+1 +/–
в таком-то возрасте - пора на пенсию ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #84

26. Сообщение от Аноним (26), 22-Июн-22, 10:37	+/–
больше языков в ядро, а потом удивляться тому, что ядро поддерживает только три с половиной процессора
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28

27. Сообщение от Массоны Рептилоиды (?), 22-Июн-22, 10:41	+/–
Графическое ядро уже почти написали!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #51, #55

28. Сообщение от Аноним (4), 22-Июн-22, 10:54	–1 +/–
Тоже ниасилил прочитать новость? Вообще предлагаю модераторам сделать следующие: вместо числа на картинке при отправке комментария отвечать на вопросы по содержанию новости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

30. Сообщение от ranen (?), 22-Июн-22, 10:55	+2 +/–
Это кусок из примера к стандартной библиотеке вводы/вывода. Никто, находясь в своем уме, не будет выкидывать пользователю сырые ошибки ввода/вывода, хоть бы имя файла указал, с которым проблемы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

31. Сообщение от microsoft (?), 22-Июн-22, 10:57	+10 +/–
> преподносится как опция Лицемерие. Ровно до тех пор пока драйвер видео или клавиатуры не будет на нем. Ню ню.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45, #72, #74

32. Сообщение от microsoft (?), 22-Июн-22, 10:59	+1 +/–
А до этого ты орал чти у Торвальдса с головой не в порядке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #33

33. Сообщение от Fracta1L (ok), 22-Июн-22, 11:06	–2 +/–
Когда?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #99

34. Сообщение от Аноним (34), 22-Июн-22, 11:09	+2 +/–
На самом деле, логичным должен быть вопрос не "когда С++", а "когда Fortran, ADA, objective C".
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #75, #432

36. Сообщение от warlock66613 (ok), 22-Июн-22, 11:18	+2 +/–
А в чём проблема, и почему неудобно? Ну и `std::` лучше убрать, импортировав `io`, тогда будет fn main() -> io::Result<()> { }
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #47

37. Сообщение от Аноним (37), 22-Июн-22, 11:25	+1 +/–
> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++? Можно. Пиши, что тебе мешает-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

38. Сообщение от DmA (??), 22-Июн-22, 11:28	+/–
Ядро и драйвера Windows NT разве не на С++ написаны?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #41, #62

40. Сообщение от Sw00p aka Jerom (?), 22-Июн-22, 11:42	+/–
новое поколение анбешных бекдорописак разучилось писать на С, вот и пихают это поделие, чтобы бекдоры не крешили систему когда работают с памятью.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44, #234

41. Сообщение от Al Ka (?), 22-Июн-22, 11:45	+/–
Нет, на Си. Если не верите посм. утекшие исходники XP
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

44. Сообщение от Попандопала (?), 22-Июн-22, 11:48	+/–
Интим не предлагать?XD
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #89

45. Сообщение от Аноним (45), 22-Июн-22, 11:51	+7 +/–
>> преподносится как опция > Лицемерие. Ровно до тех пор пока драйвер видео или клавиатуры не будет > на нем. Ню ню. Ну, сперва на одну восьмую шишечки вставят, а потом и всё ядро проржавеет. Чот мне это напомнило... ЕМНИП, нужно вроде было старый инит на более быстрый и без фатального недостатка, переделать, но это не точно, давно это было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #50, #121

46. Сообщение от Аноним (46), 22-Июн-22, 11:54	+3 +/–
к счастью, не на расте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #53

47. Сообщение от Аноним (47), 22-Июн-22, 11:55	+5 +/–
Думаю проблема в этом <()>.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #54, #109, #257, #430, #480

49. Сообщение от Bob (??), 22-Июн-22, 11:57	+/–
Абстрагируясь: можно КПД итогового решения? Сетевой драйвер для 10 ГБ\с https://github.com/ixy-languages/ixy-languages/blob/master/R... В виде научной статьи и в сравнении с другими языками https://www.net.in.tum.de/fileadmin/bibtex/publications/pape... p.s.: да, там есть грёбанный javascript. Нет, я не буду это спойлерить. p.p.s.: Rust чуть хуже с "проверками" и намного быстрее без проверок, даже при банальном переводе С кода в Rust. Смысл в проверках? - Ловит баги. Подробнее - в статье =)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52, #128, #182

50. Сообщение от Аноним (46), 22-Июн-22, 11:59	+2 +/–
Ещё гарфику пытались безопасной сделать... В итоге половина прог перестали работать из-за архитектурных проблем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

51. Сообщение от Аноним (-), 22-Июн-22, 12:04	+1 +/–
Заметь, "безопасное графическое ядро".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

52. Сообщение от Аноним (46), 22-Июн-22, 12:05	+2 +/–
Ох уж эти сказочки...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

53. Сообщение от Аноним (123), 22-Июн-22, 12:07	–1 +/–
На чём-то вроде бейсика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #100

54. Сообщение от Аноним (-), 22-Июн-22, 12:08	–2 +/–
Почему этого я не заметил, а ты заметил?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #71

55. Сообщение от Аноним (120), 22-Июн-22, 12:09	+1 +/–
Графическое ядро надо писать на Electron.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

56. Сообщение от Аноним (120), 22-Июн-22, 12:11	–2 +/–
А на Rust даже голову прикладывать ненужно, не то, что ручку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #79

58. Сообщение от Аноним (58), 22-Июн-22, 12:13	+2 +/–
А тогда зачем он раст то внедряет? Мог бы тогда как в былые годы всем им свой фирменный жест показать!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #90

60. Сообщение от Аноним (120), 22-Июн-22, 12:14	+1 +/–
Так может на OCaml?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #195

61. Сообщение от Аноним (61), 22-Июн-22, 12:14	+1 +/–
Всегда мечтал собирать ядро неделю.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #80, #111

62. Сообщение от Аноним (62), 22-Июн-22, 12:15	+1 +/–
На C++ был BeOS: https://en.wikipedia.org/wiki/BeOS_API
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #68

63. Сообщение от Аноним (58), 22-Июн-22, 12:15	+/–
HaikuOS полностью написана на с++ и вот-вот нагнёт ваш линукс на десктопах!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #73, #94, #161

64. Сообщение от Аноним (120), 22-Июн-22, 12:15	+/–
Сначала в GCC включайте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #82

67. Сообщение от Аноним (58), 22-Июн-22, 12:17	+/–
Ядро HaikuOS написано на c++. И работает на декстопах уже получше чем...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #106, #165

68. Сообщение от Аноним (58), 22-Июн-22, 12:19	+/–
И haiku!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

69. Сообщение от Аноним (-), 22-Июн-22, 12:19	+1 +/–
Как там успехи у дистрибутива Hyperbola с использованием ядра OpenBSD, кто знает?
Ответить | Правка | Наверх | Cообщить модератору

71. Сообщение от n00by (ok), 22-Июн-22, 12:21	+/–
Если перечислить языки, которые знает каждый из Анонимов, вероятно, станет понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

72. Сообщение от Аноним (120), 22-Июн-22, 12:21	+/–
Вот, даже Microsoft это понимает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

73. Сообщение от Fracta1L (ok), 22-Июн-22, 12:24	+5 +/–
С РеактОСом вместе)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

74. Сообщение от Аноним (120), 22-Июн-22, 12:24	+/–
Если позарез модуль будет нужен, придётся портировать на C. По крайней мере, пока Rust frontend не добавят в GCC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #212

75. Сообщение от Аноним (120), 22-Июн-22, 12:27	+1 +/–
Вот вопрос про Ada не кажется шуткой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #233

76. Сообщение от Аноним (-), 22-Июн-22, 12:30	+/–
Если начнут писать модули на Расте каков их будет среднестатистический бинарный размер? Только не говорите мне, что надо каждый раз отключать включёные по умолчанию функции дебага. Если начать компилировать исходные коды на Расте, сколько ждать? Половину дня? Люди говорят, что исходники на Расте и C++  компилируются очень долго. Раст болтливый язык? Одинаковая реализация в процедурном стиле среднестатистического алгоритма на чистом Си будет занимать меньше строк чем на Расте? Чисто-сишное ядро и так раздуто, а с распространением языка Раст мы будем вынуждены в итоге скачивать гигабайтный архив исходных кодов? Короче, в голову приходят страшные мысли. Ребята передайте Линусу пусть он пока не пускает Раст в ядро! А корпорасты, которые лоббируют продвижение Раста пусть идут лесом.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #83, #85, #104, #149, #173, #235

77. Сообщение от Аноним (58), 22-Июн-22, 12:31	+1 +/–
>Линус Торвальдс упомянул о возможности скорой интеграции в ядро Linux компонентов для разработки драйверов устройств на языке Rust А c++ ему не нравится! И в защиту плюсов скажу что HaikuOS (как и BeOS) от ядра и загрузчика и до самого юзерспейса написана на c++! И вот-вот нагнёт этот ваш линукс на декстопах! Уже сейчас почти работает vulkan-видеодрайвера для radeon карт!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #88, #129, #326

78. Сообщение от Cucumber (?), 22-Июн-22, 12:33	+3 +/–
Если не используется код выхода, то просто пишешь: fn main() { ...тело функции... } Если зачем-то код выхода внезапно нужен (интересно зачем, когда есть всякие panic, uwrap и тому подобная херня), то сейчас сделали чуть более лаконичный ExitCode use std::process::ExitCode; fn main() -> ExitCode {     if !check_foo() {         return ExitCode::from(42);     }     ExitCode::SUCCESS } https://doc.rust-lang.org/stable/std/process/struct.ExitCode...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #141, #325, #431

79. Сообщение от Аноним (46), 22-Июн-22, 12:35	+2 +/–
> на Rust даже голову прикладывать ненужно Оно и видно, как падал FF.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

80. Сообщение от Аноним (120), 22-Июн-22, 12:35	+/–
Первый день Rust. Впрочем, в дальнейшем может понадобиться не один день.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

81. Сообщение от n00by (ok), 22-Июн-22, 12:35	+/–
>> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++? > Потому что Линус в гробу видал C++. Линус тогда сказал именно то, что от него хотели услышать люди, писавшие ядро на Си. Действовал в интересах сообщества. > Его потом дебажить замучаешься. И > сломается в самый неподходящий момент. А это ядро. Это предрассудки. Но если люди привыкли писать на Си - вот тогда им будет сложно. Поэтому Линус не захотел ломать традицию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #197

82. Сообщение от Аноним (46), 22-Июн-22, 12:36	+1 +/–
Лицензионные ограничения раста...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #93

83. Сообщение от Аноним (120), 22-Июн-22, 12:41	+1 +/–
Эх, даже если мы устроим краудфандинг, чтобы компенсировать Торвальдсу упущенную выгоду, вслествие отказа от включения Rust, мы не наберём столько.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

84. Сообщение от Бывалый смузихлёб (?), 22-Июн-22, 12:41	+/–
Дедушку, здоровающегося с пустотой и падающего с велика, всё никак на пом.. пенсию не выкинут, а вы про торвальдса К слову, не помню последнее время репортажей о том как он катался на велике. Подготовился же, чертяка
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #110

85. Сообщение от n00by (ok), 22-Июн-22, 12:42	–3 +/–
> Раст болтливый язык? Одинаковая реализация в процедурном стиле среднестатистического > алгоритма на чистом Си будет занимать меньше строк чем на Расте? Раст, внезапно, функциональный. Так что, в общем случае, меньше. Другое дело, что железо "императивно".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #258

86. Сообщение от iPony129412 (?), 22-Июн-22, 12:42	+2 +/–
Это знак 😮. С сегодняшнего дня начну учить Rust. Найду книгу хорошую и начну.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #91, #97, #108, #112

87. Сообщение от Бывалый смузихлёб (?), 22-Июн-22, 12:44	+/–
> просто дядька невзлюбил плюсы да их в принципе немногие взлюбили, поэтому, при первой же реальной возможности, выкидывают их на помойку
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

88. Сообщение от Аноним (120), 22-Июн-22, 12:45	+/–
Тут жеж ещё всё сильно будет зависеть от того, сможет ли весь существующий свободный софт быть собранным под Haiku.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #130

89. Сообщение от Sw00p aka Jerom (?), 22-Июн-22, 12:45	+/–
без смс и рекламы :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #124

90. Сообщение от torvn77 (ok), 22-Июн-22, 12:47	–1 +/–
Так его феминистками обложили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #120

91. Сообщение от Аноним (120), 22-Июн-22, 12:50	+/–
"Rust за 21 час с нуля" или "Rust для тинейджеров" ещё не написали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #101

92. Сообщение от torvn77 (ok), 22-Июн-22, 12:51	+/–
А что он будет делать кода в ядре появится свободный код на несвободных системах комманд? Затопает ножками при полном юридическом и практическом бессилии?   Почему нельзя было сделать "безопасное написание драйверов" на другом языке программирования?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #116

93. Сообщение от Аноним (120), 22-Июн-22, 12:53	+/–
Название поменять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #95, #201

94. Сообщение от torvn77 (ok), 22-Июн-22, 12:54	+/–
А разве её не на ассемблере пишут?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #102

95. Сообщение от Аноним (120), 22-Июн-22, 12:54	+/–
Или совместимую, по крайней мере, сначала, независимую реализацию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

96. Сообщение от Аноним (96), 22-Июн-22, 12:55	–1 +/–
Дяди из Linux Foundation решили окончательно убить Linux как Mozilla убивает Firefox. Примечательно, что тоже переписыванием на Rust. Потом окончательно переведут всех на какое-то несвободное ПО вроде Fuchsia с тивоизацией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #138, #305, #396

97. Сообщение от Иваня (?), 22-Июн-22, 12:55	+2 +/–
А мне лень учить новый ЯП... Я знаю C, буду на нём писать, не зря же учил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

99. Сообщение от Аноним (120), 22-Июн-22, 12:59	+1 +/–
- Доктор, у меня провалы в памяти. - И давно это у вас началось? - Что? - Ну провалы? - Какие провалы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

100. Сообщение от Аноним (120), 22-Июн-22, 13:00	+/–
На Бедоне же. Вот как разрослась-то!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #441

101. Сообщение от iPony129412 (?), 22-Июн-22, 13:01	+/–
> "Rust за 21 час с нуля" или "Rust для тинейджеров" ещё не написали. Жаль, хотя мне всё равно. Вот с функциональщиной плохо - это может помешать наверно...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

102. Сообщение от Аноним (58), 22-Июн-22, 13:04	+2 +/–
Это KolibriOS
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #126

104. Сообщение от Аноним (104), 22-Июн-22, 13:07	+/–
Си программы меньше размером, потому что динамическая линковка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #259

105. Сообщение от НяшМяш (ok), 22-Июн-22, 13:14	+4 +/–
> Так в C++ Exception и это богомерзко и нельзя. Эппл, например, в IOKit взяли и просто запретили исключения и ещё пару вещей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

106. Сообщение от НяшМяш (ok), 22-Июн-22, 13:14	+3 +/–
Сколько в нём драйверов и архитектур есть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #118

108. Сообщение от Без аргументов (?), 22-Июн-22, 13:16	+1 +/–
лучше сначала изучите организацию ЭВМ, архитектуру железа и ядра. а потом хоть JS
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #127, #219

109. Сообщение от НяшМяш (ok), 22-Июн-22, 13:17	+1 +/–
Если уж прям глаз режет, то можно сделать type Void = ();
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

110. Сообщение от hgdslvodf (?), 22-Июн-22, 13:17	+8 +/–
Человечек, который статистически не доживет до собственной пенсии, хохочет с 79-летнего старика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #123, #170

111. Сообщение от НяшМяш (ok), 22-Июн-22, 13:19	+2 +/–
Кстати интересно как там инициатива по рефакторингу заголовочных файлов продвигается. Обещали неслабое ускорение сборки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #189, #434

112. Сообщение от НяшМяш (ok), 22-Июн-22, 13:20	+/–
https://doc.rust-lang.org/book/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

113. Сообщение от Аноним (113), 22-Июн-22, 13:22	+1 +/–
За 30 лет могли бы лучше Pascal впилить в ядро. На нём явно поприятнее писать, и дрова в том числе.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #134, #151, #232, #316, #438

114. Сообщение от Аноним (114), 22-Июн-22, 13:22	+2 +/–
Это ужасно, "макака-формошлёп"ы, не знающие чем фон неймановская архитектура отличается от гарвардской, добрались до ядра. Так называемые "программисты" на rust окончательно испортят линукс. Не подскажете куда лучше переходить? FreeBSD, OpenBSD или может быть Mac OS X?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #115, #119, #132, #196, #203, #217

115. Сообщение от Аноним (61), 22-Июн-22, 13:23	+6 +/–
На windows.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #193

116. Сообщение от Fracta1L (ok), 22-Июн-22, 13:26	+1 +/–
Шта
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #125

117. Сообщение от kugym (?), 22-Июн-22, 13:29	+/–
Он им наслаждается
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

118. Сообщение от Аноним (120), 22-Июн-22, 13:49	+1 +/–
Ну для RISC-V64 портировали, вроде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #462

119. Сообщение от АнонимКо (?), 22-Июн-22, 13:52	+/–
> Это ужасно, "макака-формошлёп"ы, не знающие чем фон неймановская архитектура отличается > от гарвардской, добрались до ядра. Так называемые "программисты" на rust окончательно > испортят линукс. > Не подскажете куда лучше переходить? FreeBSD, OpenBSD или может быть Mac OS > X? Если Linux совсем загрётся и не будет новых вменяемых альтернатив, лично я ливна на опёнка, т.к. Тео не ср@ный толерастный смузибой-макакокодер, а суровый мужик старой закалки с правильным здравым подходом к ненужному.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

120. Сообщение от Аноним (120), 22-Июн-22, 13:53	+/–
Причём, четверо из них у него дома.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

121. Сообщение от anonymous (??), 22-Июн-22, 13:56	–2 +/–
То есть RedHat вместо того чтобы втихаря ночью под одеялом накопить бесценный многолетний опыт по решению проблем тысяч промышленных установок, десятки тысяч проблем с обслуживающим персоналом, обобщить это и выяснить что башпортянки и есть главный источник проблем а значит источник бабла для проходимцев мнящих себя "я такой сисадмин юникса в свитере и знаю чем отличаются "" от '' на колени предо мной платите миллиарды за мои башзнания и нелтленные башпортянки, а то уволюсь и ппц фирме" нанял Лёню и решил проблемы, причем в открытую все документировано и свободно. Но тут как солнце из за туч от Дебиановских начетчиков : > нужно вроде было старый инит на более быстрый и без фатального недостатка Ваш главный дебиановец кто эту мутную волну на RedHаt гнал уже не снами но дело его живет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #467

123. Сообщение от Аноним (123), 22-Июн-22, 14:14	+2 +/–
А из вопреки всё-таки доживших много ли кто на велосипед осилит залезть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #133, #243

124. Сообщение от Попандопала (?), 22-Июн-22, 14:16	+/–
Ага, с OAuth говорят секьюрнее. )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

125. Сообщение от torvn77 (ok), 22-Июн-22, 14:22	+2 +/–
Ну безопасное написание драйверов ламерами это объективная реальность, потому что никто кроме них не будет писать драйвер для девайса который купили полтора человека и сделать для них загончик где они бы бсодили только свой драйвер нужно и полезно.   Но почему для этого загончика выбран инструмент с лицензией имеющей потенциальную опасность вендорлока?   Свои проприетарные системы комманд никто не сможет и не будет делать?   Как тут хорошо вспомнить о открытом процессоре RISC V в который как раз можно ставить свои расширения команд.   Я не знаю какая у него лицензия, но мой нос чувствует приближение жопы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #131, #135, #395

126. Сообщение от torvn77 (ok), 22-Июн-22, 14:24	+/–
Ну раз Гайку пишут на нормальном языке то посмотрю, судя по коментам там у вас скоро amdgpu прикрутят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #137

127. Сообщение от iPony129412 (?), 22-Июн-22, 14:25	+1 +/–
> лучше сначала изучите организацию ЭВМ, архитектуру железа и ядра. а потом хоть JS Уже есть. Только JS не это. Но не хочу как-то 🤷♂
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

128. Сообщение от Аноним (138), 22-Июн-22, 14:27	+/–
Абстрагируясь? Шляпа платит Линусу бонусы, Линус ловит лулзы с сообщества.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

129. Сообщение от Аноним (138), 22-Июн-22, 14:29	+3 +/–
> от ядра и загрузчика и до самого юзерспейса написана на c++ Как что-то хорошее. Приходи, когда нагнёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

130. Сообщение от Аноним (138), 22-Июн-22, 14:30	+/–
А с этим проблемы? Компилятор си в ней есть, берёшь, собираешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #191

131. Сообщение от Fracta1L (ok), 22-Июн-22, 14:34	+/–
Шизофазия
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

132. Сообщение от Аноним (138), 22-Июн-22, 14:34	+/–
>BSD Можешь попробовать. > Mac OS X Нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

133. Сообщение от rshadow (ok), 22-Июн-22, 14:35	+/–
Ну если альцгеймер прогрессирует, то может и старик на велосипед полезет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #140

134. Сообщение от Аноним (138), 22-Июн-22, 14:35	+/–
Что ты такое говоришь? pascal - это смерть для линукса!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

135. Сообщение от Аноним (135), 22-Июн-22, 14:37	+1 +/–
>> почему для этого загончика выбран инструмент с лицензией имеющей потенциальную опасность вендорлока Так уже вендерлок во всё ведро) Форкни системду например
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #426

136. Сообщение от Аноним (138), 22-Июн-22, 14:38	+/–
Не для вас написано, молодой человек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

137. Сообщение от Аноним (138), 22-Июн-22, 14:40	–1 +/–
>на нормальном языке >C++ Чел... Одно в гайке хорошо - она работает и неплохо выглядит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #205

138. Сообщение от Аноним (138), 22-Июн-22, 14:45	+/–
Да что ты такое пишешь то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

140. Сообщение от Аноним (123), 22-Июн-22, 14:49	+2 +/–
Ваш комментарий как яркая демонстрация того, что кое-где не могут представить — как это старики на велосипедах ездят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

141. Сообщение от Аноним (141), 22-Июн-22, 14:56	–2 +/–
>интересно зачем, когда есть всякие Сорян, но у тебя со здоровьем всё хорошо? Большего бреда от любителей раста я ещё не встречал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

143. Сообщение от Аноним (143), 22-Июн-22, 15:00	+/–
Ждем дополнения в виде Golang и Ziglang
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #152, #180

149. Сообщение от Аноним (149), 22-Июн-22, 15:23	+1 +/–
> Если начнут писать модули на Расте каков их будет среднестатистический бинарный размер? Если программа на расте будет делать тоже самое, что программа на сях, то размер будет одинаковый. > Только не говорите мне, что надо каждый раз отключать включёные по умолчанию функции дебага. А зачем у тебя по умолчанию включён дебаг? > Если начать компилировать исходные коды на Расте, сколько ждать? Без разницы - конечные пользователи устанавливают готовый бинарь. Даже если захочется самому собрать - это разовая операция. > Одинаковая реализация в процедурном стиле среднестатистического алгоритма на чистом Си будет занимать меньше строк чем на Расте? Прогресс в развитии языков наоборот, позволяет писать код менее громоздко, но при этом более понятно. > Ребята передайте Линусу пусть он пока не пускает Раст в ядро! Ты бы поинтересовался мнением программистов - за и против раста. Это более продуктивно было бы, чем, ничего самостоятельно не понимая выдумывать проблемы и обращаться за решением к диктатору, который сделает лично тебе хорошо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #174, #190

151. Сообщение от Аноним (151), 22-Июн-22, 15:35	+/–
>На нём явно поприятнее писать Субъективщина же. Я в своё время с радостью свалил с Паскаля на C++, не в последнюю очередь из-за многословности синтаксиса первого. Предполагаю, большинству кодеров больше по душе C-like.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #509

152. Сообщение от Без аргументов (?), 22-Июн-22, 15:49	+2 +/–
Эти с флагами не ходят и всюду не пихают, полноценные люди. И в мазилла фондашион лидера-гетеросексуала не смещают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #282, #284

153. Сообщение от АнонимГоним (?), 22-Июн-22, 15:52	+/–
Интересно, создатель Rustа это ж один из, трех что-ли, челов, которые в каком-то там институте делали проект безопасного надмножества C. Чому тот C не взлетел, чому на нем не пробовали писать для ядра, может постепенный переход с простого C на "не простой" а потом уже когда-нить на Rust было б проще воспринимать, хм.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #178

154. Сообщение от Аноним (154), 22-Июн-22, 16:01	+/–
Интересая новость. Вот недавно Линус разрешил-таки наконец использовать С11. Через 11 лет после появления стандарта. Отсюда вопрос. Какая версия rust будет доступна в ядре?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #156

155. Сообщение от Аноним (156), 22-Июн-22, 16:07	+/–
>  Использование Rust для разработки драйверов позволит с минимальными усилиями создавать безопасные и более качественные драйверы, избавленные от таких проблем как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера... Эта мантра также обязательна в любом тексте про Rust как и "<Организация> запрещена на территории РФ"?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #200

156. Сообщение от Аноним (156), 22-Июн-22, 16:09	+1 +/–
Ты новость читал? Прочитай с места > Торвальдс упомянул о возможности скорой интеграции в ядро Linux компонентов для разработки драйверов устройств на языке Rust. Не исключается, что патчи с поддержкой Rust будут приняты в ближайшем окне приёма изменений, формирующем состав ядра 5.20...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #162

161. Сообщение от Тычок (?), 22-Июн-22, 16:43	+1 +/–
$ cd /tmp $ git clone https://github.com/haiku/haiku Cloning into 'haiku'... remote: Enumerating objects: 773152, done. remote: Counting objects: 100% (2529/2529), done. remote: Compressing objects: 100% (1078/1078), done. remote: Total 773152 (delta 1515), reused 2315 (delta 1416), pack-reused 770623 Receiving objects: 100% (773152/773152), 429.84 MiB | 11.41 MiB/s, done. Resolving deltas: 100% (600679/600679), done. Updating files: 100% (32232/32232), done. $ cd haiku/ $ cloc .    26383 text files.    26144 unique files.     6584 files ignored. github.com/AlDanial/cloc v 1.82  T=32.28 s (614.6 files/s, 147654.1 lines/s) --------------------------------------------------------------------------------------- Language                             files          blank        comment           code --------------------------------------------------------------------------------------- C++                                   5845         416467         206441        1540805 C                                     2328         131884         213995         776295 C/C++ Header                          7785         168050         174111         711176 HTML                                  1988          26006          27508         232928 INI                                     24           3264              0          30168 Jam                                   1316           6647           1555          28362 Assembly                               258           3109           4914          11246 reStructuredText                        83           3349            453          10477 Windows Module Definition                8            202              0           5186 Bourne Shell                            98           1341           1201           4771 yacc                                     4            510            229           3525 Python                                  20            896           1300           2414 XML                                      2            329              0           2003 JavaScript                               2            551             55           1968 CSS                                     10            377            326           1817 SVG                                      7              1              4           1427 Markdown                                12            240              0           1018 PHP                                      1            136            114            660 TeX                                      1             83             31            500 awk                                      5             94            177            476 lex                                      3            117             86            425 Pascal                                   8             54              4            370 JSON                                     6              0              0            258 make                                    10            180            621            195 Bourne Again Shell                       4             23             21            168 Scheme                                   1             27             28            131 Perl                                     1             13              1            128 vim script                               3             10             33             63 Dockerfile                               2             15             10             61 GLSL                                     2             15             20             42 YAML                                     1              1              0             35 Ruby                                     1              3             11             25 --------------------------------------------------------------------------------------- SUM:                                 19839         763994         633249        3369123 ---------------------------------------------------------------------------------------
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

162. Сообщение от Аноним (154), 22-Июн-22, 16:45	+/–
И? Какая версия rust? И как часто ее можно будет увеличивать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #163, #288, #452

163. Сообщение от Попандопала (?), 22-Июн-22, 17:11	+/–
По факту наличия стабильной версии наверняка и главное есть кому поддерживать, иначе финн бы не одобрил. Парагонцы же чуть обгадились ливнув в запой понадеясь на сообшество тысячаглаз. D В любом случае ядро очевидно форкнут в стиле нераст-кернел. рейзер4 кернел же есть и прекрасно себя чухает.XD
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #266, #293

164. Сообщение от Аноним (164), 22-Июн-22, 17:22	+/–
> обязательной инициализации значений переменных перед использованием А разве может быть иначе?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #185, #333

165. Сообщение от Мохнатый пись (?), 22-Июн-22, 17:45	+1 +/–
Смешная шутка, пытался запустить эту вашу гайку на не самом свежем r5 1600+rx580, дальше загрузочного фона дело не пошло. Отличная система.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #183

166. Сообщение от Аноним (166), 22-Июн-22, 17:45	+1 +/–
>Поддержка Rust преподносится как опция, не активная по умолчанию и не приводящая к включению Rust в число обязательных сборочных зависимостей к ядру Ништяк. А то этот пакет в генте иногда напоминает маньяка своим упорным стремлением прописаться в мир.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #439

167. Сообщение от Аноним (167), 22-Июн-22, 17:51	+4 +/–
Нафиг раст? Надо просто пользоваться при разработке прог интерфейсами, которые менеджатся компилятором, а так же завести в православный си/си++ аналог фастмм, чтобы утечки памяти искал и доступ к освобожденной памяти. А то пишут на каких то языках из прошлого века и все время жалуются, что память течет и уязвимости на каждом шагу.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #177, #306

170. Сообщение от псевдонимус (?), 22-Июн-22, 18:13	+1 +/–
формально управляющего сверхдержавой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

171. Сообщение от Аноним (171), 22-Июн-22, 18:23	–1 +/–
Там, где начинаются ненужные слои абстракции и ненужная забота о чрезмерной безопасности, там заканчивается быстродействие и качество кода. Жаль что Линус стар и ему уже все равно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #181

173. Сообщение от Андрей (??), 22-Июн-22, 18:25	+/–
> Если начать компилировать исходные коды на Расте, сколько ждать? Половину дня? Люди говорят, что исходники на Расте и C++  компилируются очень долго. А до включения Раста ядро можно было скомпилировать прям на ходу при запуске с помощью tcc (Tiny C Compiler). Не говоря уже про время сборки самого компилятора. Ведь Раст - это не только сам Раст, но ещё и монстр LLVM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #228

174. Сообщение от Андрей (??), 22-Июн-22, 18:31	+/–
> Без разницы - конечные пользователи устанавливают готовый бинарь. Даже если захочется самому собрать - это разовая операция. Особенно, когда тебе говорят попробовать найти баг с помощью git bisect. Да и корректирующие релизы ядра выходят не раз в полгода. Так что далеко не разовая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #226

175. Сообщение от Андрей (??), 22-Июн-22, 18:33	+3 +/–
Печально, что у Линуса не осталось больше аргументов, чтобы не допустить прохода экспериментального языка в промышленный проект.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #179, #236

177. Сообщение от Аноним (149), 22-Июн-22, 18:39	–1 +/–
> Нафиг раст? Надо просто пользоваться Пользуйся. А другие программисты будут пользоваться тем, что они считают более полходящим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167

178. Сообщение от Аноним (138), 22-Июн-22, 18:40	+1 +/–
Ты думаешь, тебе будут делать безопасные языки, приносить прямо в руки, пиарить на весь интернет, только возьми? Как это должно работать, по-твоему?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #451

179. Сообщение от Аноним (149), 22-Июн-22, 18:41	–2 +/–
Ага, ты небось до сих пор плёночным фотоаппаратом пользуешься, и почту лошадьми гоняешь? Не пользоваться же всеми этими экспериментальными технологиями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #206, #223, #302

180. Сообщение от Аноним (104), 22-Июн-22, 18:45	+2 +/–
Golang - не системный язык с GC, не подходит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #186

181. Сообщение от Ананимус (?), 22-Июн-22, 18:48	–2 +/–
Да, C давно пора выкинуть в окно как ненужную прослойку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171

182. Сообщение от Аноним (182), 22-Июн-22, 18:48	+/–
> Подробнее - в статье =) Почти нажал. Но - нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

183. Сообщение от Аноним (138), 22-Июн-22, 18:51	+1 +/–
Попробуй на каком-нибудь старье.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #268, #269

185. Сообщение от Аноним (138), 22-Июн-22, 18:59	+2 +/–
Конечно, те же пгавославные С, С++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164

186. Сообщение от Аноним (138), 22-Июн-22, 19:05	–1 +/–
Почему не добавить GC в ядро?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180 Ответы: #248, #449

188. Сообщение от Аноним (-), 22-Июн-22, 19:11	+1 +/–
Пропала переносимость, пропал калабуховский дом.
Ответить | Правка | Наверх | Cообщить модератору

189. Сообщение от Аноним (189), 22-Июн-22, 19:33	+/–
Поддерживаю интерес!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

190. Сообщение от Аноним (189), 22-Июн-22, 19:46	+2 +/–
> Прогресс в развитии языков наоборот, позволяет писать код менее громоздко, но при этом более понятно. Ну все, Я понял, почему программы так пожирнели последнее время. ;) Это чтобы понятность не изменилась! ;) ;) ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #227

191. Сообщение от Аноним (120), 22-Июн-22, 19:52	+2 +/–
На словах всё просто. А там то Libc не совсем такая, то ещё чего. Ну собери Qt 5.15.3, например, под неё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #274

193. Сообщение от Аноним (-), 22-Июн-22, 20:03	+/–
Смищно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #209

195. Сообщение от freehck (ok), 22-Июн-22, 20:06	+/–
> Так может на OCaml? Так уже есть Mirage.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

196. Сообщение от Аноним (58), 22-Июн-22, 20:13	+1 +/–
>Не подскажете куда лучше переходить? FreeBSD, OpenBSD или может быть Mac OS X? HaikuOS!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

197. Сообщение от freehck (ok), 22-Июн-22, 20:15	+/–
>>> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++? >> Потому что Линус в гробу видал C++. > Линус тогда сказал именно то, что от него хотели услышать люди, писавшие > ядро на Си. Действовал в интересах сообщества. Ты сейчас не Линуса описываешь. Линус тебе покажет средний палец и объяснит, что у тебя в голове дepьмо. Последнее, чем он будет заниматься, это писать то, что ты от него хочешь услышать. =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #250

200. Сообщение от microsoft (?), 22-Июн-22, 21:16	+1 +/–
Фанатики, сэр.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #324

201. Сообщение от snmp agent (?), 22-Июн-22, 21:16	+3 +/–
GNURust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

202. Сообщение от Аноним (202), 22-Июн-22, 21:21	+/–
И почему нельзя назвать новую версию 6.0 из-за новой функциональности? Или старый пердун опять будет ждать, когда моча в голову стукнет?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #289

203. Сообщение от Ан (??), 22-Июн-22, 21:22	+1 +/–
DragonflyBSD
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #327

205. Сообщение от torvn77 (ok), 22-Июн-22, 21:42	+/–
>Одно в гайке хорошо - она работает и неплохо выглядит.   Посмотрел, она девушка лёгкого поведения(MIT), так что в жёны я её несмотря на красоту не буду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #276

206. Сообщение от Bdfybec (?), 22-Июн-22, 22:09	+3 +/–
Аналогия не твой конёк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179

207. Сообщение от ilowry (?), 22-Июн-22, 22:12	+1 +/–
Будет теперь инклюзивное ядро.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #218, #221

208. Сообщение от keydon (ok), 22-Июн-22, 22:23	+1 +/–
Меня тоже забыли спросить. Делают растоподдержку для 1,5 хипстеров из гугла и мелкософта. Первые поиграются и забьют. Вторые будут EEE'кать. А возиться все-равно придется мейнтейнерам ядра (нет, я не мейнтейнер, я мимокрокодил).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #231

209. Сообщение от Аноним (209), 22-Июн-22, 22:33	+9 +/–
> Смищно. А что плохого в этом совете? Ядро windows не написано на rust, не имеет systemd, pulseaudio, gnome и других подобных нехороших вещей которые ненавидят эксперты с opennet, а значит подходит больше чем Linux
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #245, #279

212. Сообщение от Аноним (212), 22-Июн-22, 22:58	+/–
Сам будешь портировать, сам и поддерживать. И кланяться, обязательно с подписью CLA, DCO и сдачей ДНК-биометрии в подтверждение, что в случае, если код не лицензионно чист, то что ты заранее жопу копирастам подставил. И не факт, что примут. Сопровождающие ядра там тебе ничего не должны. Захотят - вообще возможность запуска на твоем "калькуляторе" выпилят. Но давайте начистоту. Ядро и так жирное, собирается долго, и сами его из юзеров и разрабов никто не собирает. А если даже и собирает, то для той архитектуры драйвера на расте никто писать не будет, если раст её не поддерживает. Но раст даже микрухи теперь поддерживает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #220

217. Сообщение от Аноним (219), 22-Июн-22, 23:06	+2 +/–
Я на FreeBSD дано. Потому что это единственная ОС (а не набор пакетов), в свободном мире.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

218. Сообщение от Аноним (138), 22-Июн-22, 23:06	+1 +/–
Бодипозитив.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207

219. Сообщение от Аноним (219), 22-Июн-22, 23:07	+/–
JS как раз клал на жто всё, вместе с теми кто на нем "пишет".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

220. Сообщение от Аноним (220), 22-Июн-22, 23:08	+/–
А я где-нибудь сказал, что буду в апстрим проталкивать? Для себя и для того парня, и только для LTS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212

221. Сообщение от Аноним (46), 22-Июн-22, 23:09	+2 +/–
Это конец.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207

223. Сообщение от Аноним (46), 22-Июн-22, 23:14	+/–
> плёночным фотоаппаратом Не поверишь, до сих пор есть студии проявки киноплёнки... Да, её используют профессионалы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #492

225. Сообщение от Аноним (138), 22-Июн-22, 23:32	+1 +/–
Тем временем C++ (орфография сохранена, ... - это именно троеточие, прямо в коде) template<class T, class... Args> inline T& fn(Args&&... args) {
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #252

226. Сообщение от Аноним (226), 23-Июн-22, 00:04	+/–
Ты модуль ядра решил компилировать что ли, раз тебе бисект потребовался? Тогда бы ты знал что занимаешься его разработкой и не говорил что бинарно бисектить собрался. Короче мимо парень
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174 Ответы: #437

227. Сообщение от Аноним (226), 23-Июн-22, 00:08	+/–
Очередной любитель оптимизаций по хдд. Прогрессу плевать на твои желания, адаптируйся или деприсируй 🤣
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190 Ответы: #230, #247

228. Сообщение от Аноним (226), 23-Июн-22, 00:10	+/–
Можно, и можно будет, но зачем? И так и так всё равно нужно будет тюнить флаги компиляции… вот правда зачем тебе то дерьмо мамонта?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173

230. Сообщение от Аноним (138), 23-Июн-22, 00:24	+/–
Сначала такой >адаптируйся или деприсируй 🤣 а потом >меня-то защооо?!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #227

231. Сообщение от Аноним (231), 23-Июн-22, 02:28	+/–
Так суть раста в ЕЕЕ и есть. На какой проект,  где он внедряется, ни посмотри, везде идет раздувание сборочных зависимостей, забивание на поддержку платформ и завязывание всего на пару расто-фанатов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208

232. Сообщение от _kp (ok), 23-Июн-22, 02:42	+3 +/–
А смысл? По проблемам человечкого фактора с Си он одинаков. А синтаксис, помимо многословности, деревянный, логика исполнения неоднозначная. Помимо begin end, в исходнике ещё круглых скобок требуется заметно больше чем на Си. За одно объявление переменных,там, далеко, где то вначале, неплохо бы автору по пальцам настучать. Во времена Delphi приходилось переписывать с Си на Паскаль. В итоге получали, более многословный и менее читаемый код, с проблемами из за неоднозначной логики его исполнения. Битовые поля и работа с указателями зерез задницу, плюс куча костыльных пременных. В общем, выходит только хуже. В принципе, если хочется, драйвер возможно написать и на Паскале и на Си++, но он будет в таком виде никому не нужен. И... если человек утвержает, что на Паскале __поприятнее__ писать "дрова", то именно драйвера он точно не писал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #267

233. Сообщение от burjui (ok), 23-Июн-22, 02:47	+1 +/–
Это пока на нём не начнёшь писать. Вот уж где пригодится метод скоростной слепой печати.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

234. Сообщение от burjui (ok), 23-Июн-22, 02:49	+/–
То ли дело старое поколение, которое сразу пишет идеальный код, без единой ошибки на миллион строк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #242

235. Сообщение от burjui (ok), 23-Июн-22, 03:08	+4 +/–
> Короче, в голову приходят страшные мысли. А вот если будешь изучать язык, читать документацию и писать программы, будут приходить ещё и умные. На все твои вопросы есть очевидные ответы. Но тебе нужны не ответы, а солидарность таких же хейтерков, у которых других проблем нет в жизни, кроме Rust, который прямо-таки давит на мозги, покоя не даёт. Ну как же, придётся работать не с сырыми указателями, а со ссылками, думать, кто владеет памятью, у кого доступ на чтение, а у кого - на запись, а то же "буручекир заругаит", ещё всякие дженерики и трейты - того гляди, последняя извилина перегорит. А ещё скобочек много, глаза болят. То ли дело православная сишка, в которой скобок меньше и код красивый, как женская сися, накидал указателей, погонял немного (код, а заодно и лысого на код)... ну, раз не падает, значит багов нет. Статическая верификация - для слабаков, а настоящий программист не примет помощи от какого-то там компилятора, и вместо 100 строк unsafe кода будет читать столько кода, сколько потребуется. Заодно и наизусть выучит, чтобы потом зайти на сервер и набрать заново, потому что Git - тоже для слабаков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #323

236. Сообщение от Ананимус (?), 23-Июн-22, 05:12	+/–
Ты код ядра видел вообще? Там говно и костыли на каждом шагу, экспериментальный язык хуже уж точно не сделает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #334, #355, #362

242. Сообщение от Анончик (?), 23-Июн-22, 08:30	+/–
через месяц жизни в gdb развивается умение делать сильно меньше ошибок на си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #234 Ответы: #249

243. Сообщение от EULA (?), 23-Июн-22, 08:41	+/–
Пенсы-огородники на велосипедах частенько катаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123

244. Сообщение от Онаним (?), 23-Июн-22, 08:59	–1 +/–
Вот о <()> они и думали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

245. Сообщение от Онаним (?), 23-Июн-22, 09:01	+1 +/–
На самом деле да, тоже задумываюсь о том, что винда в итоге может оказаться вполне реальной альтернативой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209 Ответы: #264, #278

247. Сообщение от Аноним (189), 23-Июн-22, 09:39	+/–
Оптимизации люблю до определённого предела. Но, постоянная память и особенно ОЗУ они же не резиновые, что бы бросать туда всякий ненужный мусор. Но Вы же (ИМХО) гооооораздо выше таких мелочей (пока Вам этот мусор на голову не начнет сыпаться). Дико извеняюсь, но... Как же Я люблю это Но, оно как правило дремлет, но, как иногда бывает, вот заблудился человек в дебрях технического прогресса, потерялся, растерялся, запутался в чужой да и в собственной лжи, и тут о чудо, Но вдруг неожиданно просыпается, да как подпрыгнет как подскочит, надает заблудшему аплпеух да подзатыльников, повернет в сторону Истины и даст хорошего пинка, что бы Прогрессу было за кем гнатся! ;) А бывает, Но не просыпается. И приходится Прогрессу плеваться и плестись, блудить и плеваться. Грустно?!? :( НО, мы не будем, строить разлапистые теории заговоров, а просто спишем все на простую человеческую ... мудрость! ;) Если под словом деприсируй Вы имели ввиду пресс, то мне больше нравится, элиминируй, в данном контексте. О своих желаниях Я тайно поведал в предыдущем своем посте. Об остальных, скромно умолчу ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #227

248. Сообщение от Аноним (151), 23-Июн-22, 09:42	+/–
В принципе, есть экспериментальные реализации OS на Go. Это возможно, но вряд ли целесообразно. Хотя практика и эксперименты буйных голов покажут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186

249. Сообщение от burjui (ok), 23-Июн-22, 10:12	+3 +/–
Здорово. А я уже лет 6 не запускал gdb за ненадобностью, потому что перешёл с C++ на Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #242 Ответы: #285, #294, #433

250. Сообщение от n00by (ok), 23-Июн-22, 10:16	+/–
>>>> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++? >>> Потому что Линус в гробу видал C++. >> Линус тогда сказал именно то, что от него хотели услышать люди, писавшие >> ядро на Си. Действовал в интересах сообщества. > Ты сейчас не Линуса описываешь. Линус тебе покажет средний палец и объяснит, > что у тебя в голове дepьмо. Последнее, чем он будет заниматься, > это писать то, что ты от него хочешь услышать. =) Это ты сейчас отвечаешь не на мой комментарий, а на какой-то выдуманный. Я не пишу ядро Lunux, потому не вхожу в множество людей, чьи интересы Линус учитывает. Что касается пальцев - Микрософт показывал мне однажды, официально заявляя, что Си++ невозможно у них в ядре. Но оказалось возможно. Так что и палец Линуса не оказал бы воздействия. Другое дело, что Си++ _не_нужно_ в дереве исходников ядра Linux.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #253

252. Сообщение от n00by (ok), 23-Июн-22, 10:25	+/–
> Тем временем C++ (орфография сохранена, ... - это именно троеточие, прямо в > коде) > template<class T, class... Args> > inline T& fn(Args&&... args) { Точнее, многоточие. Внезапно, в данном случае оказывается интутивно-понятно. Хотите "грузить" - налегайте на && и move semantics. Я бы уже загрузился. ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #262

253. Сообщение от freehck (ok), 23-Июн-22, 10:34	–1 +/–
Ты не понял ничего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250 Ответы: #255, #263, #346

255. Сообщение от n00by (ok), 23-Июн-22, 10:42	+/–
Я _сделал_ когда-то то, чем ныне заняты растоманы. А вот если ты не смог мне что-то объяснить - это да, потому что я туповат. ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253 Ответы: #429

256. Сообщение от Аноним (258), 23-Июн-22, 11:16	+/–
> не исключил возможность Это надо срочно в новость!
Ответить | Правка | Наверх | Cообщить модератору

257. Сообщение от InuYasha (??), 23-Июн-22, 11:19	+/–
typedef goatse :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

258. Сообщение от Аноним (258), 23-Июн-22, 11:22	+/–
> Раст, внезапно, функциональный. в расте функции - первоклассные объекты, можно ими жонглировать как душе угодно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #260

259. Сообщение от Аноним (258), 23-Июн-22, 12:35	+/–
А в расте - больше, потому что динамическая линковка с libc.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #295, #436

260. Сообщение от n00by (ok), 23-Июн-22, 12:43	+/–
>> Раст, внезапно, функциональный. > в расте функции - первоклассные объекты, Если верить Википедиям, то и Си++ они первоклассные https://en.wikipedia.org/wiki/First-class_function#Language_... > можно ими жонглировать как душе угодно? Он же компилируемый - так что есть нюансы с eval. Через пару лет можно будет оформить в виде llvm.ko. Зато "переменные" иммутабельны по умолчанию, не требуется императивный return. Вот обычные для ФЯ конструкции:     let y = {         let x = 3;         x + 1     }; fn five() -> i32 {     5 } https://doc.rust-lang.org/book/ch03-03-how-functions-work.html Осталось прикрутить к этой безусловно полезной абстракции отображенные в память регистры контроллера...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258 Ответы: #286, #435

262. Сообщение от Аноним (138), 23-Июн-22, 13:13	+/–
Это код из реального проекта, который судя по всему пишут компетентные разработчики, может поэтому и понятен. Но даже это кажется бессмысленной лапшой для человека, котрый знаком с хорошими языками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252 Ответы: #265

263. Сообщение от n00by (ok), 23-Июн-22, 13:14	+/–
И ещё я не понял, как найти твои коммиты в ядро. По фамилии из профиля не находит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253 Ответы: #345

264. Сообщение от Аноним (138), 23-Июн-22, 13:16	+1 +/–
Прыгать с одной блоатваре на другую...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245 Ответы: #270, #281

265. Сообщение от n00by (ok), 23-Июн-22, 13:19	+/–
> Это код из реального проекта, который судя по всему пишут компетентные разработчики, > может поэтому и понятен. Не сочиняйте. Fn - это foo. > Но даже это кажется бессмысленной лапшой для > человека, котрый знаком с хорошими языками. "Интуитивно-понятно" в моём ответе выше следует понимать как "исходя из знания грамматики русского языка".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262 Ответы: #272

266. Сообщение от Аноним (154), 23-Июн-22, 13:20	+/–
> По факту наличия стабильной версии наверняка и главное есть кому поддерживать, иначе финн бы не одобрил. Насколько я понимаю, он на данный момент смотрит только на "возможна ли хоть какая-то польза". На инфраструктуру внимания не обращал. Хотя, конечно, учитывая опыт использования системы контроля версий, я был бы за такой вариант. Посмотреть как и что, и запилить свое без cargo и бабочек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163

267. Сообщение от Аноним (138), 23-Июн-22, 13:23	+2 +/–
Как же вам печёт от begin end и объявления переменных, любо дорого посмотреть. Видимо си правда оказывает какое-то влияние на мышление. >круглых скобок требуется заметно больше чем на Си Медитируй: if (!((ch >= 0x0FF10) && (ch <= 0x0FF19)) ||      ((ch >= 0x0FF21) && (ch <= 0x0FF3A)) ||      ((ch >= 0x0FF41) && (ch <= 0x0FF5A))) Код на паскале сам осилишь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #232 Ответы: #271, #308, #505

268. Сообщение от Алексей Михайлович (?), 23-Июн-22, 13:30	+/–
А если старья уже нет, как быть? Авито не предлагать, я найду своим деньгам более годное применение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #273

269. Сообщение от Алексей Михайлович (?), 23-Июн-22, 13:31	+/–
А если старья уже нет, как быть? Ав*то не предлагать, я найду своим деньгам более толковое применение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183

270. Сообщение от Онаним (?), 23-Июн-22, 13:33	+1 +/–
Возможно у винды в до кучи будет свой прослоечный форк ядра, не зря же они WSL2 пилят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #264

271. Сообщение от n00by (ok), 23-Июн-22, 13:38	+1 +/–
В С89 объявление переменных было как в Паскале. При этом вложенных процедур там не было, потому и сняли ограничение. И речь тут про ядро, а не холивар языков. В Виндосе некоторые писали драйвера на Дельфи, потом, как правило, переписывали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #275, #490

272. Сообщение от Аноним (138), 23-Июн-22, 13:44	+/–
Не сочиняю, увидел вызов fn<X>(args) и стало интересно, что за лапша. Оно мало того, что оказалось перегружено, так ещё и вот в такой форме. Нет, исходя только из грамматики русского языка, смысл этого кода понять не получится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #265 Ответы: #297

273. Сообщение от Аноним (138), 23-Июн-22, 13:50	+/–
>если старья уже нет Живи одним днём? Ну, значит без хайку. С линуксами та же беда, не везде запускаются, из-за этого в своё время бросил это занятие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #268

274. Сообщение от Аноним (138), 23-Июн-22, 13:52	–1 +/–
Qt должно же быть уже собрано?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191

275. Сообщение от Аноним (138), 23-Июн-22, 13:57	+/–
Про С89 интересно. Как это не холивар? А что тогда?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #271

276. Сообщение от Аноним (138), 23-Июн-22, 14:01	+/–
Хорошая, либеральная лицензия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205

278. Сообщение от Аноним (278), 23-Июн-22, 14:26	+1 +/–
Windows гораздо больше подходит для open source чем Линукс, так как для винды больше свободных программ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245 Ответы: #280, #287

279. Сообщение от Аноним (278), 23-Июн-22, 14:32	+1 +/–
И Wayland, и snap, и flatpack, и hig Все эти плохие программы отсутствуют на винде, а значит она лучше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209 Ответы: #292

280. Сообщение от Онаним (?), 23-Июн-22, 14:35	+/–
Чичиго?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #278

281. Сообщение от Онаним (?), 23-Июн-22, 14:38	+/–
Из серьёзных минусов винды сейчас - там всё не просто плохо, а очень плохо с поддержкой сетевых технологий. Изначально заточились на оффлоуд всего "лишнего", вплоть до VLAN, на сетевые платы, а оффлоуда у вендоров не случилось. В итоге чтобы банально несколько вланов принять - нужно плясать с бубном через HyperV ныне.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #264 Ответы: #283

282. Сообщение от Аноним (278), 23-Июн-22, 14:39	+/–
В этом вся суть так называемых программистов на rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

283. Сообщение от Онаним (?), 23-Июн-22, 14:39	+/–
(под оффлоудом в данном случае понимается не собственно процессинг пакетов, который кстати местами есть, а именно возможность конфигурации данных функций, некоторые драйверы умеют, некоторые нет)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #281

284. Сообщение от Аноним (278), 23-Июн-22, 14:42	+/–
Они не в состоянии понять архитектуру компьютера и систем, но лезут в ядро со своим так называемым системным, так называемым безопасным языком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #332

285. Сообщение от Sw00p aka Jerom (?), 23-Июн-22, 14:50	+/–
> Здорово. А я уже лет 6 не запускал gdb за ненадобностью, потому > что перешёл с C++ на Rust. мы же когда подходим к бармену не говорим "сделай мне смузи по такому вот рецепту".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249

286. Сообщение от Аноним (258), 23-Июн-22, 15:00	+/–
> Вот обычные для ФЯ конструкции: Уровень детсада. Где передача функций, как объектов, каррирование, композиция функций и прочая ненизкая математика?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #260 Ответы: #291, #298

287. Сообщение от Аноним (138), 23-Июн-22, 15:08	+/–
Не свободных, а бесплатных. Свободная - это открытый код под лицензиями GPL, BSD, MIT и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #278 Ответы: #317

288. Сообщение от Аноним (-), 23-Июн-22, 15:23	+/–
>И? Какая версия rust? Модная, модная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

289. Сообщение от Bdfybec (?), 23-Июн-22, 15:26	+/–
Новость про возможное прикручивание Rust. Соответственно, новая функциональность на его основе в ядре отсутствует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

290. Сообщение от Аноним (290), 23-Июн-22, 15:28	+1 +/–
Это начало конца...
Ответить | Правка | Наверх | Cообщить модератору

291. Сообщение от Аноним (-), 23-Июн-22, 15:34	+/–
>Уровень детсада. В системном программровании нужна только процедурщина. >Где передача функций, как объектов, каррирование, композиция функций и прочая ненизкая математика? А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном программировании не нужна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #286 Ответы: #299, #442

292. Сообщение от Аноним (-), 23-Июн-22, 15:42	+/–
Толсто. Windows сама по себе Зло!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #279

293. Сообщение от Аноним (-), 23-Июн-22, 15:44	+/–
>чухает. Переведи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163

294. Сообщение от Анончик (?), 23-Июн-22, 15:49	+/–
За Rust не скажу, только неллоу ворлд запускал и примеры из растбука. А на плюсах дебаггер запускал сильно меньше, но это было очень давно и код там был тривиальный. Логику на плюсах писать сильно приятней было чем на сях. Опираясь на то что я видел в расте, логику там писать приятней чем в плюсах (я так думаю, но опыта коммерческой разработки на раст у меня нет)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249

295. Сообщение от Анончик (?), 23-Июн-22, 15:54	+/–
ямеюсь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #259

297. Сообщение от n00by (ok), 23-Июн-22, 15:59	+/–
> Не сочиняю, увидел вызов fn<X>(args) и стало интересно, что за лапша. Оно > мало того, что оказалось перегружено, так ещё и вот в такой > форме. В живом проекте кто-то назвал функцию fn? Это невозможно. > Нет, исходя только из грамматики русского языка, смысл этого кода понять не > получится. Пишите честно: "мне не удалось понять".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #272 Ответы: #300

298. Сообщение от n00by (ok), 23-Июн-22, 16:07	+/–
>> Вот обычные для ФЯ конструкции: > Уровень детсада. Где передача функций, как объектов, каррирование, композиция функций > и прочая ненизкая математика? Наберите интересующие слова в поисковике и читайте. Как должно быть понятно из первой ссылки, которую Вы заботливо вырезали при цитировании, там всё это можно найти. Я лишь намекаю, что функциональное программирование это не только лямбда исчисление.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #286 Ответы: #301

299. Сообщение от n00by (ok), 23-Июн-22, 16:25	+/–
> А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном > программировании не нужна. Смысл функционального программирования не в этих всех замыканиях. Если процедура хранит состояние, то для одних и тех же входных данных она может давать различный результат. Отсюда следует идея чистых функций и иммутабельности: если состояние не хранить, тогда можно на этапе трансляции доказать корректность кода -- как раз это в Rust и называют "безопасность". По той же причине в императивных языках по возможности стараются писать const. Но в реальном железе имеем const volatile. =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #291 Ответы: #444

300. Сообщение от Аноним (138), 23-Июн-22, 16:28	+/–
Пишите честно: "мне удалось понять, зная грамматику русского языка, программирование, имея 10 лет опыта в С++, зная стандарты С++2014, С++2019 и и.д.", а то какие-то двойные стандарты, к одним словам докапываешься (fn), а С++ную лапшу - игнорируешь. Теперь понятно, откуда тёрки с росой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #297 Ответы: #337

301. Сообщение от Аноним (258), 23-Июн-22, 16:30	+/–
> Я лишь намекаю, что функциональное программирование это не только лямбда исчисление. Еще один невзрослый тезис. Не надо приравнивать некоторые элементы ФП и само ФП. Функциональное программирование - это именно жонглирование функциями. Как в расте передать композицию функций, особенно вернуть как результат, особенно с захватом локальных значений?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #298 Ответы: #339

302. Сообщение от Аноним (154), 23-Июн-22, 16:51	+/–
Я так понимаю, ты из тех, кто уже купил электрокар с автопилотом и во время езды ... книжки читает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #304

304. Сообщение от Ананимус (?), 23-Июн-22, 16:57	+/–
Ты хочешь сказать что индусам из мелланокса, которые из сетевого драйвера общий slab портят, доверия больше?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #302 Ответы: #354

305. Сообщение от sager (?), 23-Июн-22, 17:04	+/–
ну так лет пять убивать будут эт точно, а там и фуксия подоспеет. то же самое, что с файрфокс произошло - как по нотам с теми же действующими лицами
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #425

306. Сообщение от Аноним (-), 23-Июн-22, 17:58	+1 +/–
Вот что же все разрабы ядра такие тупые и за столько лет не догадались это сделать... И тут пришел анон с опенька и все разложил по полочкам!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #307

307. Сообщение от Аноним (138), 23-Июн-22, 18:08	+2 +/–
Ну так и есть, анон умный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #306

308. Сообщение от _kp (ok), 23-Июн-22, 18:16	+/–
>>круглых скобок требуется заметно больше чем на Си > Код на паскале сам осилишь. Конечно, я знаю про паскалевский case c диапазонами. В данном случае жирный плюс. Но когда надо перенести батарею подобных и хуже конструкций: chk_rec( get_iRec() + (i>=1 && i <= 4 ? (const uint32_t[]){ 1500, 600, 65, 8 }[i-1] : 1), skip); То плодятся временные переменные и константы, и раскидываются в разных местах, что от case блока элегантнее не становится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #309

309. Сообщение от Аноним (138), 23-Июн-22, 18:39	+1 +/–
В том примере прямой перевод if (без всяких case) убирает половину сишных скобок. >подобных и хуже конструкций Почему-то не удивлён увидеть именно сишный код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #308

310. Сообщение от Аноним (310), 23-Июн-22, 19:08	+/–
Почему в ядро Linux включают именно:     протекающий, ненадежный, неверифицируемый Rust,     a не безопасный, надежный, верифицируемый SPARK ?!!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #328, #329, #335

316. Сообщение от Аноним (316), 23-Июн-22, 20:54	+1 +/–
Лучше Modula-2. Тоже паскалеподобная, но получше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

317. Сообщение от Аноним (316), 23-Июн-22, 21:01	+1 +/–
Человек правильно написал - свободных. На том же sourceforge полно вещей с gpl, bsd, mit и так далее, но при этом они писались под winapi, а не под posix. Ну а если учесть что всякие зондофоксы, псевдолиброфисы и прочие vi с awk под винду портированы ещё с незапамятных времён, то линупcу гордиться особо и нечем
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #287 Ответы: #322, #484

322. Сообщение от Аноним (138), 23-Июн-22, 22:05	+/–
А можно два-три выдающихся примера? Таких программ, исходники которых под свободными лицензиями, и которые писались под winapi? То, что под winapi есть порты обычных линуксовых программ - и так понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #317 Ответы: #336, #358, #366

323. Сообщение от Sw00p aka Jerom (?), 23-Июн-22, 22:15	+/–
>А вот если будешь изучать язык, совет на вес золота, С бы так изучали
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #235 Ответы: #330, #356

324. Сообщение от Аноним (258), 23-Июн-22, 22:24	+/–
Фанатики - за идею. А тут за бабосы слухи распространяют, ой, "новости о не исключении возможности" пишут. Хотя, деньги - это тоже идея.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200

325. Сообщение от warlock66613 (ok), 23-Июн-22, 22:27	+/–
panic — это только на случай нештатной ситуации. Полно штатных ситуций, когда нужно вернуть ненулевой код возврата. Например, юзер передал в командной строке путь к несуществующему файлу, ну и т. д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

326. Сообщение от warlock66613 (ok), 23-Июн-22, 22:46	+/–
На C++ с эксепшенами или на C++ без эксепшенов? Чисто из любопытства спрашиваю. Я, правда, сравнительно немного работал с C++ продакшен кодом, но всё же работал и ни одного проекта с включёнными эксешенами и штатным RTTI не попадалось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #344

327. Сообщение от warlock66613 (ok), 23-Июн-22, 23:16	+/–
То, что вы, по-видимому, имеете в виду, называется «DragonFly BSD». С пробелом перед «BSD» и большой «F». И там всё довольно плохо с драйверами для видеокарт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

328. Сообщение от warlock66613 (ok), 23-Июн-22, 23:33	+/–
Вам ответить отвлечённо или прагматично? Потому что на Rust приятно писать код. А на SPARK упорешься. Потому что Rust как современный язык отвечает требованиям, предъявляемым современному языку (репозиторий пакетов, вменяемая система сборки, избавление программиста от обезъяньей работы вроде копипаста заголовков методов в интерфейсную часть модуля, и др.), а SPARK — штука древняя. Потому что Rust целенаправленно создавался и создаётся под подобные задачи, и из коробки имеет достойный FFI с Си. Потому что есть инициативная группа (и более широкая масса менее инициативных сочуствующих), желающая видеть Rust в ядре, а для SPARK такой группы не собралось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #310 Ответы: #381, #532

329. Сообщение от yet another anonymous (?), 24-Июн-22, 00:00	+2 +/–
Потому что ядро --- важный и значимый ресурс. Подмять его под себя через инфраструктуру, средства разработки или как ещё --- очень логичная стратегия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #310

330. Сообщение от burjui (ok), 24-Июн-22, 01:21	+/–
Можно его изучать хоть 40 лет, но от ошибок в работе с памятью это не спасёт. Если даже лучшие программисты на планете их совершают, то про опеннетных экспертов я вообще молчу. К тому же, готов поспорить, что большинство из последних не знает и половины ситуаций с undefined behaviour в их любимом языке, потому что компиляторы в большинстве случаев услужливо генерят вменяемый код, а не мусор, как могли бы, согласно стандарту. А в остальных случаях эксперты вынуждены запускать отладчик и с переменным успехом искать, из какой щели сыпется мусор. Заметь, я нигде не говорю, что С - говно и т.п., как здесь принято у местной элиты по отношению к другим языкам. Я просто перечисляю объективные недостатки языка. Если вдруг непонятно, вездесущий undefined behaviour и полное отсутствие проверки указателей со стороны компилятора - это недостатки. Мы не в 80х живём, программы сейчас намного функциональнее, соответственно, их код намного больше, и уже только из-за этого становится практически невозможно писать код на C, лишённый багов, связанных с некорректным обращением к памяти. Чем больше компилятор предотвращает ошибок, тем лучше для всех - и разработчиков, и пользователей. По-моему, это очевидно. Поэтому разработчики ядра, наученные горьким опытом, и готовы включить поддержку Rust в ядро, коль уж сишные стандартизёры, мягко говоря, не очень торопятся улучшать свой ЯП. А вот почему на техническом ресурсе ошиваются толпы луддитов-нарциссов с гипоманией и нездоровой фиксацией на C, мне совсем не очевидно. Может, это религия такая, секта? Это как если бы ты на городской улице сел перекусить бутербродом, а к тебе подбежал небритый косматый человек, одетый в шкуры, и стал бы учить, как разводить баранов и выращивать пшеницу - дескать, это азы выживания, и ты не можешь считаться мужиком, если не бегал полдня с копьём за будущим обедом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #323 Ответы: #341

332. Сообщение от burjui (ok), 24-Июн-22, 02:17	+2 +/–
Зато местные критики - эксперты во всём: в архитектуре (могут написать 10 строчек на асме и знают про кэш), компиляторах (прочитали названия глав в книге с драконом), теории типов (лучший тип - void*), проектировании языков программирования (Rust - плохо, там закорючек много, а вот Pascal - норм, там слова) и телепатии ("они не знаю то", "они не знают это"). При этом свой код не показывают, потому что достигли просветления и поняли, что лучший код - это его отсутствие. Ну, экспертами они видят себя в зеркало. А со стороны больше напоминают потенциальных обитателей психиатрического стационара. Сами-то, поди, в ядро ни строчки не написали за всё время использования Linux, но ни дай бог там кто-то хоть строчку на Rust напишет - всё, конец света, тролльвальдс скатился, луникс пропал, валим на BSD. Ой, а там всё по-другому, разбираться надо, а ещё дров не хватает, бежим назад. Точно так же до этого верещали про systemd, хотя сейчас посади их за дистр с классическим инитом и скриптами - начнутся "вьетнамские" флэшбэки. Специалисты по архитектуре бреда в комментариях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #284 Ответы: #357

333. Сообщение от burjui (ok), 24-Июн-22, 02:24	+2 +/–
Конечно. Инициализация - для слабаков. Настоящие мужики пишут такой код, который правильно работает даже со случайным мусором через нулевые указатели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #364

334. Сообщение от burjui (ok), 24-Июн-22, 02:37	+/–
Тсс, ты чего? Не разбивай хрустальные фантазии онанимов. И вообще, развели тут плюрализм... Одно ядро, один лидер, один язык! Seg fault!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #236

335. Сообщение от burjui (ok), 24-Июн-22, 02:54	+/–
Пфф, а то, что ядро написано на протекающем, ненадёжном, неверифицируемом C, тебя не смущает? Нужно срочно переписать ядро на SPARK! Ну как срочно... на это уйдёт лет 100, учитывая многословность синтаксиса, а также сколько бойлерплейта и контрактов придётся писать к каждой функциональной строчке кода. Код будет в 10 раз больше и никому не нужен, но зато абсолютно безопасен и надёжен. Впрочем, любой код будет абсолютно безопасен, если его не запускать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #310 Ответы: #340

336. Сообщение от _ (??), 24-Июн-22, 04:55	+/–
FAR bro :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #322

337. Сообщение от n00by (ok), 24-Июн-22, 07:13	+/–
Я не знаю новые стандарты плюсов и писал на них, когда variadic templates не было. Delphi / Turbo Pascal / Free Pascal: var FilteredChars: set of [#0..#32,#127,'a'..'z']; var CheckedItems: set of [4,10..38,241,58]; https://en.wikipedia.org/wiki/Ellipsis_(computer_programming)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #300

339. Сообщение от n00by (ok), 24-Июн-22, 07:34	+/–
> Функциональное программирование - это именно жонглирование функциями. Поскольку "жонглирование" не формализовано, процитированное "определение" ФП - демагогическая чушь. Поскольку цирковой термин повторяется дважды - похоже на мантру для некоей секты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #301 Ответы: #347, #348

340. Сообщение от yet another anonymous (?), 24-Июн-22, 07:47	+/–
s/SPARK/Rust/g И что, что-то по сути поменялось в месседже?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #335 Ответы: #350

341. Сообщение от n00by (ok), 24-Июн-22, 07:50	+/–
> А вот почему на техническом ресурсе ошиваются толпы луддитов-нарциссов с гипоманией и > нездоровой фиксацией на C, мне совсем не очевидно. Может, это религия > такая, секта? Может им приходилось принимать участие в разработке ядра? Если они знают Си, это вероятный сценарий. Если это так, значит часть "луддитов" говорит о том, что их так или иначе касается (насколько они правы или ошибаются - это вопрос второй). А вот что делают остальные?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #330 Ответы: #349

344. Сообщение от n00by (ok), 24-Июн-22, 07:55	+/–
Ядро Windows написано на Си, но исключения там используются. Механизм Structured Exception Handling (SEH) похож на Си++ исключения и последние могут быть реализованы поверх него. Штатный RTTI есть в Qt. Судя по возрасту проекта, когда-то там был свой велосипед, но теперь внутри него чистый dynamic_cast.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #326 Ответы: #373

345. Сообщение от n00by (ok), 24-Июн-22, 09:04	+/–
.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #263

346. Сообщение от n00by (ok), 24-Июн-22, 09:04	+/–
Если же у тебя нет коммитов в ядро (согласно тамошних правил, следует указывать реальную фамилию), то возникает другой вопрос: если ты не имеешь отношения к разработке ядра, то какое твоё дело, что происходит в ядре? Вот это можешь объяснить? Не мне, себе объясни, для начала.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253

347. Сообщение от Аноним (-), 24-Июн-22, 10:01	+/–
> "определение" ФП - демагогическая чушь Вот именно, сегодня. Сегодня "определение" ФП - это "парадигма", что есть не формальное определение, а демагогия. Сегодня любой новый модный молодежный язык, в котором есть термин "функция" - это "язык ФП". А вот раньше трава была зеленее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #339 Ответы: #353

348. Сообщение от Аноним (-), 24-Июн-22, 10:04	+/–
Вернемся к нашим баранам. Так как вернуть композицию функций в расте?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #339 Ответы: #351, #481

349. Сообщение от burjui (ok), 24-Июн-22, 10:14	+/–
> Может им приходилось принимать участие в разработке ядра? Если они знают Си, > это вероятный сценарий. Ага, а ещё у них есть руки - значит, вероятно, они маньяки-убийцы, художники, операторы бетономешалки и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #341 Ответы: #352

350. Сообщение от burjui (ok), 24-Июн-22, 10:19	–1 +/–
Если думать не головой, а задницей, то нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #340 Ответы: #359

351. Сообщение от n00by (ok), 24-Июн-22, 10:40	+/–
Ответьте, пожалуйста, отдельным сообщением, когда Вам удастся с Вашими баранами разобраться. Очень интересны вопросы животноводства.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #348

352. Сообщение от n00by (ok), 24-Июн-22, 10:41	+/–
А у Вас есть коммиты в ядро?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #349 Ответы: #365

353. Сообщение от n00by (ok), 24-Июн-22, 10:44	+/–
То есть предмет спора выдуман автором сообщения №258.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #347

354. Сообщение от Аноним (154), 24-Июн-22, 13:40	+/–
> Ты хочешь сказать что индусам из мелланокса, которые из сетевого драйвера общий slab портят, доверия больше? Такие виды ошибки лекго отлавливаются. Проблемы компиляторов, или если копнуть чуть глубже - поломкой совместимости в процессе их разработки, - практически не отлавливаются в таких сложных проектах. Для их отлова нужно интенсивное использование в других - более простых проектах. Отсюда вопрос, сколько времени должно будет пройти пред внедрением новой версии компилятора rust в ядро, если он практически нигде не используется?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #304 Ответы: #416

355. Сообщение от Аноним (154), 24-Июн-22, 13:46	+/–
> Ты код ядра видел вообще? Там говно и костыли на каждом шагу, экспериментальный язык хуже уж точно не сделает. Это ты так решил, что не сделает? И какие у тебя для таких заявлений основания?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #236

356. Сообщение от Sw00p aka Jerom (?), 24-Июн-22, 13:57	+/–
>Участник 'burjui' запретил публикацию ответов ожидаемо >Можно его изучать хоть 40 лет, но от ошибок в работе с памятью это не спасёт. если складывать все яйца в одну корзину, кто виноват? Продавец или курица которая несет ломающиеся яйца? пс: все беды людские - от ума. """ В комедии «Горе от ума» кто умное действующее лицо? ответ: Грибоедов. А знаешь ли, что такое Чацкий? Пылкий, благородный и добрый малый, проведший несколько времени с очень умным человеком (именно с Грибоедовым) и напитавшийся его мыслями, остротами и сатирическими замечаниями. Все, что говорит он, очень умно. Но кому говорит он все это? Фамусову? Скалозубу? На бале московским бабушкам? Молчалину? Это непростительно. Первый признак умного человека — с первого взгляду знать, с кем имеешь дело и не метать бисера перед Репетиловыми и тому подоб. """ Свои критические замечания о произведении высказал А. С. Пушкин в конце января 1825 года в письме А. А. Бестужеву из Михайловского в Петербург.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #323

357. Сообщение от Анончик (?), 24-Июн-22, 14:23	+4 +/–
> местные критики - эксперты во всём Ну так и есть, а что плохого-то? Это вы там в своём загончике пасётесь. Барин сказал systemd, значит systemd. Барин сказал rust, значит rust. Барин сказал, что нужно анализы сдавать, пошли сдавать. Всё для вашей же безопасности, главное не бухтеть, нужно немного подождать и уже скоро будет коммунизм. А пока вот котлетки на ужин. Вам повезло, что эту информацию тут можно почитать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #332 Ответы: #363, #368

358. Сообщение от Аноним (358), 24-Июн-22, 14:32	+/–
notepad++, mpc-hc
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #322 Ответы: #361

359. Сообщение от Аноним (154), 24-Июн-22, 14:35	–1 +/–
> Если думать не головой, а задницей, то нет. Ну так покажи эту разницу тем, кто думает задницей... Или ты то же из таких?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #350 Ответы: #360, #369

360. Сообщение от Анончик (?), 24-Июн-22, 14:48	+/–
А то! 4.332
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #359

361. Сообщение от Анончик (?), 24-Июн-22, 14:57	+/–
Вот это хорошие примеры, но для них есть FOSS аналоги. Все эти разговоры о свободе внутри проприетарной шиндошс, ну такое. FAR вообще не понимаю для кого сделан, никогда им не пользовался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #358 Ответы: #367

362. Сообщение от Аноним (362), 24-Июн-22, 17:17	+/–
Пруфов, как всегда не будет, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #236 Ответы: #415

363. Сообщение от Анончик (?), 24-Июн-22, 20:06	+/–
Чет не сильно удобно сидеть под одним ником
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #357

364. Сообщение от Аноним (209), 24-Июн-22, 20:32	+1 +/–
Обязательная инициализация означает необходимость тратить время процессора и память на ненужную оптимизацию переменных. Для системного программирования, где важен каждый такт, она неприемлема.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #333 Ответы: #374, #385, #511

365. Сообщение от burjui (ok), 24-Июн-22, 20:43	+/–
Нет. Но я и не указываю никому, на чём им писать ядрёный код. Если понадобится, буду писать на Rust, а на C - только если не будет байндингов к нужным API.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #352 Ответы: #384

366. Сообщение от Аноним (-), 24-Июн-22, 20:50	+/–
Старый Free Download Manager (линупcoвый ныне мертвый d4x - жалкая пародия на него), миранда (которая не ng) со всеми ее плагинами, уже упомянутый FAR, SP Forth и так далее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #322 Ответы: #485

367. Сообщение от Аноним (-), 24-Июн-22, 20:59	+/–
Нет в линупce аналогов. Есть жалкие пародии. Например большинство виндовых видеоплееров умеет показывать превью видео при наведении мыши на нужный момент времени без перемотки этого самого видео. Какие линупcячьи плееры так могут? И у небезызвестного mc от того же FAR хорошо если треть функционала есть (а если FAR обвесить плагинами, то на mc без желания обнять и плакать вообще смотреть не получится).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #361 Ответы: #446

368. Сообщение от burjui (ok), 24-Июн-22, 21:01	+1 +/–
Какой ещё барин? Никто никого не заставляет учить Rust, я вот учил по собственному желанию, т.к. нравятся языки ML-семейства и borrow checker. И даже пользоваться Systemd никто не заставляет, дистрибутивов Linux - гора и маленькая тележка. Мне как пользователю Systemd не мешает, конфигурация намного проще, чем с инит-скриптами, система грузится быстрее. Вы - не эксперты, а демагоги с раздутым самомнением и синдромом Даннинга-Крюгера. И то, что вы здесь генерируете - не информация, а информационный шум. На весь Опеннет хорошо если с десяток толковых разработчиков наберётся из активно комментирующих, результаты работы которых можно посмотреть в опенсорсных проектах, а остальные только и могут, что хамить, безосновательно критиковать и рассказывать сказки про то, как они без ошибок пишут на C чуть ли не для космических аппаратов. Невоспитанная школота, начитавшаяся умных книжек, но без критического мышления, которая возомнила себя экспертами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #357 Ответы: #370, #390, #448, #529

369. Сообщение от burjui (ok), 24-Июн-22, 21:10	+/–
Я уже задолбался кому-то что-то объяснять на этом ресурсе. Тем более бессмысленно объяснять что-то тем, кто думает задницей. Никто даже документацию прочитать не в состоянии, не то что попробовать написать что-то более-менее сложное на языке перед тем, как гадить в комменты про "вырвиглазный синтаксис" и прочую чепуху. Сами идите, пишите на обоих языках, а потом сравнивайте объём кода, трудозатраты и КПД своей работы. А заодно подумайте, почему ни один из формально верифицируемых языков даже близко не пошёл в массы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #359 Ответы: #371, #375, #400

370. Сообщение от Анончик (?), 24-Июн-22, 21:33	–1 +/–
> Я - хороший, это они плохие! Понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #368 Ответы: #391

371. Сообщение от Анончик (?), 24-Июн-22, 21:37	+/–
Не нужно ничего объяснять, лучше расскажи, почему ни один из формально верифицируемых языков даже близко не пошёл в массы. Послушаем умного человека.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #369 Ответы: #372

372. Сообщение от burjui (ok), 24-Июн-22, 22:35	+/–
Потому что на них, внезапно, сложно и долго писать. Или ты думал, что там просто компиляторы очень умные, сами угадывают твои намерения, и верификация даётся бесплатно? Чтобы верифицировать твой код, ты сначала должен опписать критерии верификации - то есть, "контракты" в терминологии SPARK. И тебе придётся каждую строчку кода обложить пачкой контрактов, далеко не всегда тривиальных, и тебе это очень быстро надоест, потому что успеешь постареть, пока напишешь хоть какой-то функционал. Для космических аппаратов и ядерных электростанций это приемлемо, а для менее критичного софта - нет. Никто не будет ждать 2 года, пока ты напишешь супернадёжный медиаплеер. И даже SPARK не защитит от логических ошибок, пока контракты пишет человек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #371 Ответы: #401

373. Сообщение от warlock66613 (ok), 24-Июн-22, 22:44	+/–
Про SEH я в курсе. Интересно именно про C++ и HaikuOS / BeOS. > Штатный RTTI есть в Qt. Ого. Пожалуй стоит сильнее прислушаться к хейтерам современного Qt. Возможно они не так уж неправы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #344 Ответы: #386

374. Сообщение от warlock66613 (ok), 24-Июн-22, 23:10	+1 +/–
> Обязательная инициализация означает необходимость тратить время процессора и память на > ненужную оптимизацию переменных. Для системного программирования, где важен каждый такт, > она неприемлема. И поэтому в Rust есть переменные типа `MaybeUninit`. (Для которых, разумеется, также обязательна инициализация, но она не тратит время процессора и память (если использовать для инициализации значение `MaybeUninit::uninit()`.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #364 Ответы: #388

375. Сообщение от Аноним (375), 24-Июн-22, 23:27	+/–
Как может данная прослойка обеспечить безопасность, если у нее 70% кода unsafe? Т.е фактически, будет вызываться из безопасного кода, небезопасные функции из прослойки. Да о чем можно говорить, когда этому подтверждение недописанный драйвер android от гугла. Если моя логика абсолютна не верна, то как тогда?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #369 Ответы: #376, #377

376. Сообщение от yet another anonymous (?), 24-Июн-22, 23:50	+/–
Там продвигаются более интернсные вещи, хотя на них обращают внимание сильно меньше. Это    - сборочная система    - легкий update компилятора    - пакетная система с автоподгрузкой из сетки by demand в процессе сборки Демпфировать это, в принципе, можно, но en masse это неустранимо (см. npm, pip, доустановка deb-пакетов на лету в CI, аналогичное подтягивание docker'ов, ...).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #375 Ответы: #402, #523

377. Сообщение от burjui (ok), 25-Июн-22, 00:03	+/–
Как же вы достали уже с этим, сил нет... Неужели самим непонятно, что любой потенциальный косяк работы с памятью будет локализован в этих блоках unsafe? Весь остальной код гаратированно ни при чём. А это значит, что аудит на предмет некорректных обращений к памяти (а это основной источник уязвимостей, особенно с получением root доступа) нужно проводить только для unsafe блоков. Никто и никогда не обещал полной безопасности обращений к памяти при наличии unsafe кода, однако локализация небезопасных операций в соответствующих блоках очень сильно сужает область поиска потенциальных и актуальных багов. Практически невозможно, даже тысячей глаз, прочитать миллион строк кода и найти там все переполнения буфера и т.п.. С 10к строк это сделать гораздо проще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #375 Ответы: #382, #404

381. Сообщение от Аноним (381), 25-Июн-22, 03:38	–1 +/–
> репозиторий пакетов, вменяемая система сборки Прямо перечислил априори не нужное > избавление программиста от работы головой Фиксанул, не благодари
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #328 Ответы: #387

382. Сообщение от Аноним (381), 25-Июн-22, 03:44	–1 +/–
> косяк работы с памятью Проблемы квалификации программиста, а не языка как такового. Хотя, глядя на то что творится в IT и какие макаки-гуманитарии туда идут, за будущее не страшно, т.к. выдумки о скайнете так и останутся выдумками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #377 Ответы: #383, #389

383. Сообщение от burjui (ok), 25-Июн-22, 05:19	+1 +/–
По твоей логике в мире нет ни одного квалифицированного программиста, потому ошибки совершают абсолютно все.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #382

384. Сообщение от n00by (ok), 25-Июн-22, 07:04	+/–
Указания уже даны https://www.kernel.org/doc/html/latest/process/submitting-pa... Одно из требований: Check your patches with the patch style checker prior to submission (scripts/checkpatch.pl). https://www.kernel.org/doc/html/latest/process/coding-style.... По сути, "указывающие" лишь ссылаются на официальную документацию. Другой момент, это приём пачтей. Их смотрят минимум двое. Сопровождающий драйвер и ответственный за подсистему. Эти люди далеко не вчерашние студенты и всю жизнь писали на Си. С возрастом растёт такая штука, как когнитивная ригидность. Стойкость убеждений, если по простому. Часть разработчиков ядра не могут принять Rust не потому что "синтаксис плохой", а потому что он непривычен. Эти люди будут вынуждены покинуть проект.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #365 Ответы: #392

385. Сообщение от n00by (ok), 25-Июн-22, 07:29	+1 +/–
> Обязательная инициализация означает необходимость тратить время процессора и память на > ненужную оптимизацию переменных. Если переменная в памяти, память "потрачена" независимо от инициализации. Инициализация гарантирует, что переменная окажется в кеше к моменту последующего чтения, т.е. в общем случае работать будет быстрее. > Для системного программирования, где важен каждый такт, > она неприемлема.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #364 Ответы: #440

386. Сообщение от n00by (ok), 25-Июн-22, 07:43	+/–
> Про SEH я в курсе. Интересно именно про C++ и HaikuOS / > BeOS. Что именно интересно про Си++? Когда дизайнили ядро NT, насколько понимаю, языка С++ не было. SEH точно так же хранит некоторую информацию времени исполнения о типе ошибки. Точно так же есть проблемы, не работает на высоких IRQL. И ещё объекты ядра обмениваются сообщениями. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #373 Ответы: #393

387. Сообщение от Аноним (358), 25-Июн-22, 10:22	+/–
>> избавление программиста от работы головой > Фиксанул, не благодари Как что-то плохое. Хотя страх всяких сишников можно понять, ведь повторяется история с станками жаккара.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #381 Ответы: #493

388. Сообщение от Аноним (278), 25-Июн-22, 10:24	+1 +/–
Какой ужасный синтаксис
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #374 Ответы: #398

389. Сообщение от Аноним (358), 25-Июн-22, 10:37	+1 +/–
> Проблемы квалификации программиста, а не языка как такового А вот и снова мантры про прямые руки. Только не сильно-то они помогают, раз то в одном, то в другом сишном поделии ошибки с памятью обнаруживаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #382

390. Сообщение от Аноним (278), 25-Июн-22, 10:59	+/–
Ваш комментарий нужно в рамочке повесить над формой отправки сообщения
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #368

391. Сообщение от Аноним (278), 25-Июн-22, 11:01	+1 +/–
burjui не написал что он хороший.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #370

392. Сообщение от Sw00p aka Jerom (?), 25-Июн-22, 12:01	+/–
>штука, как когнитивная ригидность. Стойкость убеждений, если по простому. нет, была бы болгарка в руках Микеланджело его бы скульптуры были бы щедевральнее чем тем же зубилом? Принял бы он болгарку, если всю жизнь учился мастерству работы с зубилом? А в чем разница он бы сразу сказал бы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #384 Ответы: #445

393. Сообщение от warlock66613 (ok), 25-Июн-22, 13:04	+/–
> Что именно интересно про Си++? Интересно, написаны HaikuOS/BeOS на C++ с эксепшенами или на C++ без эксепшенов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #386 Ответы: #394

394. Сообщение от n00by (ok), 25-Июн-22, 15:48	+/–
Уже не пойму, когда шутят, а когда нет. Можно ведь поискать. https://github.com/haiku/haiku/search?q=throw Вот например inline void* operator new(size_t size, ObjectCache* objectCache, uint32 flags) throw() {     return object_cache_alloc(objectCache, flags); } https://github.com/haiku/haiku/blob/8f16317a5b6db5c672f33181...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #393 Ответы: #397

395. Сообщение от Аноним (-), 25-Июн-22, 16:12	+/–
> Ну безопасное написание драйверов ламерами это объективная реальность, потому что никто > кроме них не будет писать драйвер для девайса который купили полтора > человека и сделать для них загончик где они бы бсодили только > свой драйвер нужно и полезно. Вообще-то бсодить ядро очень так себе идея. И Торвальдс очень популярно высказался что он про panic() при всяких нехватках памяти и проч думает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #507

396. Сообщение от Аноним (-), 25-Июн-22, 16:13	+/–
> Дяди из Linux Foundation решили окончательно убить Linux как Mozilla убивает Firefox. > Примечательно, что тоже переписыванием на Rust. Потом окончательно переведут всех на > какое-то несвободное ПО вроде Fuchsia с тивоизацией. Всех это кого? Хомячков на андроиде? У них и так линукс довольно паршивенький, с блоботой и троянами, сливащий телеметрию. А, и секурбут конечно. Кто сказал что линукс так не может?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

397. Сообщение от warlock66613 (ok), 25-Июн-22, 16:17	+/–
Из приведённого вами куска кода ответ на мой вопрос не получить никак. Врочем, действительно, если поискать (для ответа на мой вопрос искать надо конечно в первую очередь `dynamic_cast`, а во вторую `catch`, в то время как наличие/отсутствие `throw` совершенно иррелевантно), то похоже что используется именно то, что называется «C++ без эксепшенов».
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #394 Ответы: #399

398. Сообщение от warlock66613 (ok), 25-Июн-22, 16:53	+/–
> Какой ужасный синтаксис Именно синтаксис здесь плюсовый. И что в нюм ужасного? Двойное двоетчие? А `MaybeUninit`, `uninit` — это не синтаксис, это просто идентификаторы, имя типа и тмя метода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #388 Ответы: #510

399. Сообщение от n00by (ok), 25-Июн-22, 17:32	+/–
Я не вижу какого-либо конкретного вопроса в Ваших сообщениях. Возможно, потому что имею некторое представление, как работают диспетчер исключений и dynamic_cast. throw() это в моём понимании "с эксепшенами" (для kernel/slab/Slab.h сделано, как и должно быть). Их поддержку можно на уровне транслятора отключить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #397 Ответы: #403

400. Сообщение от Анлним (?), 25-Июн-22, 18:28	+/–
> Сами идите, пишите на обоих языках, а потом сравнивайте объём кода, трудозатраты и КПД своей работы. Ты правильные вопросы задал:   объем кода   трудозатраты   КПД молодец. Теперь в твою модель добавь следующие переменные:   надежность (авиация, еретические производства, оборонка - сбой, падение программы неприемлемо)   безопасность (требуется уровень не ниже A1 - математическое доказательство корректности, отсутствия ошибок и уязвимостей на уровне исходных текстов) И перещетай заново свои критерии оценки языка:   объем кода   трудозатраты   КПД И где теперь Rust с C по сравнению со SPARK? > А заодно подумайте, почему ни один из формально верифицируемых языков даже близко не пошёл в массы. Это смотря кто заказчик. Массовому заказчику надо:   быстро и дёшево а не   надежно, безопасно, верефицируемо. По этому пишут на Python. За SPARK стоит самый крутой заказчик, которому необхожим язык дающий сразу гарантии:   надежности   безопасности   верефицируемости всем написанным на нем програмам. Трудозатраты на мат верификацию исходного кода на отсутствие уязвимостей и збоев работы программы на SPARK равны 0.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #369 Ответы: #405

401. Сообщение от Анлним (?), 25-Июн-22, 18:53	+/–
Ответ: массового заказчика нет. SPARK уже занял свою нишу. Заказчик должен платить за надежность, безопасность и верифицируемость ПО. Есть надежная, безопасная и верифицируемая ОС: https://muen.sk Кажется стандарт в гражданской авиации. Даже в РФ бортовое ПО на ADA-SPARK пишут? Кроме атомной энергетики, военные SPARK любят в своих АСУ. Сегодня просто уникальный исторический момент. Прошло около 45 лет со дня заказа разработки этого языка программирования, сменилось несколько поколений программистов и на конец в GNU смогли написать свободный компилятор RUST. Вхождение в мир надежного, безопасного и верифицируемость ПО стоит не десятки миллиардов долларов, а 0.0$ Я категорически против зоопарка. Убежден, что Linux должен писался на C и ASM, как это было изначально. А добавление любого другого языка в ядро Linux только запустить его, затруднит поддержку и использование. А конкретно Rust вместо безопасности добавит новые классы уязвимостей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #372 Ответы: #407

402. Сообщение от Анлним (?), 25-Июн-22, 18:56	+/–
> пакетная система с автоподгрузкой из сетки by demand в процессе сборки Это смерть безопасности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #376

403. Сообщение от warlock66613 (ok), 25-Июн-22, 19:09	+/–
«C++ с эксепшенами» — это стандартный C++ с RTTI. «C++ без эксепшенов» получается если компилировать с выключенным RTTI. Подход к написанию кода настолько сильно вынужденно меняется в последнем случае, что это практически другой язык. Наличие `throw` в коде (особенно в плане указания что метод не кидает эксепшенов) никак не мешает иметь выключенный RTTI. Другое дело — `dynamic_cast`. Ну и `catch` тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #399 Ответы: #417

404. Сообщение от Анлним (?), 25-Июн-22, 19:19	+/–
> Неужели самим непонятно, что любой потенциальный косяк работы с памятью будет локализован в этих блоках unsafe Тебя обманули и ты вводишь в заблуждение других. В ядро Linux, уже очень давно, лет 20 как, можно компилятором gcc собрать безопасно:   гарантии безопасной работы с памятью получить МОЖНО!!!   гарантии надежности НЕТ.   автоматической математической верификации корректности на уровне исходныых текстов НЕТ. Гарантии безопасности работы ядра Linux с памятью: config_pax_kernexec config_grkernsec_randstruct Безопасность работы с памятью в ядрах некоторых UNIX, Linux, NetBSD, частично OpenBSD уже есть! И все на C. Она достигнута логически следуя правилу: все, что исполняется не должно изменятся, а что изменяется не должно исполнятся. Используя инструкции процессоров (постранично) или даже полностью софтварно (посегментно). Эксплуатация переполнения буфера невозможна! Цена использования C: невозможность дать гарантии надежности при дачи гарантий безопасности работы с памятью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #377 Ответы: #406, #408

405. Сообщение от burjui (ok), 25-Июн-22, 19:39	+/–
Как я и писал выше, опеннетовский эксперт не умеет читать [1] и мыслить критически [2]. А в вашем случае ещё и минимально грамотно писать [3] - это при наличии спеллчекера в браузере. Зато всё на свете знает. И правильно - зачем думать, если можно просто знать? [1] Выше я писал: "И тебе придётся каждую строчку кода обложить пачкой контрактов, далеко не всегда тривиальных, и тебе это очень быстро надоест, потому что успеешь постареть, пока напишешь хоть какой-то функционал. Для космических аппаратов и ядерных электростанций это приемлемо, а для менее критичного софта - нет. Никто не будет ждать 2 года, пока ты напишешь супернадёжный медиаплеер." [2] "Трудозатраты на мат верификацию исходного кода на отсутствие уязвимостей и збоев работы программы на SPARK равны 0." Ага, а про трудозатраты на написание нескольких контрактов на одну строчку кода мы, конечно же, забудем. Видимо, компилятор сам догадается, что ты имел ввиду и напишет контракты за тебя. Только непонятно тогда, зачем нужен программист, если компилятор такой умный. [3] Не люблю докапываться до орфографии, но это же просто ужас какой-то - "перещетай", "збоев", "верефицируемо", "програмам".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #400 Ответы: #409

406. Сообщение от Анлним (?), 25-Июн-22, 19:44	+/–
Еще одна большая сакральная тайна которую пропагандисты Rust скрывают, чтобы вас всех обмануть: Ядра некоторых UNIX, Linux, NetBSD, Apple OS X, частично OpenBSD и MS Windows дают гарантии безопасной работы с памятью для всего прекладного ПО! Даже, для того, что написан на дырявом C и текущем Rust: Для Linux включите опции ядра: config_pax_noexec config_pax_pageexec    (надеюсь ваш проц инструкцию NX держит) config_pax_mprotect И получаем гарантии безопасности и корректности работы с памятью сразу всего прикладного ПО, на любом языке программирования, собранного любым компилятором!!! Цена: нет гарантий надежности. В авиации, атомной энергетике, ... необходима надежность. Ни Rust ни C надежности и верификации вам не дадут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #404

407. Сообщение от burjui (ok), 25-Июн-22, 20:03	+/–
>Вхождение в мир надежного, безопасного и верифицируемость ПО стоит не десятки миллиардов долларов, а 0.0$ Из крайности - в крайность. Типичный опеннетный эксперт. >0.0$ Это если не писать контракты в том же SPARK. Правда, тогда и код не скомпилируется. А контрактов придётся писать больше, чем кода. Так что совсем не 0$. > А конкретно Rust вместо безопасности добавит новые классы уязвимостей. На каком основании вы сделали такой вывод?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #401 Ответы: #499

408. Сообщение от burjui (ok), 25-Июн-22, 20:14	+/–
>> Неужели самим непонятно, что любой потенциальный косяк работы с памятью будет локализован в этих блоках unsafe >Тебя обманули и ты вводишь в заблуждение других. Аргументы будут или пука в лужу, по вашему мнению, достаточно? >все, что исполняется не должно изменятся, а что изменяется не должно исполнятся. Такой способ безопасной работы с памятью не бесплатен, а имеет накладные расходы во время выполнения кода, в отличие от статической верификации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #404 Ответы: #410, #411

409. Сообщение от Анлним (?), 25-Июн-22, 20:17	+/–
Не хами. Писал грамотно, а вражеский спелчекер поменял слова. Вот Ыксперту по безопасной работе с памятью еще: https://www.opennet.ru/openforum/vsluhforumID3/127824.html#404 https://www.opennet.ru/openforum/vsluhforumID3/127824.html#406 Могу сравнить трудозатраты по разработке ПО на Python и C как 1 к 10. Соответственно считай КПД и цену ПО как 1 к 10. Смотри код ядра ОС на СОВРЕМЕННОМ SPARK-2014: https://git.codelabs.ch/?p=muen.git;a=tree;f=kernel/src Он легко читаем, понятен, удобен для поддержки. > тебе придётся каждую строчку кода обложить пачкой контрактов, далеко не всегда тривиальных, и тебе это очень быстро надоест, потому что успеешь постареть, пока напишешь хоть какой-то функционал > Ага, а про трудозатраты на написание нескольких контрактов на одну строчку кода мы, конечно же, забудем. Тебя обманули и ты вводишь в заблуждение других. Смотри спецификации языка SPARK-2014, лучше SPARK-2021. Им таки удалось написать АВТОМАТИЧЕСКИЙ ВЕРИФИКАТОР почти всего синтаксиса языка програмирования "ADA". Сегодня GNU уже почти всевозможные вериыикаторы написала. В общем писать верифйикаторы не придется. Смотри пример кода ядра OS на SPARK-2014: https://git.codelabs.ch/?p=muen.git;a=blob;f=kernel/src/sk-k... https://git.codelabs.ch/?p=muen.git;a=blob;f=kernel/src/sk-k...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #405 Ответы: #412

410. Сообщение от Анлним (?), 25-Июн-22, 20:41	+/–
> Аргументы будут или пука в лужу, по вашему мнению, достаточно? В луже с растом сейчас сидишь ты. Аргументируют: config_pax_noexec config_pax_pageexec    (надеюсь ваш проц инструкцию NX держит) config_pax_mprotect config_pax_kernexec 1. Дает гарантии корректной и безопасной работы с памятью ядра Linux и всего прикладного ПО не зависимо от язака написания и используемого компилятора. 2. Накладные расходы при постраничной проверке памяти равны 0 для следующих архитектур процессоров: alpha, avr32, ia64, parisc, sparc, sparc64, x86_64, i386 и старше с поддержкой инструкции NX. А для ppc, ppc64 накладные расходы мизерны. Прочти в учебнике раздел о "Проактивной защите". И всем обратить внимание на РЕАЛИЗАЦИЮ защиты пямяти в разных ОС. Правильная защита памяти: Linux+PAX, NetBSD, Apple OS X, ... Не правильная защита памяти: OpenBSD, MS Windows, ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #408 Ответы: #413

411. Сообщение от Анлним (?), 25-Июн-22, 21:03	+/–
Узри саму убогость и ущербность идеи Rust иметь частичную (ибо есть unsave) проверку во время сборки только для одной программы написанные на Rust, по сравнению с глобальной гарантией корректности и безопасности работы с памятью всех программ без любых исключений (включая даже блоки unsave) от ядра ОС и процессора. И без любых накладных расходов для x86_64. Вас обманули и повели по неверному пути. Вы пытаетесь, частично, защитить программу, когда уже как 30 лет всем доступна технология защиты памяти всразу всех программ без исключений! Незыблимый принцип безопасности: ГАРАНТИИ защиты и корректности работы с памятью дает ядро ОС с процессором. А не аккуратность програмиста, продвинутость компилятора (хотя это тоже очень важно) или какой-то очередной ЯП. Да, у технологии Проактивной безопасности есть цена - отсутствие гарантий надежности работы программы. И на сегодня единственным рабочим вариантом дающим математически доказанные гарантии надежности и безопасности на уровне исходных текстов есть - SPARK.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #408 Ответы: #414, #421

412. Сообщение от burjui (ok), 25-Июн-22, 21:51	+/–
Интересные ссылки ты приводишь. А я вот заглянул в другую часть сорцов, и что же я вижу? https://git.codelabs.ch/?p=muen.git;a=blob;f=common/src/sk-c...   27    procedure Cli   28    with   29       Global  => (In_Out => X86_64.State),   30       Depends => (X86_64.State =>+ null),   31       Inline_Always; https://git.codelabs.ch/?p=muen.git;a=blob;f=common/src/sk-c...   37    procedure Cli   38    with   39       SPARK_Mode => Off   40    is   41    begin   42       System.Machine_Code.Asm   43         (Template => "cli",   44          Volatile => True);   45    end Cli; Итого 2 контракта на одну инструкцию "cli" и отключение режима SPARK. То есть, SPARK знать ничего не знает про инструкцию "cli" и никаких гарантий давать не может в принципе, поэтому компилируем функцию как обычную ADA. Ловко выкрутились 😁 Так это что получается, аналог unsafe? Вот тебе и хвалёная верификация. "Мамой клянусь, эта функция только X86_64.State меняет!". Ну что сказать, сильные гарантии. Прямо как в другом языке, где тоже можно из безопасного кода вызывать опасный. Но этот другой язык - плохой, потому что называется Rust, а вот SPARK намного лучше, хотя суть у него та же: разработчик в маленькой функции пообещал не хулиганить, а компилятор пожал плечами и разрешил её вызывать, полагаясь на честное слово.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #409 Ответы: #418, #419, #420, #475

413. Сообщение от burjui (ok), 25-Июн-22, 21:59	+/–
>Накладные расходы при постраничной проверке памяти равны 0 для следующих архитектур процессоров: alpha, avr32, ia64, parisc, sparc, sparc64, x86_64, i386 и старше с поддержкой инструкции NX. Здесь был неправ, признаю. Тем не менее, от некорректного обращения к памяти эта технология не защищает. Она защищает от последствий некорректного обращения к памяти - то есть, вместо того, чтобы дать прочитать мусор или переписать адрес возврата, сгенерирует аппаратное исключение, а ОС, скорее всего, грохнет процесс. То есть, код по-прежнему может попытаться прочитать мусор или переполнить буфер, после чего упасть. При статической же проверке некорректных обращений к памяти вовсе не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #410 Ответы: #423

414. Сообщение от burjui (ok), 25-Июн-22, 22:06	+/–
Прочитай мой комментарий ниже со ссылками на код Muen. Надеюсь, я там наглядно показал, чего стоят "гарантии надёжности и безопасности" SPARK, которые по принципу идентичны гарантиям Rust. Даже на главной странице написано: SPARK is a software development technology specifically designed for engineering high-reliability applications. It consists of a programming language, a verification toolset and a design method which, taken together, ensure that ultra-low defect software can be deployed in application domains where high-reliability must be assured, for example where safety and security are key requirements. > ultra-low defect software Внимательно прочитал? Не defectless, а ultra-low defect. Не дают они "математическиие гарантии надёжности и безопасности", потому что это невозможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #411 Ответы: #422

415. Сообщение от Ананимус (?), 25-Июн-22, 22:47	+2 +/–
О, пруфов будет предостаточно. С какой подсистемой ты лучше знаком?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #362

416. Сообщение от Ананимус (?), 25-Июн-22, 22:49	+/–
> Такие виды ошибки лекго отлавливаются. Супер, отлови пожалуйста. А то её уже полтора года отловить не могут. Стектрейс скинуть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #354

417. Сообщение от n00by (ok), 26-Июн-22, 09:42	+/–
Напишу только по поводу MSVC (у GCC исходники открыты и всё должно быть документировано без меня). Если отключить RTTI, диспетчер исключений никуда не денется и будет выполнять свои задачи, вызывать деструкторы, искать и вызывать обработчик (подходящий окажется с ...). Его следует отключать отдельно, если поддержка исключений не нужна. А подход к написанию кода меняется уже от того, что код в ядре. В ряде случаев бросать исключения никак нельзя, будь то C++ или инструкция int3. И зачем в ядре dynamic_cast<>, где его можно применить, я пока не пойму.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #403

418. Сообщение от Аноним (423), 26-Июн-22, 10:19	+/–
1. Пока не весь код Mumen написан на SOARK-2014 и ASM, есть немного кода на неверифицируемой ADA+2012: https://git.codelabs.ch/?p=muen.git;a=blob;f=README 2. Ядро OS это очень низкоуровневое ПО работающие напрямую с железом, асемблерными инструкциями процессора. На данном этапе эволюции процессоров и языков программирования пока необходимо использовать асеблерный код для написание некоторых частей OS. Да, поддержку CPU без асеблера не напишешь. Асемблерный код неверифицируется SPARK, весь Асемблерный код необходимо проверять руками, но его немного: https://git.codelabs.ch/?p=muen.git;a=tree;f=kernel/src/asm В отношении асемблерного кода нет гарантий безопасности и надежности. 3. Использование неверифицируемой ADA, влияет только на математические доказательства отсутствия ошибок и корректности работы с памятью на уровне исходных текстов. По надежности и безопасности ПО на ADA на порядок выше чем C и Rust. 4. Прикладное ПО, это не ядро ОС, можно писать на чистом SPARK без ASM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #412

419. Сообщение от Аноним (423), 26-Июн-22, 10:33	+/–
> поэтому компилируем функцию как обычную ADA. Язык SPARK это верифицируемое подмножество языка программирования ADA. SPARK своего компилятора не имеет, для компиляции программ на SPARK используется обычный компилятор ADA. SPARK имеет автоматический верификации исходных текстов кода, дающий гарантии отсутствия ошибок во время работы программы, включая ошибки связанные с безопасной работой с памятью на уровне исходных текстов програм. В автоматический верификации добавляются новые верификаторы добавляя синтаксис ADA в верифицируемое подмножество SPARK.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #412

420. Сообщение от n00by (ok), 26-Июн-22, 10:34	+/–
Clear Interrupt Flag (cli) Operation 0 → IF Description Clears the interrupt flag if the current privilege level is at least as privileged as IOPL; affects no other flags. External interrupts disabled at the end of the cli instruction or from that point on until the interrupt flag is set
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #412 Ответы: #424

421. Сообщение от Аноним (358), 26-Июн-22, 10:36	+/–
> ГАРАНТИИ защиты и корректности работы с памятью дает ядро ОС с процессором. А не аккуратность програмиста Осторожно, ты оскорбляешь религиозные чувства секты свидетелей прямых рук.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #411 Ответы: #497

422. Сообщение от Аноним (423), 26-Июн-22, 10:49	+/–
> Внимательно прочитал? Не defectless, а ultra-low defect. Не дают они "математическиие гарантии надёжности и безопасности", потому что это невозможно. Имеется в ввиду ОБЩЕЕ решение "ultra-low defect". SPARK это верификатор подмножества языка программирования ADA, дающий гарантии отсутствия ошибок и корректности работы с памятью на уровне исходных текстов. Проверяются ТОЛЬКО исходные тексты, а не запускаемые бинари. Есть еще компилятор языка програмирования ADA, который тоже разрабатывался как высоконадежный и очень безопасный. Незабываем о CPU с его асемблером в котором тоже иногда просачиваются ошибки. Общие решение:   исходный код на SPARK + компилятор языка программирования ADA + исполняющий бинарь процессор -- 100% гарантий не имеет, но дает достаточные гарантии для использования в бортовых системах авиации, на критических производствах, военных АСУ, а также в обеспечении государственной информационной безопасности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #414 Ответы: #427

423. Сообщение от Аноним (423), 26-Июн-22, 11:13	+/–
> Тем не менее, от некорректного обращения к памяти эта технология не защищает. Она защищает от последствий некорректного обращения к памяти - то есть, вместо того, чтобы дать прочитать мусор или переписать адрес возврата, сгенерирует аппаратное исключение, а ОС, скорее всего, грохнет процесс. То есть, код по-прежнему может попытаться прочитать мусор или переполнить буфер, после чего упасть. Там есть разные варианты в разных ситуациях: 1. Не убивать процессы, а только логировать ошибки. 2. Убивать процессы и логировать ошибки. 3. Убить ВСЕ процесы пользователя, запретить создание новых и логировать ошибки. 4. При угрозе изменения логов с ошибками, убивать все процесы и само ядро ОС, для сохранения лога. > При статической же проверке некорректных обращений к памяти вовсе не будет. Аккуратный Сишник, имея неизменненный лог ошибки проги, быстро подправит косяк при обращении к памяти и выпустит патч с "закрытием очередной сишной дырени". Все патч наложат и в этом месте "плазма" уже падать не будет. Заметь, технология практичной защиты, обеспечила гарантии безопасности ОС, не допустила эксплуатации некорректного обращения к памяти, и способствовала передачи в логах необходимой информации программисту, для локализации и устранения ошибки в программе. А вот надежности работы программы не дает!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #413 Ответы: #453

424. Сообщение от burjui (ok), 26-Июн-22, 12:05	+/–
Я тоже умею копипастить и знаю, что делает инструкция cli. Что сказать-то хотел этим?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #420 Ответы: #450

425. Сообщение от Аноним (-), 26-Июн-22, 12:24	+/–
> ну так лет пять убивать будут эт точно, а там и фуксия > подоспеет. то же самое, что с файрфокс произошло - как по > нотам с теми же действующими лицами А фуксию и убивать не надо - там квинтэссенция корпоративного булщита сразу по максимуму забабахана. Реализация FAT на игогошечки. Веьмакаки пыжатся в системное программирование, какая милота.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #305

426. Сообщение от Аноним (-), 26-Июн-22, 12:26	+/–
> Форкни системду например А в чем проблема? У меня свой реп с парой кастомных патчиков. Апстриму оно не сильно надо т.к. на типа-старую-версию, потому что сильно менять то что уже работало было впадлу а починить кой-что хотелось. Назыввать это форком слишом громко, но так можно было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135

427. Сообщение от burjui (ok), 26-Июн-22, 12:28	+1 +/–
>100% гарантий не имеет, Вот именно. >Но дает достаточные гарантии для использования в бортовых системах авиации, на критических производствах, военных АСУ, а также в обеспечении государственной информационной безопасности. Согласен, с этим я не спорю. Впервые за долгое время дискуссия на опеннете привела к чему-то кроме уничтожения нейронов головного мозга: кто-то признал, что 100% гарантий не даст ни один ЯП без серьёзных ограничений множества возможных программ, а я узнал о новом для себя ЯП, который имеет смысл изучить хотя бы для кругозора. Это повод принести в жертву компьютерным богам содержимое /tmp.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #422 Ответы: #476

429. Сообщение от Аноним (-), 26-Июн-22, 12:29	+/–
> Я _сделал_ когда-то то, чем ныне заняты растоманы. Это, например, что? Прислал патчи с поддержкой другого яп в майнлайн? Да ну?! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #255 Ответы: #443

430. Сообщение от Аноним (-), 26-Июн-22, 12:31	+/–
> Думаю проблема в этом <()>. Рыба камбала :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

431. Сообщение от Аноним (-), 26-Июн-22, 12:32	+/–
> use std::process::ExitCode; > fn main() -> ExitCode { >     if !check_foo() { >         return ExitCode::from(42); >     } >     ExitCode::SUCCESS > } > https://doc.rust-lang.org/stable/std/process/struct.ExitCode... Агаблин, это вместо сишного return 42. Стало проще, красивее, удобнее... </sarcasm>
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #459

432. Сообщение от Аноним (-), 26-Июн-22, 12:35	+/–
> На самом деле, логичным должен быть вопрос не "когда С++", а "когда > Fortran, ADA, objective C". Когда ты покажешь как на всем этом великолепии системщину делать и чтобы это не было еще более жутким чем все остальное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

433. Сообщение от Аноним (-), 26-Июн-22, 12:36	+/–
> Здорово. А я уже лет 6 не запускал gdb за ненадобностью, потому > что перешёл с C++ на Rust. Круто, оказывается, хруст как-то делает программы без багов. Нюню, пылесосы иди продавай, Кирби позавидует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249 Ответы: #456

434. Сообщение от Анонми (?), 26-Июн-22, 12:38	+/–
> Кстати интересно как там инициатива по рефакторингу заголовочных файлов продвигается. > Обещали неслабое ускорение сборки. Некоторые части уже вкомитили. Но не все, оно большое и очень интрузивное чтобы его оптом и с лопаты везде впихать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

435. Сообщение от Аноним (-), 26-Июн-22, 12:40	+/–
> Он же компилируемый - так что есть нюансы с eval. Через пару > лет можно будет оформить в виде llvm.ko. Чочо, модуль на 60 метров, да еще на плюсах? Ух блин нет, за это Торвальдс таки все же прилюдно люстрирует, имхо :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #260 Ответы: #447

436. Сообщение от Аноним (-), 26-Июн-22, 12:40	+2 +/–
> А в расте - больше, потому что динамическая линковка с libc. Господа, а вас не смущает что кернел с libc не линкуется, ни там ни там? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #259

437. Сообщение от Аноним (-), 26-Июн-22, 12:42	+/–
> Ты модуль ядра решил компилировать что ли, раз тебе бисект потребовался? Тогда > бы ты знал что занимаешься его разработкой и не говорил что > бинарно бисектить собрался. Короче мимо парень А в чем прикол стандартное стоковое ядро компилить? Bisect это как раз вполне валидная причина компилежки и время оного очень даже интересует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226

438. Сообщение от Аноним (-), 26-Июн-22, 12:45	+/–
> За 30 лет могли бы лучше Pascal впилить в ядро. > На нём явно поприятнее писать, и дрова в том числе. Да ну чего в нем приятного, особенно в системщине? Абсолютно все потуги делать на этом системщину выглядели "через ж...у в левый глаз". Чаще всего паскакалистов это задалбывало и они асм вставкой все системное делали, но вот так оно совершенно точно не вперлось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

439. Сообщение от Аноним (-), 26-Июн-22, 12:46	+/–
Это ж линуксоиды. У них даже HDCP какой - опция. Хочешь жрать DRM'о, включаешь. Не хочешь - отруби и собери кернел как тебе больше нравится. Этим линуксоиды и хороши.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

440. Сообщение от Аноним (-), 26-Июн-22, 12:49	+/–
> Если переменная в памяти, память "потрачена" независимо от инициализации. А вот это - совсем не факт. Оптимизатор может все пох@рить в ноль если видит что side effects от этого ровно ноль. И кода не будет вообще. И данных тоже. С железным аргументом "а если не видно разницы, зачем генерить больше?" > Инициализация гарантирует, что переменная окажется в кеше к моменту последующего чтения, > т.е. в общем случае работать будет быстрее. С чего бы это вдруг такие гарантии вот так безаппеляционно? >> Для системного программирования, где важен каждый такт, она неприемлема. С другой стороны факапнуться с uninitialized variable в нем тоже так себе радость. Особенно когда все работает но раз в месяц почему-то палка все же стреляет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #385 Ответы: #457

441. Сообщение от Аноним (-), 26-Июн-22, 12:51	+/–
> На Бедоне же. Вот как разрослась-то! А что, архитектура улиц и транспорта - как будто питонист макет делал. Но это примерно как с питонным битторентом: да, истошный кал, но тогда по другому и не умели же!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

442. Сообщение от Аноним (-), 26-Июн-22, 12:58	+/–
> В системном программровании нужна только процедурщина. А ты уверен что даже просто ioctl какой попадает под именно такое определение? :) А еще - в сях можно функции переназначать на лету, передавать как параметры и проч. Указателями на функцию, прикинь?! Это позволяет делать довольно забавные вещи. Ну там например дефолтный хэндлер события, который однако юзер может перекрыть своим если оно ему надо. И много чего еще. Типа вгрузки функций на лету из .so допустим. >>Где передача функций, как объектов, каррирование, композиция функций >>и прочая ненизкая математика? > А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном > программировании не нужна. Они половину этой порнухи так то сами умеют делать прямо из сей каких и проч.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #291

443. Сообщение от n00by (ok), 26-Июн-22, 12:58	+/–
>> Я _сделал_ когда-то то, чем ныне заняты растоманы. > Это, например, что? Прислал патчи с поддержкой другого яп в майнлайн? Да > ну?! :) Вот в этом-то вся и соль. Зачем они хотят в майнлайн? Якобы, что бы писать драйвера на Rust. Когда мне понадобился Си++ в ядре Виндовс, я не слал в Микрософт письма с вопросами по компилятору, а просто сел и начал писать, дальше люди помогли. При этом "сишники" никак не мешали, поскольку не было походов со своим уставом в чужой монастырь. В итоге оно заработало (при этом драйвер работал гораздо раньше, чем появилась поддержка исключений, которая в ядре нужна не очень, но помогала не писать тесты, а брать готовые). У растоманов уже есть какой-то драйвер, или только вот этот процесс внедрения?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #429 Ответы: #463

444. Сообщение от Аноним (-), 26-Июн-22, 13:00	+/–
> в реальном железе имеем const volatile. =) Это что еще за порнография? Типа регистр RO для софта, но который может со своей стороны менять железо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #299 Ответы: #455

445. Сообщение от Аноним (-), 26-Июн-22, 13:02	+/–
Черт его знает, но если болгарка будет маленькой и CNCшной, я могу попробовать забахать что-то прикольное. И в отличие от Микеланджело не обломлюсь повторить на бис 50 раз. Или 50 000 000 раз. Иногда это по своему прикольно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #392 Ответы: #454

446. Сообщение от Аноним (-), 26-Июн-22, 13:11	+/–
> у небезызвестного mc от того же FAR хорошо если треть функционфала > есть (а если FAR обвесить плагинами, то на mc без желания > обнять и плакать вообще смотреть не получится). Вообще, FAR и под линукс нынче есть... довольно своеобразный, но все же. А так - простите, но если в линухе мой проект втрое быстрее компилится, может и черт с ним с фаром, при таком раскладе и миднайт сойдет. А плагины ставить... тоже мне миранда им очередная. Тем более что миднайт я могу даже на вон том роутере-мыльнице запустить, по ssh. Попробуй так с фарой, особенно в винде. В этом месте мы и понимаем прелесть *никсной консоли: универсальный и очень нетребовательный тул. Лезущий по сети с минимальными требованиями, по неспешным сериальным шнуркам, а по сути всему что отдаленно напоминает коммуникационный канал, даже неторопливый и базовый. А траблшутинг какой-нибудь винды которая не взлетает это вообще например очень отдельный вид жэсти. И в лине - только подумай - миднайт запустится в лысой консоли в single user mode и поможет по ФС при отскребании системы от асфальта навигировать. А в винде ... ну фар ты явно при проблемах такого уровня уже не запустишь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #367

447. Сообщение от n00by (ok), 26-Июн-22, 13:12	+/–
>> Он же компилируемый - так что есть нюансы с eval. Через пару >> лет можно будет оформить в виде llvm.ko. > Чочо, модуль на 60 метров, да еще на плюсах? Ух блин нет, > за это Торвальдс таки все же прилюдно люстрирует, имхо :) Так это будет потом. Когда привыкнут, что Rust уже и так есть, выйдет версия 2.0. Окно Овертона же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #435 Ответы: #489

448. Сообщение от Аноним (-), 26-Июн-22, 13:13	+/–
> сказки про то, как они без ошибок пишут на C чуть > ли не для космических аппаратов. Невоспитанная школота, начитавшаяся умных книжек, но > без критического мышления, которая возомнила себя экспертами. И тем не менее полно софта, в том числе и для космоса, писаного на си. А на эмбедовке без MMU хруст так то даже от элементарного переполнения стэка не защищает, внезапно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #368

449. Сообщение от Аноним (-), 26-Июн-22, 13:15	+/–
> Почему не добавить GC в ядро? Да их там есть даже, несколько разных. Только вот в игого он вообще везде и хрен от него отделаешься. Это ведет к патологическим случаям когда под нагрузкой он начинает делать черт знает что. О чем фуксики из соседней новости и узнали, чего-то полюбив хруст и чуть не плюсы. А, самое стебное? Хруст почему-то у них можно в системщине но для приложух не заявлено. Логика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186

450. Сообщение от n00by (ok), 26-Июн-22, 13:16	+/–
> Я тоже умею копипастить и знаю, что делает инструкция cli. Я это не заметил в "Мамой клянусь, эта функция только X86_64.State меняет!".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #424 Ответы: #458

451. Сообщение от Аноним (-), 26-Июн-22, 13:16	+/–
> Ты думаешь, тебе будут делать безопасные языки, приносить прямо в руки, пиарить > на весь интернет, только возьми? Как это должно работать, по-твоему? Zig и Hare ... примерно как-то так и образовались. А чего в этом такого?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178

452. Сообщение от Аноним (-), 26-Июн-22, 13:17	+/–
> И? Какая версия rust? Ночнушка последняя поди, как обычно. В релизных видите ли много тупняков для того чтобы кернел ими билдовать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

453. Сообщение от burjui (ok), 26-Июн-22, 13:17	+/–
> А вот надежности работы программы не дает! И правильно, кому она нужна? Главное - уязвимостей нет, а то что прога падает - так это проблемы пользователя, поэтому будем фанатично упираться и продолжать писать на C. Лучше пожертвуем пользователем, но на Rust принципиально писать не будем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #423 Ответы: #477

454. Сообщение от Sw00p aka Jerom (?), 26-Июн-22, 13:20	+/–
> и CNCшной вот тут надо задуматься, ибо ЧПУшку надо программировать (пошагово) и получается, что мы придерживаемся строгих правил движения, это как черчение. Но ведь мы не "ценим" черчение так как "ценим" изобразительное искусство (графику к примеру, без красок), вопрос - почему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #445 Ответы: #472

455. Сообщение от n00by (ok), 26-Июн-22, 13:25	+/–
>> в реальном железе имеем const volatile. =) > Это что еще за порнография? Типа регистр RO для софта, но который > может со своей стороны менять железо? Это когда регистр железно выполнен как RO, софт может туда и писать, но ничего не изменит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #444 Ответы: #470

456. Сообщение от burjui (ok), 26-Июн-22, 13:26	+1 +/–
>Круто, оказывается, хруст как-то делает программы без багов. Это я сказал или ты придумал? Вопрос риторический. Rust "делает программы" без некорректных обращений к памяти. А для поиска логических ошибок я gdb практически не использую, потому что гораздо удобнее вывести структуры данных в нужном формате через println!(), нежели ковыряться в сырых данных в gdb. Это тебе, Онаниму, нужно идти продавать пылесосы, потому что твоим навыки демагогии в программировании не только бесполезны, но ещё и вредны. В этой профессии и без тебя дураков хватает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #433 Ответы: #468

457. Сообщение от n00by (ok), 26-Июн-22, 13:37	+/–
>> Если переменная в памяти, память "потрачена" независимо от инициализации. > А вот это - совсем не факт. Оптимизатор может все пох@рить в > ноль если видит что side effects от этого ровно ноль. И > кода не будет вообще. И данных тоже. С железным аргументом "а > если не видно разницы, зачем генерить больше?" Так я описал худший случай, поскольку отвечал на: "Обязательная инициализация означает необходимость тратить время процессора и память на ненужную оптимизацию переменных". >> Инициализация гарантирует, что переменная окажется в кеше к моменту последующего чтения, >> т.е. в общем случае работать будет быстрее. > С чего бы это вдруг такие гарантии вот так безаппеляционно? Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет прочитана), а потом кеш скидывается в ОЗУ. А если нет записи, тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе придётся ждать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #440 Ответы: #520

458. Сообщение от burjui (ok), 26-Июн-22, 13:40	+/–
Потому что у тебя опилки в голове. Читаем https://sites.radford.edu/~nokie/classes/320/std_lib_html/sy...: procedure Asm (   Template : String;   Outputs  : Asm_Output_Operand_List;   Inputs   : Asm_Input_Operand_List;   Clobber  : String  := "";   Volatile : Boolean := False); procedure Asm (   Template : String;   Outputs  : Asm_Output_Operand := No_Output_Operands;   Inputs   : Asm_Input_Operand_List;   Clobber  : String  := "";   Volatile : Boolean := False); procedure Asm (   Template : String;   Outputs  : Asm_Output_Operand_List;   Inputs   : Asm_Input_Operand := No_Input_Operands;   Clobber  : String  := "";   Volatile : Boolean := False); procedure Asm (   Template : String;   Outputs  : Asm_Output_Operand := No_Output_Operands;   Inputs   : Asm_Input_Operand  := No_Input_Operands;   Clobber  : String  := "";   Volatile : Boolean := False); function Asm (   Template : String;   Outputs  : Asm_Output_Operand_List;   Inputs   : Asm_Input_Operand_List;   Clobber  : String  := "";   Volatile : Boolean := False)   return     Asm_Insn; function Asm (   Template : String;   Outputs  : Asm_Output_Operand := No_Output_Operands;   Inputs   : Asm_Input_Operand_List;   Clobber  : String  := "";   Volatile : Boolean := False)   return     Asm_Insn; function Asm (   Template : String;   Outputs  : Asm_Output_Operand_List;   Inputs   : Asm_Input_Operand := No_Input_Operands;   Clobber  : String  := "";   Volatile : Boolean := False)   return     Asm_Insn; function Asm (   Template : String;   Outputs  : Asm_Output_Operand := No_Output_Operands;   Inputs   : Asm_Input_Operand  := No_Input_Operands;   Clobber  : String  := "";   Volatile : Boolean := False)   return     Asm_Insn; Ты здесь видишь какие-нибудь контракты? А здесь? procedure Cli   38    with   39       SPARK_Mode => Off   40    is   41    begin   42       System.Machine_Code.Asm   43         (Template => "cli",   44          Volatile => True);   45    end Cli; А здесь они откуда-то взялись, хотя функция System.Machine_Code.Asm контрактов не имеет:   27    procedure Cli   28    with   29       Global  => (In_Out => X86_64.State),   30       Depends => (X86_64.State =>+ null),   31       Inline_Always; Ну, и откуда они взялись? А их приписал разработчик. Но мог написать другие, некорректные, или вовсе не писать. Получается "мамой клянусь". А ведь верификация на контрактах держится, без них тебе компилятор ничего за пределами Ada 2012 не гарантирует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #450 Ответы: #460, #474

459. Сообщение от warlock66613 (ok), 26-Июн-22, 13:47	+/–
> Агаблин, это вместо сишного return 42. Стало проще, красивее, удобнее... </sarcasm> Точно красивее. И удобнее, если брать не настолько синтетический пример. И например в C вы можете сделать `return -42;`. А POSIX говорит, что код должен быть в пределах `0 ..= 255`. И вот попробуй догадайся, 1) к чему такой код приведёт, 2) зачем язык позволяет писать это.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #431 Ответы: #466

460. Сообщение от n00by (ok), 26-Июн-22, 14:13	+/–
Я своими опилками не догоняю, как и что можно верифицировать в запрете прерываний. Посмотреть далее наличие Hlt и убедиться, что инициализируется Application Processor? У меня прям дымиться начинают опилки от этих мыслей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #458 Ответы: #461

461. Сообщение от burjui (ok), 26-Июн-22, 14:31	+/–
Такое ощущение, что ты притворяешься дурачком ради троллинга. Не могу поверить, что до сих пор непонятно. Какая разница, запрет прерываний это или что-то ещё? Нет контрактов - нет верификации. Контракты пишутся человеком, а не компилятором. Компилятор доверяет контрактам. Чем это принципиально отличается от unsafe в Rust?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #460 Ответы: #464

462. Сообщение от Аноним (-), 26-Июн-22, 15:29	–1 +/–
> Ну для RISC-V64 портировали, вроде. И на скольких железках оно реально взлетает? И хотя-бы вафлю с вон того usb свистка оно зацепит при этом? Или тем более какого-нибудь модуля, ктулху упаси, на SDIO каком? Это линукс то если в свежей версии цепляет и не очень глючит - уже за счастье. Ну и операционка с неотрываемым гуем на большинстве RISCV нужна как собаке пятая нога примерно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

463. Сообщение от Аноним (-), 26-Июн-22, 15:40	+1 +/–
> Вот в этом-то вся и соль. Зачем они хотят в майнлайн? Якобы, > что бы писать драйвера на Rust. Ну да. А что в этом пожелании такого плохого? В лине как-то принято с апстримом кооперироваться чтобы не усложнять себе и им жизнь лишний раз. Совместная работа над проблемой с двух сторон при наличии понимания и более-менее консенсуса с обоих сторон - эффективнее. > Когда мне понадобился Си++ в ядре Виндовс, я не слал в Микрософт письма с вопросами по > компилятору, а просто сел и начал писать, дальше люди помогли. С майкрософтом кооперация и коллаборация по сути невозможны. Я проверял. Это вообще совсем другие экосистемы и подходы и с точки зрения R&D это вообще-то их баг а не фича. В лучшем случае за майками можно выгрести их фекальи. В хучшем вы там %$^тесь как хотите и всем похрен. И на разработку кернела - так же. На его перфонмас. Фичи. И их отсутствие. Косяки. И даже откровенные баги. Гнилая экосистема и уж не ее адептам линуксоидов учить как надо. Просто сравнивая какие вещи напрягавшие меня и где удалось загасить и сколько усилий это от меня потребовало так и сяк. А майкрософт был отклассифицирован как "враждебный апстрим". И теперь "хорошо что это не у меня". Торвальдс предпочитает быть более конструктивным апстримом. И кроме всего прочего не собирается счастье к глотку саплгами заталкивать, кроме некоторых сильно принципиальных моментов, что выгодно отличает его от майкрософта, чей маркетинг практикует это с завидным постоянством. > При этом "сишники" никак не мешали, поскольку не было походов со своим > уставом в чужой монастырь. В итоге оно заработало (при этом драйвер > работал гораздо раньше, чем появилась поддержка исключений, которая в ядре нужна > не очень, но помогала не писать тесты, а брать готовые). У > растоманов уже есть какой-то драйвер, или только вот этот процесс внедрения? Ну так хрустикам придется интерфейситься к овердофига сишной начинки, нравится им это или нет. Никто не будет ради них все ядро переписывать да и не смогли бы в следующие цать лет. Они это или осилят или пойдут в пень, какие еще варианты есть? Если осилят, малацца, значит на хрусте можно и правда косиить под типа этакий си до кучи :) Что до виндовых дров - я не очень в курсе что там у них, их DDK и подходы меня всегда вымораживали оверинженерностью и сложностью, и тем что без огромной и нахреннужной мне студии шагу ступить невозможно. В паре с общей враждебностью майков к ядерным девам пусть им там кто другой дрова пишет, имхо. В _моей_ системе (где я могу _моим_ ключем влепить подпись на модуль себе) такие развлечения как-то сильно проще той порнографии которую по этому поводу предлагали майки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #443 Ответы: #465

464. Сообщение от n00by (ok), 26-Июн-22, 16:05	+/–
Возможно дело в том, что ты пытаешься везде разглядеть атаки на Rust. На само деле, мне интересна именно эта команда. Ты писал когда-нибудь команду cli? Если да, то зачем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #461

465. Сообщение от n00by (ok), 26-Июн-22, 16:19	+/–
>> Вот в этом-то вся и соль. Зачем они хотят в майнлайн? Якобы, >> что бы писать драйвера на Rust. > Ну да. А что в этом пожелании такого плохого? В желании писать - ничего плохого не вижу. > В лине как-то > принято с апстримом кооперироваться чтобы не усложнять себе и им жизнь > лишний раз. Совместная работа над проблемой с двух сторон при наличии > понимания и более-менее консенсуса с обоих сторон - эффективнее. А вот здесь вижу смешение понятий. Если драйвера нет, что кооперировать? Потенциальную возможность? >[оверквотинг удален] > совсем другие экосистемы и подходы и с точки зрения R&D это > вообще-то их баг а не фича. > В лучшем случае за майками можно выгрести их фекальи. В хучшем вы > там %$^тесь как хотите и всем похрен. И на разработку кернела > - так же. На его перфонмас. Фичи. И их отсутствие. Косяки. > И даже откровенные баги. Гнилая экосистема и уж не ее адептам > линуксоидов учить как надо. Просто сравнивая какие вещи напрягавшие меня и > где удалось загасить и сколько усилий это от меня потребовало так > и сяк. А майкрософт был отклассифицирован как "враждебный апстрим". И теперь > "хорошо что это не у меня". Я не понял, к чему это. Они контролируют ОС, но не могут запретить использовать ЯП. > Торвальдс предпочитает быть более конструктивным > апстримом. И кроме всего прочего не собирается счастье к глотку саплгами > заталкивать, кроме некоторых сильно принципиальных моментов, что выгодно отличает его > от майкрософта, чей маркетинг практикует это с завидным постоянством. И это не понял. >> При этом "сишники" никак не мешали, поскольку не было походов со своим >> уставом в чужой монастырь. В итоге оно заработало (при этом драйвер >> работал гораздо раньше, чем появилась поддержка исключений, которая в ядре нужна >> не очень, но помогала не писать тесты, а брать готовые). У >> растоманов уже есть какой-то драйвер, или только вот этот процесс внедрения? > Ну так хрустикам придется интерфейситься к овердофига сишной начинки, нравится им это > или нет. Это само собой разумеется. ZFS on Linux приходится, и Reiser 4 приходится. > Никто не будет ради них все ядро переписывать да > и не смогли бы в следующие цать лет. Они это или > осилят или пойдут в пень, какие еще варианты есть? Если осилят, > малацца, значит на хрусте можно и правда косиить под типа этакий > си до кучи :) На самом деле сишникам придётся качать сорцы на Rust, нравится им это или нет. Судя по комментариям, не всем нравится. И потом придётся смотреть патчи на Rust. И ревьювить... ну или так принимать. ;) > Что до виндовых дров - я не очень в курсе что там > у них, их DDK и подходы меня всегда вымораживали оверинженерностью и > сложностью, и тем что без огромной и нахреннужной мне студии шагу > ступить невозможно. В паре с общей враждебностью майков к ядерным девам > пусть им там кто другой дрова пишет, имхо. В _моей_ системе > (где я могу _моим_ ключем влепить подпись на модуль себе) такие > развлечения как-то сильно проще той порнографии которую по этому поводу предлагали > майки. Ну это сейчас так всё плохо, раньше было получше, в том числе и потому что Студия не умела собирать дрова.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #463 Ответы: #471

466. Сообщение от Аноним (-), 26-Июн-22, 16:27	+/–
> Точно красивее. Я заметил. Еще не менее красив их пример с функциями в параметрах, где у assignment'ов видите ли нет value, но вы можете вот так костыльнуть, но точку с запятой дескать вот тут ставьте а вот тут нет. Вот это я понимаю - наколень в дизайне ЯП, в отличие от сей, с оправданием что г@вно в синтаксисе так и задумано... И это, а оно может из функции несколько параметро вернуть кроме как struct'ом каким? И что за нафиг, почему имена нельзя назначать на выход? Они решили сделать все это вообще так же педальненько как в сях? :))) За примеры с структами и типами данных им в буке тоже факоф. Половина тем тупо не раскрыты. Окей гугл, покажите как красиво и без #$%чих закорючек вернуть допустим 1) статус операции, удалась она или нет (boolean) и 2) продвинутое инфо для тех кому не пофиг детали причины облома? Некрасиво я это и на сишке могу. У них эта тема вообще не раскрыта. Еще мне понравилось про 2's complement. Мол в дебаге ловим, в релизе нет. И чем это от ubsan в сях отличается, например? :) И почему & в референсе структов вон там надо а вон там можно не ставить? Это чо за недоделаеная ПОЛУавтоматика одного и того же? Они издеваются? :) Или можно ли там сделать допустим тип у которого валидное значение только от 3 до 8 а если больше пытаются - лучше всего компил сломать нахрен, т.к. это явно баг? Не, там и прикольные моменты есть, но... но вот например бук на их сайте писан явно какой-то корпоративной сволочью в программирование не способной совсем. Поэтому даже типовые кейсы и конструкции не раскрыты. Здорово конечно но прогать какие-то более-менее реалистичные программы по этому не особо научишься. Да еще везде свой карго культ гадский суют. > И удобнее, если брать не настолько синтетический пример. > И например в C вы можете сделать `return -42;`. А POSIX говорит, > что код должен быть в пределах `0 ..= 255`. В позиксе про _Exit написано такое: The value status & 0377 is returned to the parent process as the process's exit status, and can be collected using one of the wait(2) family of calls И если вам кажется что позикс паршиво специфицирован: да, это так. Но знаете что самое досадное для хрустиков? Вы его будете жрать точно таким же кривым. А лишние абстракции над этими кривульками как максимум могут прибавить глюков и непоняток. Переписывать ради вас таких красивых тот же позикс никто не будет. А стандартная либа это прекрасно, пока не потребовалось что-то ну вот натурально системное, именно вызовами в операционку и ее начинку. Потому что на вообще совсем все стандартных либ не напишешь. > И вот попробуй догадайся, 1) к чему такой код приведёт, 2) зачем язык > позволяет писать это. См. выше. Язык на самом деле просто не выделывается особо а позикс что, он писан укурками. Как впрочем и олдовые сишные типы с их никакущей спецификацией. В этом хруст даже имеет некие бонусы, но требование допустим u128 ставит раком некоторые платформы. На какой-нибудь 8-битной дряни его татк то тяжко. А если кто про системщину вякал и кроссплатформенность, нехило бы и в микроконтроллеры уметь так то. Иначе вместо альтернативы сям получается какой-то стеб.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #459 Ответы: #473

467. Сообщение от Аноним (-), 26-Июн-22, 16:42	+/–
Вообще-то волну гнать начал еще специалист по шаттлам из убунты. Но у него апстарт получился, скажем так, и хотя идея была прикольная (реакция на эвенты) оказалось что она в комплекте с некоторыми довольно специфичными граблями. А именно 1) В этой штуке было не особо предусмотрено как притащить системные дефолты с одной стороны, дать админу их перекрыть с другой и чтобы пакетник при апдейте это все не выпилил к хренам. Об этом убунтуи просто не подумали на фазе дизайна а потом поздняк метаться было. Посмотрел на это поттеринг и сделал деление на системные дефолты притаскиваемые пакетником и более приоритетный админский оверрайд, который пакетники трогать не смеют просто по регламенту. 2) Прописать СВОЮ программу "до" или "после" чьей-то еще? В СВОЕМ конфиге запускалки? Да сейчас! Это надо конфигу той программы трогать. Опачки, а это уже полный залет, надо чужую программу и ее компонент портить оказывается. Посмотрел на это все поттеринг и сделал инверсию зависимостей. И вот тогда стало хорошо. Можно вот именно своим юнитом стартануть перед или за кем-то совсем посторонним, если мы уверены что надо именно вот так. Ну например если я запускаю прогу которой надо впн - я могу запуститься после того как впн запустился, а не до того как его интерфейса даже еще нету блин, так что подвиснуть на нем точно ой -> FAILED. А sysv init вообще подобной фигней и много чем еще - не особо парился, вы там и...сь как хотите, дескать. Ну и творился трэш, угар и содомия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

468. Сообщение от Аноним (-), 26-Июн-22, 16:53	+/–
> практически не использую, потому что гораздо удобнее вывести структуры данных в > нужном формате через println!(), нежели ковыряться в сырых данных в gdb. Ну надо же, а у нас это "дебажный printf" называлось лет так .. дофига. Только у вас он оверинженернутый и можно поспорить баг сие или фича. И вдруг я что-то проприетарное пишу? Тогда я не хочу чтобы тем мордам утекали сведения о внутренней начинке программы в таких объемах, особенно с именами и прочим. > Это тебе, Онаниму, нужно идти продавать пылесосы, потому что твоим навыки демагогии > в программировании не только бесполезны, но ещё и вредны. В этой > профессии и без тебя дураков хватает. Просто напомноло уж очень логику продажников кирби. Мол покупайте пылесосы, смотрите, сколько пыли после вашего! Ух, а оказывается столько же и после их пылесоса будет, только про это не говорят :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #456

470. Сообщение от Аноним (-), 26-Июн-22, 17:03	+1 +/–
> Это когда регистр железно выполнен как RO, софт может туда и писать, > но ничего не изменит. А, обычный RO регистр, что-то я тупанул тут. Вообще регистры логично референсить как адреса в памяти, то-бишь указатели, и там чуть сложнее получается - const'ов может быть ДВА. У указателя (как индикатор что адрес регистра прибит на гвозди, зачем нам баги если мы сдуру указатель сменим?!) - и потом у его типа. Как бы именно volatile const'ом регистр вообще не референсится, скорее указателем на него. Хотя-бы потому что убедить си кинуть переменную в памяти по конкретному адресу... как бы это... ну, не предусмотрено. А с указателями пожалуйста. Интересно как хрустики кстати volatile делают и вот это самое, раз кудахчут про системность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #455

471. Сообщение от Аноним (-), 26-Июн-22, 17:44	+/–
> В желании писать - ничего плохого не вижу. Ну дык. И в совместной работе над проблемой по-моему тоже одни плюсы. Это эффективнее получается чем если кто-то что-то в своей норке. Русинович делал вон годные системные тулсы. Маленкие. Полезные. Крутые. Профессиональные. Решающие конкретные системные проблемы. Майки его купили. И ... чо?! Слили в унитаз? Не предложив внятной замены?! Этим они неслабо так нассали в норку весьма большому количеству народа. А продвинутые кодеры на такое скотство апстрима откровенно заагрились. Ну как, тот же dbgview допустим, полезная штука был. Но после скупки русиновича он умер. Блобик даже не то что сдох, но начиная с 2008 примерно стал работать как-то фифти-фифти. Где-то пашет, где-то нет. Зачем мне тул на который нельзя положиться? К тому же замены просто нет. Штатные средства майков это дикое оверинженернутое Г которое точно не будешь ставить чтобы заткнуть мелкую системную проблему здесь и сейчас по быстрому. ИМХО такому апстриму место в аду. > А вот здесь вижу смешение понятий. Если драйвера нет, что кооперировать? Потенциальную > возможность? Да, а чего? Если всерьез кодить с прицелом на надежность и безопасность, можно заметить что сишка белый, пушистый, но некоторые принципиальные тупняки в его дизайне - есть. При том настолько фундаментальные что полностью их заделать не могут даже мощные статические анализаторы. Правда насколько оно там у хрустиков лучше окажется вопрос открытый и не получится ли так что заткнув 10 проблем они поимеют 100 новых - кто ж его знает. А убогий отлов integer overflow как у них я даже на совсем обкоцаном микроконтроллере могу с урезаным ubsan на сях. Так что у меня возникло ощущение что в пиаре эти господа лучше чем в реальной системщине. А лучше бы наоборот. > Я не понял, к чему это. Они контролируют ОС, но не могут запретить использовать ЯП. Ну да. И наверное если очень захотеть, можно и для линукса так изгальнуться. Просто это будет именно "изгальнуться". С прошибанием всех стенок своим лбом. А оно такое надо? Если цель доказать из принципа что автомобилем можно при сильном желании сбить вертолет, ну, да, в каких-то отдельных допущениях может прокатить. А если цель без напрягов накодить драйвер, занимаясь написанием (логики) драйвера а не деланием мозга не очень связанными сложностями - ну, блин. К тому же ABI там все же наверное сишное, и для его соблюдения придется осетра местами урезать. Как и исползование фич плюсов. И получатся типа плюсы, которые как бы плюсы, но как бы не совсем плюсы. Хрустикам это тоже в принципе все светит, но там их вроде отдрессировали сделать натяг совы на глобус несколько элегантнее, хотя тоже костылями выглядит вообще-то :) > И это не понял. Я имел в виду что если вон та толпа народа хочет дрова на хрусте кодить, а зачем им собственно лом в вентилятор ставить? У Торвальдса же все просто - если совсем не понравится или вон те сдуются, с выпиливанием из кернела у него не ржавеет. > Это само собой разумеется. ZFS on Linux приходится, и Reiser 4 приходится. Ну да, только они в отличие от хрустиков выбрали сложный путь. И вот это уже сугубо их половые трудности как они там в своей норке будут с этим разгребаться. В ядре Linux это никому не интересно. И при перепашке подсистем ядра они скорее учтут интересы хрустиков чем этих. Такой вот парадокс. Можно в список еще НеБлоб драйвер нвидии добавить, если что-то не изменится будет примерно так же имхо. > На самом деле сишникам придётся качать сорцы на Rust, нравится им это или нет. А еще мы качаем кучу всяких self tests, опциональных утилит, скриптов и какой там еще требухи, которую я вообще не компилю и не запускаю в 95% случаев. Более того - у ядра есть достаточно нетривиальные опции, которыми пользуются не все. Кто из опеннетчиков хоть раз ядро с KASAN билдил? Или crash kernel? А качать - придется. Более того - десктопному хомяку придется скачать какие-нибудь модули infiniband-а. И даже если у тебя RISCV нету, его поддержку скачать придется. Более того - билдсистема может довольно активно пытаться предложить собрать модули для чипаков, скажем так, "довольно нехарактерных для x86 компьютеров". В теории конечно ничему не противоречит что на SPI или I2C какой-то мамки влепят именно вон то, но оно обычно в околомобилочных или эмбедовочных девайсах на ARM каком. Но это не только скачать заставят, но еще и при сборке придется осмысленно ответить на эти вопросы. Или не очень осмысленно но тогда от числа модулей можно немного офигеть. > Судя по комментариям, не всем нравится. И потом придётся > смотреть патчи на Rust. И ревьювить... ну или так принимать. ;) Таки да, это вызывает и у меня некоторые вопросы. Но если Торвальдс считает что может get it right - а пусть покажет, интересно посмотреть на это все. > Ну это сейчас так всё плохо, раньше было получше, в том числе > и потому что Студия не умела собирать дрова.) Ух, я даже не знаю когда она их не умела собирать. DDK у майков сколько я себя помню был чем-то типа нашлепки над студией чтоли. А с альтернативными тулчейнами было как-то не особо. Да еще качать DDK так просто довольно долго не давали, душась жабой. Не знаю в чем прикол, но если они хотели нагнуть системщиков, это получилось - те и нашли greener pastures где их не натягивают. А майки получили персональный привет из эпохи ARMов когда оказалось что винда на этом не работает. Точнее как-то что-то на квалкомах. А все остальное - упс. И желающих кодить дрова - около ноля. Их так и не попускает - после похорон виндофона они что-то там с UWP чтоли пыжились, но проблема с дровами довольно фундаментальная и сменой названия и перестановкой кроватей не решается :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #465 Ответы: #482

472. Сообщение от Аноним (-), 26-Июн-22, 18:26	+/–
> вот тут надо задуматься, ибо ЧПУшку надо программировать (пошагово) Вообще-то вот именно мне будет надо модельку отрисовать. Опять же при помощи компьютеров. А ее втрамбовку в возможности конкретной машины можно поручить тем у кого эта машина стоит, это довольно типовой вид отношений. Ну и вручную опять же все движения програмить никто не будет, только ограничения возможностей машины обыграют и усе, а основной объем команд сгенерится автоматикой из модели. > и получается, что мы придерживаемся строгих правил движения, это как черчение. Зубилом тоже не любой объект сможешь. Попробуй им полость внутри сделать без изъянов? И не любой материал сможешь. Ну, отзубиль кусок титана, допустим. А какой-нибудь 3D принтер в принципе может это обойти, другая технология - другие лимиты. При том модель он сожрет в общем то ту же самую. > Но ведь мы не "ценим" черчение так как "ценим" изобразительное искусство > (графику к примеру, без красок), вопрос - почему. С другой стороны, лично я вполне оценил ролик про "костюм железного человека" на ютубе. Из титана, выдерживает попадание пуль, и даже летает (хоть и оказалось что есть нюансы). И хотя его можно повторить, это дорого, возни много, а смысла мало, к тому же надо с правообладателем опять согласовывать. Поэтому он такой один на всю планету. Зачетный артефакт так то. В общем то ценим мы, имхо, талант, креативность, оригинальные идеи и что-то неординарное. Вот именно черчеба в чистом виде как и рутинная трансляция команд этим не является. А оригинальная модель и проект в целом - уже вполне. Ну и когда оно масспродакшн то оно просто приедается и начинает восприниматься как должное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #454

473. Сообщение от warlock66613 (ok), 26-Июн-22, 18:29	+/–
> вы можете вот так костыльнуть, но точку с запятой дескать вот тут ставьте а вот тут нет. Вот это я понимаю - наколень в дизайне ЯП, в отличие от сей, с оправданием что г@вно в синтаксисе так и задумано... Это как раз одна из самых красивых вещей. Одна из тех, пр которые давно стало понятно как надо делать правильно, и вот Rust (не считая, конечно, Haskell и т.п.) наконец воплотил. > оно может из функции несколько параметро вернуть кроме как struct'ом каким? Туплом. > почему имена нельзя назначать на выход? Они решили сделать все это вообще так же педальненько как в сях? Так и на вход нельзя. Симметрия. Ну и если уж нужны имена, то может стоит придумать ещё всего одно имя  и сделать именованную структуру? Ну и почему прямо как в сях? В хаскеле тоже так, например. > У них эта тема вообще не раскрыта. Эта тема общая для всех языков с ADT, никакой Rust специфики в ней нет. > И чем это от ubsan в сях отличается, например? Тем, что здесь это не UB. > И почему & в референсе структов вон там надо а вон там можно не ставить? Это вопрос из серии из серии "почему в русском языке тут надо запятую ставить, а тут не надо". Потому что такие правила. Чтобы обсуждать предметно, нужна альтернатива. Только лучше не получится. > можно ли там сделать допустим тип у которого валидное значение только от 3 до 8 Можно, но не нужно, потому что без зависимых типов ценность у таких типов нулевая (если не отрицательная), ибо при первой же арифметической операции все эти ограничения теряются и они превращаются в полноразмерный тип. > Здорово конечно но прогать какие-то более-менее реалистичные программы по этому не особо научишься. Потому что это учебник языка, а не учебник программирования. > требование допустим u128 ставит раком некоторые платформы А что, длинную арифметику отменили? Атомарности Rust не требует от такого типа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #466 Ответы: #478, #487

474. Сообщение от Аноним (-), 26-Июн-22, 18:30	+/–
> procedure Asm ( >   Template : String; >   Outputs  : Asm_Output_Operand_List; >   Inputs   : Asm_Input_Operand_List; >   Clobber  : String  := ""; >   Volatile : Boolean := False); Что это за ужас? Это вроде не хруст? Они даже хрустиков по ужасному синтаксису сделали, с отрывом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #458

475. Сообщение от Аноним (477), 26-Июн-22, 19:01	+/–
> Мамой клянусь ... Не клянись, никогда, ничем. Тем более в вопросах языка на котором здесь никто не написал ни одной строчки кода. И никто не проверял что компилятор ADA эще с этим делает. Клястся не хорошо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #412

476. Сообщение от Аноним (477), 26-Июн-22, 19:34	+/–
> кто-то признал, что 100% гарантий не даст ни один ЯП Конечно не даст. В верификаторах SPARK наверняка есть ошибки, программист может "неаккуратно что написать" и бажный верификаторах пропустит дыру. Со временем вылежут и баги. > я узнал о новом для себя ЯП, который имеет смысл изучить хотя бы для кругозора Мне точно известно что версия SPARK-2021 у них получилась наконец рабочая. И компилятор GNU для ADA в 2021 году так-же наконец получился рабочим и пригодным для промышленного использования. Год прошел, а я так и не решилась что-то написать, другие задачи. Меня интересуют ответы на вопросы: 1. Насколько готовый бинарь со SPARK медленнее бинаря скомпиленого с C. 2. Задачи жесткого реального времени. В ASM и C можно рассчитать количество тактов проца необходимых для работы проги. А в SPARK  можно дать гарантии исполнения бинаря за определенное количество тактов процессора? 3. Насколько долго писать на SPARK по сравнению с C или Python? Трудозатраты?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #427 Ответы: #479

477. Сообщение от Аноним (477), 26-Июн-22, 19:52	+/–
> уязвимостей нет, Уязвимость есть они никуда не денутся. Криворукий сишник таки ошибку сделал. Благодаря проактивной защите реализованной в ОС и процессоре, бажную прогу убили и записали лог о ошибке. > а то что прога падает - так это проблемы пользователя, Да. Сишники, когда им лог падения высылаешь и пальцем показываешь на баг, иногда с патчем, так и говорят,- да пошли вы со своими проблемами и вашей "проактивной защитой"... > на Rust принципиально писать не будем. Я стал противником go и по инерции Rust когда увидел список зависимостей к ipfs, при компиляции мне с инета начало тянуть >1200 никем не подписаных пакетов. Также считаю Rust в ядре Linux неуместным, пусть оно остается на C и ASM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #453

478. Сообщение от warlock66613 (ok), 26-Июн-22, 20:05	+/–
> Так и на вход нельзя. Симметрия. Точнее так: на вход имена не может указывать вызывающая сторона (нет вызова функции с именованными параметрами), а на выход, наоборот, вызываемая (функция не может специфицировать имена для полей результата). И наоборот, функция при описании специфицирет имена входных параметров, а вызывающая сторона может декомпозировать результат в набор именованных параметров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #473 Ответы: #488

479. Сообщение от warlock66613 (ok), 26-Июн-22, 20:14	+/–
> В ASM и C можно рассчитать количество тактов проца необходимых для работы проги. А вот объясните, как специалист, каким образом можно рассчитать количество тактов в асм, если оно зависит как минимум от того как удачно бранч предиктор справится со своей задачей?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #476 Ответы: #495, #496

480. Сообщение от Аноним (480), 26-Июн-22, 22:54	+/–
надо просто понять что есть аналог void'а: https://doc.rust-lang.org/std/primitive.unit.html ну и немного привыкнуть к Result, потом это не кажется чем-то страшным
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

481. Сообщение от Аноним (480), 26-Июн-22, 23:02	+/–
Простите, ваша фамилия случайно не Головин?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #348

482. Сообщение от n00by (ok), 27-Июн-22, 09:48	+/–
>> В желании писать - ничего плохого не вижу. > Ну дык. И в совместной работе над проблемой по-моему тоже одни плюсы. Где она, эта совместная работа? Где для неё обоснованные предпосылки? Грег Кроа-Хартман собирает статистику по коммитерам. Есть данные, сколько знают Rust? Сколько готовы писать на Rust? >> А вот здесь вижу смешение понятий. Если драйвера нет, что кооперировать? Потенциальную >> возможность? > Да, а чего? Если всерьез кодить с прицелом на надежность и безопасность, > можно заметить что сишка белый, пушистый, но некоторые принципиальные тупняки в > его дизайне - есть. При том настолько фундаментальные что полностью их > заделать не могут даже мощные статические анализаторы. Правда насколько оно там > у хрустиков лучше окажется вопрос открытый и не получится ли так > что заткнув 10 проблем они поимеют 100 новых - кто ж > его знает. Ну вот, никто не знает, никто не попробовал. Готовятся к экспериментам на живом теле. В моём понимании, это стоило развить отдельно, создать что-то уровня Reiser4 - тогда никто не сможет возразить. Придётся моча учить Rust или идти подстригать газон. > А убогий отлов integer overflow как у них я > даже на совсем обкоцаном микроконтроллере могу с урезаным ubsan на сях. > Так что у меня возникло ощущение что в пиаре эти господа > лучше чем в реальной системщине. А лучше бы наоборот. Вот к этому я и клоню. Им важен не результат, а сам процесс внедрения, шум вокруг него. Зачем Гуглю этот процесс? У них есть своё новое перспективное ядро - Фуксия. Зачем им тогда Линукс? >> Я не понял, к чему это. Они контролируют ОС, но не могут запретить использовать ЯП. > Ну да. И наверное если очень захотеть, можно и для линукса так > изгальнуться. Просто это будет именно "изгальнуться". С прошибанием всех стенок своим > лбом. А оно такое надо? В Линукс это не надо, поскольку много человек долгие годы пишут ядро на Си. В Виндосе нет такого решающего фактора, как традиция и мнение сообщества, каждый сам себе паровоз. Были Керниган и Риччи, придумали Си, создали Юникс. Был Чарльз Симони, придумал венгерскую нотацию, получился в итоге Виндос. > Если цель доказать из принципа что > автомобилем можно при сильном желании сбить вертолет, ну, да, в каких-то > отдельных допущениях может прокатить. А если цель без напрягов накодить драйвер, > занимаясь написанием (логики) драйвера а не деланием мозга не очень связанными > сложностями - ну, блин. Вот мне и требовалось решать задачу, где слишком много логики, что для ядра в принципе не свойственно. В Виндовсе много технологических отверстий, потому антивирус из пространства пользователя мало что насканирует, надо быть в ядре. Пока я не вижу драйвера на Rust, где бы была такая логика, мне ситуация не очень понятна. > К тому же ABI там все же > наверное сишное, и для его соблюдения придется осетра местами урезать. Как > и исползование фич плюсов. И получатся типа плюсы, которые как бы > плюсы, но как бы не совсем плюсы. Хрустикам это тоже в > принципе все светит, но там их вроде отдрессировали сделать натяг совы > на глобус несколько элегантнее, хотя тоже костылями выглядит вообще-то :) >> И это не понял. > Я имел в виду что если вон та толпа народа хочет дрова > на хрусте кодить, а зачем им собственно лом в вентилятор ставить? А они уже кодили дрова? В Виндосе самый первый драйвер, который пишут, как правило специально генерит BSOD разыменовыванием NULL. ИМХО что-то в этом есть. > Таки да, это вызывает и у меня некоторые вопросы. Но если Торвальдс > считает что может get it right - а пусть покажет, интересно > посмотреть на это все. Торвальдс перед всей этой историй уходил в странный отпуск, что бы подумать. >> Ну это сейчас так всё плохо, раньше было получше, в том числе >> и потому что Студия не умела собирать дрова.) > Ух, я даже не знаю когда она их не умела собирать. DDK > у майков сколько я себя помню был чем-то типа нашлепки над > студией чтоли. Вот во времена DDK и не умела, в DDK шел свой транслятор в комплекте, сопровождалось это религиозным убеждением, что с другой версией обязательно случится BSOD. Потом DDK стал называться WDK. Наверное, 2008я Студия научилась собирать, зачем-то же я её устанавливал посмотреть. > А с альтернативными тулчейнами было как-то не особо. Да > еще качать DDK так просто довольно долго не давали, душась жабой. IFS Kit не давали. Прикол был в том, что вход в файловые системы только через курсы на OSR. И дело там не в жабе - они так искали специалистов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #471 Ответы: #486

483. Сообщение от Аноним (-), 27-Июн-22, 14:25	+/–
https://kevinlynagh.com/rust-zig/ > Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun > With Rust 1.50, a from-scratch debug build of my keyboard firmware takes 70 seconds (release, 90 seconds) and the target/ directory consumes 450MB of disk. > Zig 0.7.1, on the other hand, compiles my firmware from-scratch in release mode in about 5 seconds and its zig-cache/ consumes 1.4MB. Nice! Эх, не тот язык выбрали добавлять в линукс
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #494

484. Сообщение от Анончик (?), 27-Июн-22, 16:08	+/–
Хорошо, софта накидали. Правда он для каких-то дедов, ну ладно. Но если шиндоуз такой хороший, почему мне не хочется возвращаться? Просто интересно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #317

485. Сообщение от Аноним (138), 27-Июн-22, 16:09	+1 +/–
Миранда для чего-то пригодна в 2022?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #366 Ответы: #491

486. Сообщение от Аноним (-), 27-Июн-22, 16:20	+/–
> Где она, эта совместная работа? В случае сабжа для этого честно говоря рано. Поэка это в виде полураздристаного экспериментального нечто, им пользуются только полтора ультра-хардкорщика. Что логично. > Где для неё обоснованные предпосылки? Обоснованной предпосылкой будет очевидно появление этого в ядре. Вот там станет понятнее - есть что-то кроме воплей что %s это круто, или только гнилой пиар. > Грег Кроа-Хартман собирает статистику по коммитерам. Есть данные, сколько знают Rust? > Сколько готовы писать на Rust? На немайнлайнутой не устаканившейся реализации заведомо готово кодить чуть более ноля. А сколько на более адекватной застабилизированой реализации, с обтоптаными уже граблями - вопрос интересный. Этот эксперимент его и покажет. А не понравится - это будет далеко не первое что вылетело из линукскернела. > Ну вот, никто не знает, никто не попробовал. Готовятся к экспериментам на живом теле. Синтетические эксперименты не дают объективных результатов. И в силу опциональности этой штуки каждый сам может решить, надо ли оно ему. Я как минимум первое время буду это отключать, ибо заниматься тантрами с скачкой особой уличной магии^W ночнушек хруста я точно не готов. А если это будет дистровской версией цепляться, и желательно на основе gcc, там видно будет. > В моём понимании, это стоило развить отдельно, создать что-то > уровня Reiser4 - тогда никто не сможет возразить. Придётся моча учить > Rust или идти подстригать газон. В смысле? Я не думаю что ядерщики перестанут принимать сишный код в обозримом будущем. А загадывать на 50 лет вперед в таких вещах дело неблагодарное. > Вот к этому я и клоню. Им важен не результат, а сам > процесс внедрения, шум вокруг него. У меня тоже такое ощущение есть. Но кроме этого в хрусте все же есть парочка дельных идей. > Зачем Гуглю этот процесс? У них много на это завязано, CVE их потрахивают, линукс у них много где, им это не нравится. > У них есть своё новое перспективное ядро - Фуксия. Зачем им тогда Линукс? Я вообще не уверен что этот кусок хайпоты с FAT'ом на игого жизнеспособен. Гугл и куда более крупные проекты сливал в трэш, типа гуглоплюса и Wave, под дружный вой всех кто вляпался. > В Линукс это не надо, поскольку много человек долгие годы пишут ядро на Си. А кто и почему решает что надо в Linux? А, Торвальдс и его майнтайнеры? Ну так если они поскрипели и решили что вон то им оки, я им поверю. А вот конкретно я могу и не собирать хайпоту от гугля на хрусте. Что мне от них надо в ближайшее время? > В Виндосе нет такого решающего фактора, как традиция и мнение сообщества, > каждый сам себе паровоз. И в конечном итоге желающих кодить дрова для виндов почти и не осталось. Что при омобиливании мира и гегемонии там ARM очень хорошо нагнуло майкрософт. Так себе история успеха. > Были Керниган и Риччи, придумали Си, создали Юникс. Был Чарльз Симони, > придумал венгерскую нотацию, получился в итоге Виндос. Только вот я Linux использую, который GNU, а он как известно, GNU is Not Unix. И я об этом помню. И сишку я предпочитаю минимум 99-ю. За хотя-бы вменяемые типы данных. Потому что вот честно, "int" это перманентный источник грабель и брейнфака в си при попытке писать портабельно. И правила integer promotion у сей тот еще брейнфакт. А указатели это круто и эффективно, но... статический анализ на них делать в вменяемом виде - невозможно. Так что K&R для своего времени зажгли неплохо. Получше чем разработчики раста - но даже так, кто вот ща на K&R C вообще шпрехает? А вменяемые кодеры и типы данных C99 давно освоили. И даже содрали у хайлевелеров идеи типа возврата struct и проч для нормальных апи, а не, пардон, получения выхлопа функции в указателе поданом на ВХОД (это ушлепское убиение структурирования проги, в одном ряду с goto). > Вот мне и требовалось решать задачу, где слишком много логики, что для > ядра в принципе не свойственно. В Виндовсе много технологических отверстий, В Linux при желании можно ... наверное вообще совсем все. Я например из юзермода регистры железа трогал. Это делать конечно нельзя, потому что рушит парадигму многозадачки. Но если я уверен что я там один - прокатывает. С ремаркой "не пытайтесь повторить это у себя дома". Это не технологическое отверстие, а, пардон, complete takeover. Конечно, только от рута. В новых ядрах можно рубануть, DRMщики "lockdown" пропихали, но он и для секурити системы катит. > потому антивирус из пространства пользователя мало что насканирует, надо быть в ядре. Иные антивирусы сами почти как руткит, для самозащиты. Для меня это повод не пользоваться ими. Руткитобразный блоб без сорца доверия не внушает. Почему-то. > Пока я не вижу драйвера на Rust, где бы была такая > логика, мне ситуация не очень понятна. Могу даже немного натянуть сову на глобус. Вот смотри, билдсистема кернела пиндит если stack frame превышает 1024 байта. Большие стэкфреймы в именно ядре с кучей всего - ведут к дурным проблемам. К сожалению это означает что дровописаки начинают любить динамическое выделение памяти. А вот с этим не поздравляют, ибо все-таки известный источник проблем. Правда у хрустиков решение проблемы само получилось тем еще костылем, чтобы не просто паниковало, при том не особо совместимым с другим кодом на хрусте :))) и доступное только в ночнушках или типа того. В общем так себе спасители человечества. > А они уже кодили дрова? Ну, как минимум, что-то пытаются изобразить. Совсем без этого они бы прослойку нишмагли, как и понять какие у ванили проблемы относительно ядра. Им сразу в рассылке сказали - мол, чего фигней страдаете, пишите какой-нибудь реалистичный драйвер, узнаете свои реалистичные грабли. Здравые коменты, между прочим, и они вроде вняли. > В Виндосе самый первый драйвер, который пишут, как правило специально > генерит BSOD разыменовыванием NULL. ИМХО что-то в этом есть. Мне это честно говоря не очень понятно. Я даже когда фирмвари писать учился первое что было все же помигать светодиодиком, потом сказать hello world в уарт например. А вот NULL отдереференсить и поймать свой HardFault - продвинутости, точно не первая штука. Я все же пишу код не для того чтобы он валился. > Торвальдс перед всей этой историй уходил в странный отпуск, что бы подумать. Я честно говоря вообще не понимаю как он выживает с его режимом. > Вот во времена DDK и не умела, в DDK шел свой транслятор в комплекте, > сопровождалось это религиозным убеждением, что с другой версией обязательно > случится BSOD. Потом DDK стал называться WDK. Наверное, 2008я Студия научилась > собирать, зачем-то же я её устанавливал посмотреть. Я когда-то, в эпоху раннего реактоса, смог собрать пару NT DRIVERS обычным gcc'ом и реактосовскими обвесом кажись, но это было довольно враждебно и потом они в подписи вдарились а рекатос в 2-й раз занялся перепиской кернела и я для себя решил что такие экосистемы я видал разве что в аду. К этому моменту мне как раз удачно подвернулась какая-то ранняя убунта на бесплатном сидюке, который не пропал даром =) > IFS Kit не давали. Прикол был в том, что вход в файловые > системы только через курсы на OSR. И дело там не в > жабе - они так искали специалистов. Их до сих пор так и не попустило до конца походу. Вон юзерам новых маздаек ReFS зачем-то покоцали. Довели несчастных, WinBTRFS пилят с горя :). В общем MS vs FS это проклятое место походу. Они почему-то мнят что их технологии такие офигенные что позволяют выкрутку рук. Поэтому все годное что случается в этом направлении стало почему-то в пингвине :). Иногда майкрософт в своей жабе походу начинает жрать свой же хвост.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #482 Ответы: #503

487. Сообщение от Аноним (-), 27-Июн-22, 17:24	+/–
> Это как раз одна из самых красивых вещей. Агаблин, кроме лаконичного и унифицированного синтаксиса (== эффективный тул). В этом месте мы понимаем почему говорят что краткость сестра таланта. И нет, вот именно то в сишке обычно никаких проблем никому не создавало, так что починили то что не сломано. Хз нафига. > Одна из тех, пр которые давно стало понятно как надо делать правильно, и вот Rust > (не считая, конечно, Haskell и т.п.) наконец воплотил. Лично я не понимаю хаскелистов, они слишком сферически-вакуумные для написания реальных программ. Решают какие-то проблемы которые мне до 3.14-ды, а мне до того же они и их программы с яп-ом. > Туплом. Спасибо, если сложные вещи возвращать я и в сях struct могу нарисовать, но это не очень удобно и не очень красиво, лишние закорюки. С фига вот нельщя -> i32, i16 и return (10, 20)? И почему я должен это в тупл совать если они логически не связаны между собой? > Так и на вход нельзя. Симметрия. Как это? https://doc.rust-lang.org/book/ch05-02-example-structs.html fn area(width: u32, height: u32) -> u32 { По-моему, width и height это 2 именованых входных параметра, при том хотя дока про struct'ы, в именно этом случае оно как раз без них. А вот так же, симметрично, на выход сделать - уже фиг. И где симметрия?! Но вон то с impl'ом довольно симпатично. >  Ну и если уж нужны имена, то может стоит придумать ещё всего одно имя  и сделать > именованную структуру? Ради пары integer'ов не рулит. Больше писанины и закорючек в конечном итоге. При том для эффективного референса (указатель) в хрусте как я понял тоже & надо и когда он вон там автоматически добавляет, а вот там нет - это называется костыльный и ни разу не стройный дизайн ЯП имхо. Опять же симметрия продолбана. > Ну и почему прямо как в сях? В хаскеле тоже так, например. Чисто практически хаскелисты - один из самых бесполезных видов програмеров которых я знаю. Развели концепций и абстракций во имя луны, но ни одной полезной программы на этом я не встречал за всю мою жизнь. Так что ценность тех брейнфартов мне не очевидна. Я в курсе что уйдя в матрицу можно не вернуться, в их случае - поголовно. > Эта тема общая для всех языков с ADT, никакой Rust специфики в ней нет. Если я смотрю на хруст и его синтаксис, да еще в их буке, кивать куда-то еще очень сильно не комильфо, имхо. Смысл в таком буке? > Тем, что здесь это не UB. Если ubsan активировать, становится  defined behavior'ом, так же дает в тыкву, 1 в 1 :). Есть даже лайтовый режим когда там очень небольшой оверхед когда это вызывает хардварное исключение проца типа Bad Opcode вместо навороченого рантайма, так даже на микроконтроллерах живет (конечно же продолбав скорость и увеличив код). Могу себе представить что у него вот так оверхеда зело меньше чем у дебагбилда хруста. Не ноль конечно. > Это вопрос из серии из серии "почему в русском языке тут надо > запятую ставить, а тут не надо". Если уж мы об этом, русский язык уж точно не стоит брать за пример при создании ЯП. Сложный, несимметричный, кривой, с кучей "легаси". Какой % жителей РФ им нормально владеет в виде когда они могут хотя-бы писать без тупых ошибок? :))) > Потому что такие правила. Чтобы обсуждать предметно, нужна альтернатива. > Только лучше не получится. "Убийц хруста" уже несколько штук есть. Видимо сомневаются - и имеют на то причины. Я что-то не вижу заявленной симметрии - и это в самых базовых вещах из их же бука. > Можно, но не нужно, потому что без зависимых типов ценность у таких > типов нулевая (если не отрицательная), ибо при первой же арифметической операции > все эти ограничения теряются и они превращаются в полноразмерный тип. Мде. Ну например, есть некий алгоритм. Он доказуемо-валидно себя ведет "от сих до сих". А с другими значениями начинает делать бред, вплоть до out of bounds. И мне совсем не катит чтобы он out of bounds или даже панику сделал в рантайме, например. И нехило бы в компилтайме чекнуть что оно именно вот так. Что до арифметических операций, нехило бы какой-то варнинг или типа того в таким случаях, что "невозможно пруфнуть". Как намек что я вообще-то должен пересмотреть этот код из соображений стабильности, безопасности и верификации. В этом смысле Zig с компилтайм вычислениями любопытно выглядит, там наверное такую сову на глобус даже реально. > Потому что это учебник языка, а не учебник программирования. Вообще-то предполагается что это учебник программирования на этом языке. С какими-то более-менее реалистичными конструкциями. > А что, длинную арифметику отменили? Атомарности Rust не требует от такого типа. На 8-битном уродце лестница арифметики получается такая что часто всем просто вломы это. И честно говоря я не понимаю зачем u128 делать базовым типом. Для BigInt мало, на большей части платформ не особо эффективно, мелочевку нагибает (байбай, универсальность), а в реалистичных случаях всякие там смещения в файлах и проч к 2^64 врядли приблизятся в обозримом будущем. Они там сингулярность запилили втихаря?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #473 Ответы: #502

488. Сообщение от Аноним (-), 27-Июн-22, 17:26	+/–
> Точнее так: на вход имена не может указывать вызывающая сторона (нет вызова > функции с именованными параметрами), а на выход, наоборот, вызываемая (функция не > может специфицировать имена для полей результата). А симметрия тут в каком месте возникает? Может, имелась в виду АНТИсимметрия? Вот в это я готов поверить :)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #478 Ответы: #501

489. Сообщение от Аноним (-), 27-Июн-22, 17:37	+/–
> Так это будет потом. Когда привыкнут, что Rust уже и так есть, > выйдет версия 2.0. Окно Овертона же. Скорее, научат хруст eBPF какой генерить и в юзермод вывесят :))). Но между нами, вон там LLVM или кто еще GPUшке в юзермоде шейдеры как-то так и компиляет. Теоретически, это может быть безопасно. Практически, как-то наподобие трахнули xbox360, чтоли, поклав на многоэтажную систему DRMной секурити...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #447

490. Сообщение от Аноним (-), 27-Июн-22, 17:40	+/–
У гну кстати прикольное расширение есть для switch-case, с диапазонами. Но, увы, это не стандарт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #271

491. Сообщение от Аноним (-), 27-Июн-22, 17:42	+/–
> Миранда для чего-то пригодна в 2022? Гм, эту стюардессу оказывается откопали - см. соседнюю новость.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #485

492. Сообщение от Аноним (-), 27-Июн-22, 17:45	+/–
Таки почти все вымерли кроме очень специальных случаев, перейдя на цифру. Конечно, профессиональную и за совсем другие деньги. Как угодно но в цифре потом редактировать например куда как лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #223

493. Сообщение от Аноним (-), 27-Июн-22, 17:49	+/–
Сишники видите ли обычно системщики. А это свободный и гордый народ, знающий себе цену. Предпочитающие некую автономию и самодостаточность, без лизания ботинок гугла, майкрософта и амазона. А ваше светлое будущее с лизанием ботинок вон тем - выглядит довольно так себе. Ага, репы контролирует "некомерческий" фаундейшн с некоммерческими директорами из амазона, гугла и майкрософта. И вот это уже выглядит как годная заявка на сдачу им в рабство. Почему-то. Хотя белый человек так то давно просек что папуас на бусы ведется и активно пользовался...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #387

494. Сообщение от Аноним (-), 27-Июн-22, 17:51	+/–
> Эх, не тот язык выбрали добавлять в линукс А откоменть в рассылку по приколу, если пользуешься им и можешь аргументировать? На первый взгляд Zig прикольнее хруста, но я активно им не пользовался и не смогу аргументировать на должном уровне :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #483 Ответы: #512

495. Сообщение от Аноним (499), 27-Июн-22, 18:13	+/–
Там считают не минимум (с "предсказаниями" проца) а максимум, чтобы сказать: "вот за такое количество тактов прога гарантировано отработает".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #479

496. Сообщение от Аноним (499), 27-Июн-22, 18:31	+/–
Если с предсказаниями рассчитывать, то считаем по худшему варианту.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #479 Ответы: #498

497. Сообщение от Аноним (499), 27-Июн-22, 18:40	+/–
> секты свидетелей прямых рук Есть еще свидетели секты мозготраха, веруют, что он позитивно влияет на безопасность и без него ИТ безопасности не бывает. К стати а на каком из уровней ИТ безопасности в США требуется чистка персонала? C: DAC B: MAC A1: математическое доказательство корректности кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #421

498. Сообщение от Аноним (499), 27-Июн-22, 18:48	+/–
Лучше без предсказателя считать и работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #496

499. Сообщение от Аноним (499), 27-Июн-22, 19:47	+/–
>> А конкретно Rust вместо безопасности добавит новые классы уязвимостей. > На каком основании вы сделали такой вывод? Новый язык, другой компилятор, от других людей, новые дыры: https://www.cvedetails.com/vulnerability-list.php?vendor_id=... https://www.developer-tech.com/news/2022/jan/24/rust-vulnera.../ Намного усложнитса поддержка и аудит кода. И это еще не те новые классы уязвимостей которые я иметь ввиду. Вся модель безопасности ОС держится на правеле: что исполняется не должно изменятся, а что изменяется не должно исполнятся (согласовано учеными конца 1960-тых и принято в стандарт 1983). В помощь инструкции проца NX, PAE. С этого следуют требования к защите памяти: CONFIG_PAX_MPROTECT=y - changing the executable status of memory pages that were    not originally created as executable, - making read-only executable pages writable again, - creating executable pages from anonymous memory, - making read-only-after-relocations (RELRO) data pages writable again. ОС в которых эти требования не соблюдаются, не имеют правильной защиты памяти и есть уязвимы. Рассуждения: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... Executable code and read-only data must not be writable ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Any areas of the kernel with executable memory must not be writable. While this obviously includes the kernel text itself, we must consider all additional places too: kernel modules... Это же относится и ко всему прикладному ПО без исключений и копромисов на JIT, PBF, ... и прочью дрянь. Принципиальный вопрос о толерантности к Rust, в прикладном ПО, зависит от строгого следования этим правилам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #407 Ответы: #508

500. Сообщение от Аноним (500), 28-Июн-22, 00:08	+/–
там про то что утечки памяти пишут, так я скажу то драйвер написанный тем у кого на плюсах память течет - скорее всего студент первого курса. ну а ты раз ссылаешься безосновательно на на прочтение статьи - дичь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

501. Сообщение от warlock66613 (ok), 28-Июн-22, 02:28	+/–
Антисимметрия — это частный случай симметрии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #488

502. Сообщение от warlock66613 (ok), 28-Июн-22, 03:41	+/–
> И нет, вот именно то в сишке обычно никаких проблем никому не создавало Одна из самых известных проблем, ради которой какие только костыли ни придумывали — и "сравнение наоборот" (`2 == x` вместо `x == 2`), и дополнительные скобки и чего только не придумывали. А всё что нужно — чтобы присваивание не возвращало значения. > С фига вот нельщя -> i32, i16 и return (10, 20)? Потому что `(10, 20)` — это и есть тупл. Поэтому `-> (i32, i16)`. > По-моему, width и height это 2 именованых входных параметра Но при вызове функции эти имена теряются, нельзя позвать `area(width: 1, height: 2)`. С возвращаемым значением наоборот — при вызове можно поименовать компоненты тупла: `let (width, height) = function();`, а в сигнатуре функции они безимянные. > когда он вон там автоматически добавляет, а вот там нет Автореференс делается в одной, строго оговорённой ситуации. Есть один реальный кейс, где это реально выливается в неприятную штуку, но тут просто нет решения лучше, нет альтернативы. > Если я смотрю на хруст и его синтаксис, да еще в их > буке, кивать куда-то еще очень сильно не комильфо, имхо. Смысл в > таком буке? Смысл в том, что это не учебник программирования. > Если ubsan активировать, становится  defined behavior'ом, так же дает в тыкву, > 1 в 1 :). Ну и в чём проблема-то? > "Убийц хруста" уже несколько штук есть. Они даже близко не стоят по степени готовности. > И нехило бы в компилтайме чекнуть что оно именно вот так. Без зависимых типов это всё паллиатив, мёртвому припарка. Но в Rust такое можно сделать, без проблем. Только ерунда это. > какой-то варнинг Непонятно что с этим ворнингом дальше делать. Только затыкать, но тогда это некорректный ворнинг получается, такому ворнингу в компиляторе не место, он как минимум в линтере должен быть, а то и вообще в полноценном статическом анализаторе. Но полноценный статический анализатор и без явного типа-диапазона может провести доказательство, что в нужном месте паника не возникает. > Вообще-то предполагается что это учебник программирования на этом языке. С какими-то более-менее реалистичными конструкциями. Я не знаю кем такое предполагается. Учебник — это совсем другая книга, другой жанр. Например, не может быть учебника без задач. > На 8-битном уродце лестница арифметики получается такая что часто всем просто вломы > это. И честно говоря я не понимаю зачем u128 делать базовым > типом. Для BigInt мало, на большей части платформ не особо эффективно, > мелочевку нагибает (байбай, универсальность), а в реалистичных случаях всякие там смещения > в файлах и проч к 2^64 врядли приблизятся в обозримом будущем. Не могу тут ничего сказать. Не знаю. Но, например, монотонное время в наносекундах в u64 не влезает. Так, в линуксах `timespec` состоит из 64-битных секунд и 32-битных наносекунд, так что если пытаться упаковать это в одно число, то нужно u128. Но это, конечно, слабый аргумент.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #487 Ответы: #506

503. Сообщение от n00by (ok), 28-Июн-22, 10:26	+/–
>> В моём понимании, это стоило развить отдельно, создать что-то >> уровня Reiser4 - тогда никто не сможет возразить. Придётся моча учить >> Rust или идти подстригать газон. > В смысле? Я не думаю что ядерщики перестанут принимать сишный код в > обозримом будущем. А загадывать на 50 лет вперед в таких вещах > дело неблагодарное. В смысле, что Окно Овертона открывается постепенно. Безопасность же. За безопасность так или иначе приходится платить. Обяжут. >> В Виндосе нет такого решающего фактора, как традиция и мнение сообщества, >> каждый сам себе паровоз. > И в конечном итоге желающих кодить дрова для виндов почти и не > осталось. Сейчас ломается традиция писать Linux на Си. >> Пока я не вижу драйвера на Rust, где бы была такая >> логика, мне ситуация не очень понятна. > Могу даже немного натянуть сову на глобус. Вот смотри, билдсистема кернела пиндит > если stack frame превышает 1024 байта. Большие стэкфреймы в именно ядре > с кучей всего - ведут к дурным проблемам. К сожалению это > означает что дровописаки начинают любить динамическое выделение памяти. А вот с > этим не поздравляют, ибо все-таки известный источник проблем. Именно это много лет как решает Си++ с std::unique_ptr. И я видел proposal в ISO/IEC 9899 на тему автоматического вызова функции очистки при выходе из scope. Другое дело, что мешать RAII и goto cleanup в одном проекте - не обязательно хорошая идея. >> В Виндосе самый первый драйвер, который пишут, как правило специально >> генерит BSOD разыменовыванием NULL. ИМХО что-то в этом есть. > Мне это честно говоря не очень понятно. Я даже когда фирмвари писать > учился первое что было все же помигать светодиодиком, потом сказать hello > world в уарт например. А вот NULL отдереференсить и поймать свой > HardFault - продвинутости, точно не первая штука. Я все же пишу > код не для того чтобы он валился. Фирмварь работает где-то далеко и там ошибка страницы не так наглядна, как на живой системе. Никто не хочет, что бы что-то валилось. В 19-м веке, когда принимали мост, ставили инженеров под него и сверху пускали паровоз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #486 Ответы: #514

504. Сообщение от qsdg (ok), 28-Июн-22, 11:50	+/–
RUST -- это БЫСТРО и БЕЗОПАСНО!
Ответить | Правка | Наверх | Cообщить модератору

505. Сообщение от Аноним (505), 28-Июн-22, 12:11	+/–
> Медитируй: > > if (!(ch >= 0x0FF10 && ch <= 0x0FF19 || >       ch >= 0x0FF21 && ch <= 0x0FF3A || >       ch >= 0x0FF41 && ch <= 0x0FF5A)) Починил. У автора вашего варианта проблемы с приоритетами операторов, причём явные, раз уж он даже не знает, чей приоритет выше: логического умножения или логического сложения. А в Паскале, да, надо везде ставить скобки, как вы и написали. Да ещё и вместо &&/|| использовать and/or.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267

506. Сообщение от Аноним (506), 28-Июн-22, 17:05	+/–
> Одна из самых известных проблем, ради которой какие только костыли ни придумывали > — и "сравнение наоборот" (`2 == x` вместо `x == 2`), Вообще-то... 1) Проблема в том что сравнение было похоже на присвоение и очевидное типо вело к факапу. На момент десигна сей такой статистики не было и это еще можно понять. А потом, вот, зная типовость граблины заворкэраундили. Сколько такого в хрусте мы узнаем... потом. 2) Эта проблема в хрусте пролечена скорее уж кейвордом let, явно сделанным из подобных соображений. 3) Паскалисты делали это лучше своим :=, меньше кноп жать (2 vs 4). Просер вдвое паскалю, вчетверо сям. 4) Обругать другой яп так себе аргумент за стройность яп... :) > и дополнительные скобки и чего только не придумывали. А всё что > нужно — чтобы присваивание не возвращало значения. Когда 2 = x, это ошибка, ибо константе пытаются что-то присвоить, совершенно невалидно. Но к вон тому случаю относится достаточно косвенно. > Потому что `(10, 20)` — это и есть тупл. В моем примере это лишь визуальное выделение, return 10, 20; ничем не хуже. Туплы все же какая-то отдельная сущность и если цель вернуть пару параметров без заморочек, выглядит каким-то оверкилом. А для наворотов и так struct были. В чем их пойнт вообще? > Поэтому `-> (i32, i16)`. Ну да, однако декларим вход мы все же несколько иначе и получается как-то кособоко. > Но при вызове функции эти имена теряются, нельзя позвать `area(width: 1, height: 2)`. Да и хрен с ним, имхо. Если кто ну вот реально именно это хотел (параметров дофига?), ему, наверное, все же struct'ы хотелось на самом деле. > С возвращаемым значением наоборот — при вызове можно поименовать компоненты > тупла: `let (width, height) = function();`, а в сигнатуре функции они безимянные. И получается, блин, опять не симметрично. > Автореференс делается в одной, строго оговорённой ситуации. Есть один реальный кейс, где > это реально выливается в неприятную штуку, но тут просто нет решения > лучше, нет альтернативы. Это еще в принципе хрен с ним, всего не предусмотришь. Мое опасение здесь что когда в 1 случае автоматика есть а в другом нет, это может привести к багам когда кодер это пробакланит. > Смысл в том, что это не учебник программирования. Вообще-то это именно "учебник программирования на Rust" судя по виду. > Ну и в чём проблема-то? На самом деле - в стандартах сей и как они написаны. Бывает так что люди срезают угол, экономя себе силы там, где это делать было вообще совсем нельзя. Это именно тот случай. > Они даже близко не стоят по степени готовности. Says who? Адепт яп который сабж может чуть ли не только в ночнушках? :) > Без зависимых типов это всё паллиатив, мёртвому припарка. Но в Rust такое > можно сделать, без проблем. Только ерунда это. Это не ерунда, это какие-то азы контрактов, чтоли, без полномасштабного залета на это. Вы правильно поняли, все хотят и рыбку съесть и косточкой не подавиться. > Непонятно что с этим ворнингом дальше делать. 1) Там где это реально важно (safety-critical, security, reliability) и стандарты кодинга строгие, -Werror. 2) Остальным популярно рассказать фу такими быть, типа как с unsafe. Если уж кто воткнул подобие контракта то наверное имел в виду что это должно быть так. > Только затыкать, но тогда это некорректный ворнинг получается, такому ворнингу > в компиляторе не место, он как минимум в линтере должен быть, Если так рассуждать, warning'ам вообще в компиляторе не место. Некоторые разделяют эту точку зрения и как минимум в сях и плюсах практикуют -Wall -Werror. Что так то очень на пользу качеству кода и отлову левых ситуаций. > статическом анализаторе. Но полноценный статический анализатор и без явного типа-диапазона > может провести доказательство, что в нужном месте паника не возникает. Вот это ну не факт. Если я моим кодом генеряю вход - может быть. А если я это с ADC прочел? Ну, докажи что он мне может дать и не может. И вот в этом случае было бы айс получить варнинг или еррор, поскольку кодер, очевидно, облажался. > Я не знаю кем такое предполагается. Учебник — это совсем другая книга, > другой жанр. Например, не может быть учебника без задач. В принципе они могли бы добавить и это, кмк похрустеть немного мозгом их аудитории было бы полезно :) > Не могу тут ничего сказать. Не знаю. Но, например, монотонное время в > наносекундах в u64 не влезает. Могу себе представить что будет если кто hi-res время в u128 начнет безбашенно считать. Там у линуксоидов и так прикол был что на часы зырить довольно дорогая операция, а если ее еще этим обвесить... :))) > Так, в линуксах `timespec` состоит из 64-битных секунд и 32-битных наносекунд, > так что если пытаться упаковать это в одно число, то нужно u128. Технически вон то занимает 96 битов в памяти. Это меньше. Переполнение оных происходить не обязано. А u128 это не только 2 64-бит регистра но и совершенно точно мастхэв кода который их переполнение ворочает. Это может и спасет от каких-то багов но может урыть перфоманс. > Но это, конечно, слабый аргумент. Ну хоть какой-то, я и на это не рассчитывал :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #502

507. Сообщение от torvn77 (ok), 29-Июн-22, 01:36	+/–
Я имею ввиду всякие ошибки когда пишут не туда и затирают не то, там ведь могут быть люди которые начнут использовать указатели вообще не понимая что это такое, просто для получения эффекта надо так то написать и поставить *.   Так что БСОД это самое малое что они могут учинить... И объявлять этот БСОД будет точно не их драйвер(это если успеет объявить до фактического развала)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #395

508. Сообщение от burjui (ok), 29-Июн-22, 02:05	+/–
Вы так и не привели ни одного примера "новых классов уязвимостей", которые якобы привнесёт именно Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #499 Ответы: #522

509. Сообщение от Аноним (509), 29-Июн-22, 11:21	+/–
Многословность легко решается редактором/IDE с нормальным автодополнением и сниппетами. Плюс код читается чаще, чем пишется, так что тут от многословности только польза.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151 Ответы: #519

510. Сообщение от Аноним (509), 29-Июн-22, 11:33	+/–
В плюсовом? Да примерно всё, если взять не самый простой для парсинга синтаксис C (потому что контекстно-зависимый и не всегда однозначный), щедро обмазать абсолютно ортогональным синтаксисом темплейтов, а сверху ляпнуть новых фич C++11 и далее, с, как обычно, изобретённым заново синтаксисом для конструкций - вряд ли найдутся люди, которые осознанно и добровольно будут на нём писать и не плеваться. "Синтаксис не важен!", скажут многие, окей, если синтаксис неважен, то почему его нельзя было сделать проще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #398

511. Сообщение от Аноним (509), 29-Июн-22, 11:36	+/–
Пока в Вилларибе дрочат на такты и дебажат код в поисках мемори лика, в Виллабаджо уже завезли многопроцессорность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #364 Ответы: #521

512. Сообщение от Аноним (509), 29-Июн-22, 11:44	+/–
>When I first started using Zig, I was dismayed that it was missing so many features that I liked from other languages. No syntax for ranges. No closures. No iterator syntax. > However, I ended up finding these absences liberating — this is where the “fun” comes in. как бы это странно ни звучало, но fun для такого проекта, как Linux в наше время неприемлем. Хотя вот это > Focus on debugging your application rather than debugging your programming language knowledge. мне по душе (хотя я и не считаю, что в Zig-е такой уж удачный синтаксис)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #494

513. Сообщение от Fedd (ok), 29-Июн-22, 13:11	+/–
Смотрю местные анонимусы потихоньку переобуваются топить за раст, как и следовало ожидать
Ответить | Правка | Наверх | Cообщить модератору

514. Сообщение от Аноним (-), 29-Июн-22, 21:56	+/–
> В смысле, что Окно Овертона открывается постепенно. Безопасность же. И я бы сказал что с 70х прошлого века некоторые реалии и правда изменились, _некий_ валидный пойнт я распознаю. > За безопасность так или иначе приходится платить. Обяжут. Безопасность мне и самому нравится. А насчет обяжут КМК если и будет то не скоро. Загадывать на ...цать лет вперед - может к тому моменту хрустики задолбаются, или очередной убийца хруста его дожмет, а может и лину(к)са уделает кто-то новый. На такие сроки я загадывать не готов. > Сейчас ломается традиция писать Linux на Си. Си хорошая штука но тоже со своими приколами. А навсегда утыкаться в state of art 70х без учета новых данных и идей тоже как-то так себе. Поэтому логично иногда опробовать иные опции. Плюсеров понесло куда-то не туда и системный яп из них точно не получился, зело уж сложные отношения у их нечто с рантаймом, стартапом и прочим. D может и имел шансы но жаба производителя компилера все про#$T%ла. А кто еще? А, убийцы раста на 90% слизаные с раста? :) > Именно это много лет как решает Си++ с std::unique_ptr. 1) В ядре/бутлоадере/фирмвари и т.п. в общем случае НЕТ stdlib. Хрустики с этим тоже откушали, но, вроде, частично замахали. 2) В лучшем случае там есть что-то свое. Сильно кастомное. И для C++ это имеет свойство выглядеть весьма мерзотно и нетривиально и делаться хтонически криво. У него сложные отношения с ABI, стартапом, рантаймом и прочим. В кастомных окружениях та еще порнография. 3) Дебаг и аби плюсоты и все такое - очень так себе радость. Если хрустики смогут лучше чем это - получат памятник при жизни. И мне похрен как оно в виндусе и вьюжлстудии, скажем прямо. 4) Хруст таки придумал довольно наглый чит по части безопасности памяти когда им в частном случае вроде удалось и рыбку схесть и на ... сесть с их borrow checker'ом. 5) Типы данных в плюсах и UB не намного лучше сей. В хрусте этим все же больше заморочились. Так что выбирая прогать системщину на плюсоте или хрусте я еще дважды подумаю. У хрустиков хватило ума на нормальные целочисленные типы так как они должны быть в системщине (кроме u128 в обязаловку) и борьбу с UB. > И я видел proposal в ISO/IEC 9899 на тему автоматического вызова функции очистки при > выходе из scope. Оно может даже и не есть плохо, но в сях и плюсах объективно есть вещи которые стоило бы переделать или депрекейтнуть к хренам. Например я искренне ненавижу "классические" типы целых. Так по уродски их и тоникие моменты задефайнить еще суметь надо было. А сейчас на память об этом нам легион вулнов и тупых багов вокруг integer overflow. Даже гранды иногда фекалий откушивают. Лично видел. > Другое дело, что мешать RAII и goto cleanup в одном проекте - не обязательно хорошая идея. Определенно. И механизм типа exceptions в кернеле - очень спорный бенефит. В том плане что там допущения сильно другие чем в приложухах. Ядро не может просто сдохнуть при ауте памяти, даже для себя любимого. А механизм рекавери... вообще хрустики с этим тоже покушали и интересно посмотреть как оно им будет. > Фирмварь работает где-то далеко У меня она "на кончиках пальцев". Вон, в терминалке со мной через подобие ROM-монитора чатится. Накодив работу с шаговиком - погонять его интерактивно туда-сюда с разными скоростями и числами шагов было намного прикольнее любых бсодов. Управление шаговиком в стиле Quake с клавы? > и там ошибка страницы не так наглядна, как на живой системе. Там нет страниц, поэтому нет и ошибок страниц. И вы же не думаете что я буду ронять себе основную систему при ядерных экспериментах? Это сейчас все нормальные люди в виртуалках делают. Там даже если ядро совсем помре, out of band дебагер qemu туда все же пролезет. Вообще сие фирмварщики и железячники первые придумали с JTAGом, но потом и ядерщикам так захотелось, что они, не люди? На х86 так можно но у него это сложно и уродливо, виртуальная версия этого - проще заводится. > Никто не хочет, что бы что-то валилось. В 19-м веке, когда принимали мост, > ставили инженеров под него и сверху пускали паровоз. Мне эта идея нравится и я хочу дойти до состояния когда я реально не зассу полагаться на мои фирмвари даже зная что их отказы могут меня угробить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #503 Ответы: #515

515. Сообщение от n00by (ok), 30-Июн-22, 09:45	+/–
>> Сейчас ломается традиция писать Linux на Си. > Си хорошая штука но тоже со своими приколами. А навсегда утыкаться в > state of art 70х без учета новых данных и идей тоже > как-то так себе. Поэтому логично иногда опробовать иные опции. > Плюсеров понесло куда-то не туда и системный яп из них точно не > получился, зело уж сложные отношения у их нечто с рантаймом, стартапом > и прочим. Нет там рантайма, если разобраться и написать свой.) Диспетчер исключений это аналог setjmp.h. Статические конструкторы это аналог __init. typeinfo не обязательно использовать, да и реализация уложится в сотню строк. >> Именно это много лет как решает Си++ с std::unique_ptr. > 1) В ядре/бутлоадере/фирмвари и т.п. в общем случае НЕТ stdlib. unique_ptr не требует что-либо из "рантайма". Упрощённо можно считать, что перед скобкой } транслятор вставляет free(ptr); >> Фирмварь работает где-то далеко > У меня она "на кончиках пальцев". Вон, в терминалке со мной через > подобие ROM-монитора чатится. Накодив работу с шаговиком - погонять его интерактивно > туда-сюда с разными скоростями и числами шагов было намного прикольнее любых > бсодов. Управление шаговиком в стиле Quake с клавы? Ну нет смысла её ронять, в отличие от живой сиситемы, по по пальцам она не ударит и рефлекс не выработается. >> и там ошибка страницы не так наглядна, как на живой системе. > Там нет страниц, поэтому нет и ошибок страниц. И вы же не > думаете что я буду ронять себе основную систему при ядерных экспериментах? > Это сейчас все нормальные люди в виртуалках делают. На эту тему есть анекдот: - почему ты забыл префикс lock? - у меня на вируталке и так работает! >> Никто не хочет, что бы что-то валилось. В 19-м веке, когда принимали мост, >> ставили инженеров под него и сверху пускали паровоз. > Мне эта идея нравится и я хочу дойти до состояния когда я > реально не зассу полагаться на мои фирмвари даже зная что их > отказы могут меня угробить. А просто надо не ссать. Опыт приходит сразу после того как был нужен. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #514 Ответы: #518

516. Сообщение от adolfus (ok), 30-Июн-22, 17:02	+/–
\cite{... избавленные от таких проблем как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера. } Не очень понятно, зачем все это перечисленное делать. Когда колбасу режем, пальцы же себе не отфуячиваем, так почему так аккуратно и программы не писать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #517

517. Сообщение от Ананимус (?), 30-Июн-22, 17:20	+1 +/–
> \cite{... избавленные от таких проблем как обращение к области памяти после её > освобождения, разыменование нулевых указателей и выход за границы буфера. > } > Не очень понятно, зачем все это перечисленное делать. > Когда колбасу режем, пальцы же себе не отфуячиваем, так почему так аккуратно > и программы не писать? У тебя проводка дома без изоляции лежит? Нет? А чо ты как лох, изоляция для слабаков которые не смотрят под ноги.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #516 Ответы: #524

518. Сообщение от Аноним (-), 30-Июн-22, 23:51	+/–
> Нет там рантайма, если разобраться и написать свой.) Я так понимаю что хрустики именно таким и занялись, модуляризацией стдлиб и проч и альтернативными версиями там где "обычное" не катит. Хинт: если я хотел драйвер накодить, не факт что я хотел еще и то кодить сам, может весь кернел еще? > Диспетчер исключений это аналог setjmp.h. Я не уверен что в ядре исключения хорошая идея. И хрустиковая паника тоже. Ну вот допустим у нас не получилось выделить память а падать не хотим. Вместо этого хотим попозже попытаться опять. Но исключения и паника это не обеспечат. Торвальц хрустикам популярно донес, до них дошло вроде. И будет у них там более сиобразный стиль... ))) > Статические конструкторы это аналог __init. Этот __init что и где? В сях его быть не обязано, технически гнутый тулчайн оперирует entry (с любым названием). Его вызывают (кто и почему отдельный вопрос), а дальше - теоретически, там должен быть стартап, который нормальную сишную арену соберет. В стандартной программе потом main вызовет. Может быть и что-то еще, тогда это окружение отличается от стандартного си по свойствам. Сам компилер в freestanding режиме как максимум может хотеть 3 функции, это 100% документировано: memcpy, memset и memmove. Вот их он реально иногда сам втыкает при кодогенерации. У плюсоы все сильно разлапистее, конечно. > typeinfo не обязательно использовать, да и реализация уложится в сотню строк. Сама программная модель исключений неважно ложится на то что может реально хотеть делать кернел. Наверное можно натянуть сову на глобус но хрустики ... пошли по пути пробитому сишниками как я понял. Т.е. накодили костыль для box и т.п. который таки может FAILить без вских паник и это надо чекать в откровенно севом стиле. > unique_ptr не требует что-либо из "рантайма". Упрощённо можно считать, что перед скобкой > } транслятор вставляет free(ptr); Круто, кроме того что alloc/free изначально тоже нет. Их как максимум можно себе создать. Фирмвари могут на это забить ("static memory allocation"). Ядро это делает, но у него несколько кастомных функций такого плана под специфику. А вот "транслятор вставляет" означает что при случае можно будет огрести грабель. > Ну нет смысла её ронять, в отличие от живой сиситемы, по по > пальцам она не ударит и рефлекс не выработается. Ждать пока упадет мой код можно долго. Мой МКшный код обычно не падает никогда и никак, ибо я читал определенные guidelines и выводы сделал. Но как мне узнать что handler вообще делает то что там задумано? Пришлось накодить искусственную провокацию, посмотреть на реакцию вообще. Не ждать же годами пока шальная частица подобьет мне проц? > - почему ты забыл префикс lock? > - у меня на вируталке и так работает! А таки я активно VM юзаю, ядерщики тоже, и это сильно упрощает многие вещи. И разницы с VM и железом обычно минимум. Во всяком случае в qemu и линукскернелом. Как оно там у вас в чем там у вас я понятия не имею. Я даже образа ARMовых систем отстраиваю на VM которая кросс-транслирует x86 <-> arm, это неспешно, но позволяет сделать образ даже когда железки еще в руках нету. SYZBOT штука довольно крутая кст, дофига багов робот репортит. Или вон скрипт autobisect кернела в qemu, круто, чо. Почти-сам ловит бажный комит если удалось pass/fail программно сформулировать. Для вас это поди космические технологии? > А просто надо не ссать. Опыт приходит сразу после того как был нужен. :) Так в случае МК в ящик сыграть можно, или угробить кого-то. Поэтому я предпочитаю постепенно двигаться: по мере прокачки скилла и появления ощущения что я контролирую ситуацию я позволяю себе несколько более требовательные применения. Сейчас я развлекаюсь с power electronics с программным управлением. При фэйле никто не умрет, но серьезный фэйл достаточно заметен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #515 Ответы: #526

519. Сообщение от Аноним (-), 01-Июл-22, 00:01	+/–
Автодополнение видите ли может и ложно сработать, что так то тоже бесит. И это, визуально код с парными скобками и форматированием схватывается лучше чем какой-то текст begin-end который к тому же - цуко - разной длины, что как бы FAIL т.к. блоки кода косые малость получаются. И это не круто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #509

520. Сообщение от Аноним (-), 01-Июл-22, 00:09	+/–
> Так я описал худший случай, поскольку отвечал на: "Обязательная инициализация означает > необходимость тратить время процессора и память на ненужную оптимизацию переменных". Не уверен что это настолько уж масштабная проблема. > Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет > прочитана), а потом кеш скидывается в ОЗУ. А если нет записи, > тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе > придётся ждать. У нормальных людей инициализация переменных не настолько частая чтобы это было проблемой. Более того - при генерации кода компилер вообще может целиком заинлайнить все. При том возможно что 90% нужного уже было в других регистрах. А с каким-нибудь LTO зависимость вообще нелинейная. Иногда казалось бы более плохой код генерит более короткий и резвый код. В чем прикол? А вон там глобальному оптимизатору константы лучше легли. С ним вообще приходится эмпирически, на конкретном коде подбирать :). Но он круто лишнее выпиливает. Может треть кода аннулировать без какого либо изменения скорости или логики. И вот тут оно стоит того чтобы погреть проц при компиле, как минимум релизной версии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #457 Ответы: #527

521. Сообщение от Аноним (-), 01-Июл-22, 00:10	+/–
> Пока в Вилларибе дрочат на такты и дебажат код в поисках мемори > лика, в Виллабаджо уже завезли многопроцессорность. Если ты так развлечешься в кернеле, вероятно, ты еще и не так потом будешь др@чить в дебаге внезапно падающего кернела.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #511

522. Сообщение от Аноним (-), 01-Июл-22, 00:13	+/–
> Вы так и не привели ни одного примера "новых классов уязвимостей", которые > якобы привнесёт именно Rust. Кодер подумал что безопасТно и забил на использование мозга. Маркетологи гамадрила корп сказали же что безопасТно!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #508 Ответы: #525

523. Сообщение от Аноним (-), 01-Июл-22, 00:20	+/–
>    - сборочная система Лизать ботинки гугла, амазона и майкрософт с их Единственно Правильной Экосистемой - вообще баг а не фича. >    - легкий update компилятора Безопасным curl | sh? :) Где ремотным джентльменам верят на слово. >    - пакетная система с автоподгрузкой из сетки by demand > в процессе сборки Очень безопасно и совсем не лижет корпоративные ботинки упомянутой троицы. И совсем не разводит левый мусор в системе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #376

524. Сообщение от Аноним (-), 01-Июл-22, 00:23	+/–
> У тебя проводка дома без изоляции лежит? Нет? А чо ты как > лох, изоляция для слабаков которые не смотрят под ноги. Однако хватает и проводов без изоляции. Контактный рельс метро не очень заизолируешь на все сто. И вон ту высоковольтку - тоже. Слой изоляции больно уж непотребный надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #517 Ответы: #528

525. Сообщение от burjui (ok), 01-Июл-22, 00:51	+/–
Зато голословно заявлять про какие-то мифические "новые классы" (что мля?) уязвимостей - это явный признак полного использования мозга. Жаль только, что мозг используется, а результат такой, как будто нет - получается, энергия расходуется впустую. "безопасТно", "гамадрила корп" и прочие "хрусты" - это всё, на что способен мозг типичного хейтерка с Опеннета, потому что он ещё не окончил школу, но зато уделал одноклассников на уроках информатики своими обширными познаниями в разработке на Turbo Pascal и C, на котором он не делает ошибок, потому что ничего не пишет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #522 Ответы: #531

526. Сообщение от n00by (ok), 01-Июл-22, 10:18	+/–
>> Диспетчер исключений это аналог setjmp.h. > Я не уверен что в ядре исключения хорошая идея. Потому и пишу "аналоги". Оно как бы есть по стандартам языков, но вполне можно без него. > И хрустиковая паника > тоже. Ну вот допустим у нас не получилось выделить память а > падать не хотим. Вместо этого хотим попозже попытаться опять. Но исключения > и паника это не обеспечат. В Си++ это всё делается с помощью placement new, либо точно так же как и в Си. > Торвальц хрустикам популярно донес, до них > дошло вроде. И будет у них там более сиобразный стиль... ))) Только в другом синтаксисе. >> Статические конструкторы это аналог __init. > Этот __init что и где? В сях его быть не обязано, технически > гнутый тулчайн оперирует entry (с любым названием). Этот __init можно найти в коде ядра. Точно так и статические экземпляры не обязательно создавать. > Его вызывают (кто и > почему отдельный вопрос), а дальше - теоретически, там должен быть стартап, > который нормальную сишную арену соберет. В стандартной программе потом main вызовет. > Может быть и что-то еще, тогда это окружение отличается от стандартного > си по свойствам. Сам компилер в freestanding режиме как максимум может > хотеть 3 функции, это 100% документировано: memcpy, memset и memmove. Вот > их он реально иногда сам втыкает при кодогенерации. У плюсоы все > сильно разлапистее, конечно. У меня это всё практически написано в виде работающего кода. Потому я могу утверждать, что мнение "сильно разлапистее" является предрассудком, в лучшем случае после знакомства с жирными реализациями. Это примерно как сказать "Си не годится в ядро, поскольку glibc много весит". ;) >> unique_ptr не требует что-либо из "рантайма". Упрощённо можно считать, что перед скобкой >> } транслятор вставляет free(ptr); > Круто, кроме того что alloc/free изначально тоже нет. Их как максимум можно > себе создать. Потому и написано "упрощенно". Вызывается заданная программистом функций. >> - почему ты забыл префикс lock? >> - у меня на вируталке и так работает! > А таки я активно VM юзаю, ядерщики тоже, и это сильно упрощает > многие вещи. И разницы с VM и железом обычно минимум. Да, "обычно минимум". То есть разница есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #518

527. Сообщение от n00by (ok), 01-Июл-22, 10:28	+/–
>> Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет >> прочитана), а потом кеш скидывается в ОЗУ. А если нет записи, >> тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе >> придётся ждать. > У нормальных людей инициализация переменных не настолько частая чтобы это было проблемой. Это всё субъективно. Вон то про кеш - оно не зависит от наших убеждений. То есть инициализация переменных оправдана, как оптимизация по скорости. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #520

528. Сообщение от Ананимус (?), 01-Июл-22, 18:44	+/–
> Однако хватает и проводов без изоляции. Контактный рельс метро не очень заизолируешь на все сто Поэтому там регулярно люди и умирают :))))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #524

529. Сообщение от bOOster (ok), 04-Июл-22, 12:12	+/–
Конечно, лучшая часть человечества совершенствует себя, а худшая совершенствует механизмы сопутствующие лени и ничего не деланию. Все реально видят куда это идет и даже фильмы снимают, про катострофически отупeвшее человечество. А вообще, конечно, каждый должен заниматься своим делом, нет наклонностей к программированию, не можешь элементарные "загибы" алгоритма просчитать катись в другую отрасль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #368

531. Сообщение от Аноним (531), 05-Окт-22, 17:49	+/–
Не голословно. Для GNU/Linux придется использовать этот компилятор Rust: https://www.opennet.ru/opennews/art.shtml?num=57491 стандартный компилятор добавит новые классы уязвимостей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #525

532. Сообщение от Аноним (532), 06-Окт-22, 13:05	–1 +/–
> Потому что на Rust приятно писать код. Ну ты и Петросян!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #328 Ответы: #533

533. Сообщение от warlock66613 (ok), 07-Окт-22, 19:12	+/–
Я понимаю, что хаскелистам смешно, да. Но мне на Rust приятнее во всех отношениях и проще. Хотя Хаскелл в чём-то удобнее, я согласен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #532

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

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