The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход/выход
слежка
RSS


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

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

Подробнее: https://www.opennet.me/opennews/art.shtml?num=57391

Ответить | Правка | Cообщить модератору

Оглавление

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


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

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

6. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +16 +/–
Сообщение от Аноним (6), 22-Июн-22, 09:41 
Вряд ли он страдает юношеским максимализмом, тем более в его-то возрасте.
Ответить | Правка | Наверх | Cообщить модератору

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

84. Скрыто модератором  +/–
Сообщение от Бывалый смузихлёб (?), 22-Июн-22, 12:41 
Ответить | Правка | Наверх | Cообщить модератору

110. Скрыто модератором  +8 +/–
Сообщение от hgdslvodf (?), 22-Июн-22, 13:17 
Ответить | Правка | Наверх | Cообщить модератору

123. Скрыто модератором  +2 +/–
Сообщение от Аноним (123), 22-Июн-22, 14:14 
Ответить | Правка | Наверх | Cообщить модератору

133. Скрыто модератором  +/–
Сообщение от rshadow (ok), 22-Июн-22, 14:35 
Ответить | Правка | Наверх | Cообщить модератору

140. Скрыто модератором  +2 +/–
Сообщение от Аноним (123), 22-Июн-22, 14:49 
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

11. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Fracta1L (ok), 22-Июн-22, 09:45 
Москва не сразу строилась
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

46. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +3 +/–
Сообщение от Аноним (46), 22-Июн-22, 11:54 
к счастью, не на расте.
Ответить | Правка | Наверх | Cообщить модератору

53. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –1 +/–
Сообщение от Аноним (123), 22-Июн-22, 12:07 
На чём-то вроде бейсика.
Ответить | Правка | Наверх | Cообщить модератору

100. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (120), 22-Июн-22, 13:00 
На Бедоне же. Вот как разрослась-то!
Ответить | Правка | Наверх | Cообщить модератору

441. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:51 
> На Бедоне же. Вот как разрослась-то!

А что, архитектура улиц и транспорта - как будто питонист макет делал. Но это примерно как с питонным битторентом: да, истошный кал, но тогда по другому и не умели же!

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

33. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –2 +/–
Сообщение от Fracta1L (ok), 22-Июн-22, 11:06 
Когда?
Ответить | Правка | Наверх | Cообщить модератору

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

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

Почему нельзя было сделать "безопасное написание драйверов" на другом языке программирования?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

116. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Fracta1L (ok), 22-Июн-22, 13:26 
Шта
Ответить | Правка | Наверх | Cообщить модератору

125. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +2 +/–
Сообщение от torvn77 (ok), 22-Июн-22, 14:22 
Ну безопасное написание драйверов ламерами это объективная реальность, потому что никто кроме них не будет писать драйвер для девайса который купили полтора человека и сделать для них загончик где они бы бсодили только свой драйвер нужно и полезно.  

Но почему для этого загончика выбран инструмент с лицензией имеющей потенциальную опасность вендорлока?  

Свои проприетарные системы комманд никто не сможет и не будет делать?  
Как тут хорошо вспомнить о открытом процессоре RISC V в который как раз можно ставить свои расширения команд.  
Я не знаю какая у него лицензия, но мой нос чувствует приближение жопы.

Ответить | Правка | Наверх | Cообщить модератору

131. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Fracta1L (ok), 22-Июн-22, 14:34 
Шизофазия
Ответить | Правка | Наверх | Cообщить модератору

135. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (135), 22-Июн-22, 14:37 
>> почему для этого загончика выбран инструмент с лицензией имеющей потенциальную опасность вендорлока

Так уже вендерлок во всё ведро)
Форкни системду например

Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

426. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:26 
> Форкни системду например

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

Ответить | Правка | Наверх | Cообщить модератору

395. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 25-Июн-22, 16:12 
> Ну безопасное написание драйверов ламерами это объективная реальность, потому что никто
> кроме них не будет писать драйвер для девайса который купили полтора
> человека и сделать для них загончик где они бы бсодили только
> свой драйвер нужно и полезно.

Вообще-то бсодить ядро очень так себе идея. И Торвальдс очень популярно высказался что он про panic() при всяких нехватках памяти и проч думает.

Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

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

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

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

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

425. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:24 
> ну так лет пять убивать будут эт точно, а там и фуксия
> подоспеет. то же самое, что с файрфокс произошло - как по
> нотам с теми же действующими лицами

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

Ответить | Правка | Наверх | Cообщить модератору

396. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 25-Июн-22, 16:13 
> Дяди из Linux Foundation решили окончательно убить Linux как Mozilla убивает Firefox.
> Примечательно, что тоже переписыванием на Rust. Потом окончательно переведут всех на
> какое-то несвободное ПО вроде Fuchsia с тивоизацией.

Всех это кого? Хомячков на андроиде? У них и так линукс довольно паршивенький, с блоботой и троянами, сливащий телеметрию. А, и секурбут конечно. Кто сказал что линукс так не может?

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

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

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

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

13. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –2 +/–
Сообщение от Fracta1L (ok), 22-Июн-22, 09:46 
> плюсы тоже умеют это, если ручку приложить

Если ручку приложить - можно из буханки хлеба сделать троллейбус, только зачем

Ответить | Правка | Наверх | Cообщить модератору

63. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (58), 22-Июн-22, 12:15 
HaikuOS полностью написана на с++ и вот-вот нагнёт ваш линукс на десктопах!
Ответить | Правка | Наверх | Cообщить модератору

73. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +5 +/–
Сообщение от Fracta1L (ok), 22-Июн-22, 12:24 
С РеактОСом вместе)
Ответить | Правка | Наверх | Cообщить модератору

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

102. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +2 +/–
Сообщение от Аноним (58), 22-Июн-22, 13:04 
Это KolibriOS
Ответить | Правка | Наверх | Cообщить модератору

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

137. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –1 +/–
Сообщение от Аноним (138), 22-Июн-22, 14:40 
>на нормальном языке
>C++

Чел...
Одно в гайке хорошо - она работает и неплохо выглядит.

Ответить | Правка | Наверх | Cообщить модератору

205. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от torvn77 (ok), 22-Июн-22, 21:42 
>Одно в гайке хорошо - она работает и неплохо выглядит.  

Посмотрел, она девушка лёгкого поведения(MIT), так что в жёны я её несмотря на красоту не буду.

Ответить | Правка | Наверх | Cообщить модератору

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

161. "гонишь"  +1 +/–
Сообщение от Тычок (?), 22-Июн-22, 16:43 
$ 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
---------------------------------------------------------------------------------------
Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

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

79. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +2 +/–
Сообщение от Аноним (46), 22-Июн-22, 12:35 
> на Rust даже голову прикладывать ненужно

Оно и видно, как падал FF.

Ответить | Правка | Наверх | Cообщить модератору

87. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Бывалый смузихлёб (?), 22-Июн-22, 12:44 
> просто дядька невзлюбил плюсы

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

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

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

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

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

105. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +4 +/–
Сообщение от НяшМяш (ok), 22-Июн-22, 13:14 
> Так в C++ Exception и это богомерзко и нельзя.

Эппл, например, в IOKit взяли и просто запретили исключения и ещё пару вещей.

Ответить | Правка | Наверх | Cообщить модератору

20. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +5 +/–
Сообщение от freehckemail (ok), 22-Июн-22, 09:54 
> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++?

Потому что Линус в гробу видал C++. Его потом дебажить замучаешься. И сломается в самый неподходящий момент. А это ядро.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

60. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (120), 22-Июн-22, 12:14 
Так может на OCaml?
Ответить | Правка | Наверх | Cообщить модератору

195. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от freehckemail (ok), 22-Июн-22, 20:06 
> Так может на OCaml?

Так уже есть Mirage.

Ответить | Правка | Наверх | Cообщить модератору

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

106. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +3 +/–
Сообщение от НяшМяш (ok), 22-Июн-22, 13:14 
Сколько в нём драйверов и архитектур есть?
Ответить | Правка | Наверх | Cообщить модератору

118. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (120), 22-Июн-22, 13:49 
Ну для RISC-V64 портировали, вроде.
Ответить | Правка | Наверх | Cообщить модератору

462. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –1 +/–
Сообщение от Аноним (-), 26-Июн-22, 15:29 
> Ну для RISC-V64 портировали, вроде.

И на скольких железках оно реально взлетает? И хотя-бы вафлю с вон того usb свистка оно зацепит при этом? Или тем более какого-нибудь модуля, ктулху упаси, на SDIO каком? Это линукс то если в свежей версии цепляет и не очень глючит - уже за счастье.

Ну и операционка с неотрываемым гуем на большинстве RISCV нужна как собаке пятая нога примерно.

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

273. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (138), 23-Июн-22, 13:50 
>если старья уже нет

Живи одним днём?

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

Ответить | Правка | Наверх | Cообщить модератору

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

81. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 22-Июн-22, 12:35 
>> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++?
> Потому что Линус в гробу видал C++.

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

> Его потом дебажить замучаешься. И
> сломается в самый неподходящий момент. А это ядро.

Это предрассудки. Но если люди привыкли писать на Си - вот тогда им будет сложно. Поэтому Линус не захотел ломать традицию.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

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

Ты сейчас не Линуса описываешь. Линус тебе покажет средний палец и объяснит, что у тебя в голове дepьмо. Последнее, чем он будет заниматься, это писать то, что ты от него хочешь услышать. =)

Ответить | Правка | Наверх | Cообщить модератору

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

Это ты сейчас отвечаешь не на мой комментарий, а на какой-то выдуманный. Я не пишу ядро Lunux, потому не вхожу в множество людей, чьи интересы Линус учитывает. Что касается пальцев - Микрософт показывал мне однажды, официально заявляя, что Си++ невозможно у них в ядре. Но оказалось возможно. Так что и палец Линуса не оказал бы воздействия. Другое дело, что Си++ _не_нужно_ в дереве исходников ядра Linux.

Ответить | Правка | Наверх | Cообщить модератору

253. "YOU are full of Bullshit!"  –1 +/–
Сообщение от freehckemail (ok), 23-Июн-22, 10:34 
Ты не понял ничего.
Ответить | Правка | Наверх | Cообщить модератору

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

429. "YOU are full of Bullshit!"  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:29 
> Я _сделал_ когда-то то, чем ныне заняты растоманы.

Это, например, что? Прислал патчи с поддержкой другого яп в майнлайн? Да ну?! :)

Ответить | Правка | Наверх | Cообщить модератору

443. "YOU are full of Bullshit!"  +/–
Сообщение от n00by (ok), 26-Июн-22, 12:58 
>> Я _сделал_ когда-то то, чем ныне заняты растоманы.
> Это, например, что? Прислал патчи с поддержкой другого яп в майнлайн? Да
> ну?! :)

Вот в этом-то вся и соль. Зачем они хотят в майнлайн? Якобы, что бы писать драйвера на Rust. Когда мне понадобился Си++ в ядре Виндовс, я не слал в Микрософт письма с вопросами по компилятору, а просто сел и начал писать, дальше люди помогли. При этом "сишники" никак не мешали, поскольку не было походов со своим уставом в чужой монастырь. В итоге оно заработало (при этом драйвер работал гораздо раньше, чем появилась поддержка исключений, которая в ядре нужна не очень, но помогала не писать тесты, а брать готовые). У растоманов уже есть какой-то драйвер, или только вот этот процесс внедрения?

Ответить | Правка | Наверх | Cообщить модератору

463. "YOU are full of Bullshit!"  +1 +/–
Сообщение от Аноним (-), 26-Июн-22, 15:40 
> Вот в этом-то вся и соль. Зачем они хотят в майнлайн? Якобы,
> что бы писать драйвера на Rust.

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

> Когда мне понадобился Си++ в ядре Виндовс, я не слал в Микрософт письма с вопросами по
> компилятору, а просто сел и начал писать, дальше люди помогли.

С майкрософтом кооперация и коллаборация по сути невозможны. Я проверял. Это вообще совсем другие экосистемы и подходы и с точки зрения R&D это вообще-то их баг а не фича.

В лучшем случае за майками можно выгрести их фекальи. В хучшем вы там %$^тесь как хотите и всем похрен. И на разработку кернела - так же. На его перфонмас. Фичи. И их отсутствие. Косяки. И даже откровенные баги. Гнилая экосистема и уж не ее адептам линуксоидов учить как надо. Просто сравнивая какие вещи напрягавшие меня и где удалось загасить и сколько усилий это от меня потребовало так и сяк. А майкрософт был отклассифицирован как "враждебный апстрим". И теперь "хорошо что это не у меня". Торвальдс предпочитает быть более конструктивным апстримом. И кроме всего прочего не собирается счастье к глотку саплгами заталкивать, кроме некоторых сильно принципиальных моментов, что выгодно отличает его от майкрософта, чей маркетинг практикует это с завидным постоянством.

> При этом "сишники" никак не мешали, поскольку не было походов со своим
> уставом в чужой монастырь. В итоге оно заработало (при этом драйвер
> работал гораздо раньше, чем появилась поддержка исключений, которая в ядре нужна
> не очень, но помогала не писать тесты, а брать готовые). У
> растоманов уже есть какой-то драйвер, или только вот этот процесс внедрения?

Ну так хрустикам придется интерфейситься к овердофига сишной начинки, нравится им это или нет. Никто не будет ради них все ядро переписывать да и не смогли бы в следующие цать лет. Они это или осилят или пойдут в пень, какие еще варианты есть? Если осилят, малацца, значит на хрусте можно и правда косиить под типа этакий си до кучи :)

Что до виндовых дров - я не очень в курсе что там у них, их DDK и подходы меня всегда вымораживали оверинженерностью и сложностью, и тем что без огромной и нахреннужной мне студии шагу ступить невозможно. В паре с общей враждебностью майков к ядерным девам пусть им там кто другой дрова пишет, имхо. В _моей_ системе (где я могу _моим_ ключем влепить подпись на модуль себе) такие развлечения как-то сильно проще той порнографии которую по этому поводу предлагали майки.

Ответить | Правка | Наверх | Cообщить модератору

465. "YOU are full of Bullshit!"  +/–
Сообщение от n00by (ok), 26-Июн-22, 16:19 
>> Вот в этом-то вся и соль. Зачем они хотят в майнлайн? Якобы,
>> что бы писать драйвера на Rust.
> Ну да. А что в этом пожелании такого плохого?

В желании писать - ничего плохого не вижу.

> В лине как-то
> принято с апстримом кооперироваться чтобы не усложнять себе и им жизнь
> лишний раз. Совместная работа над проблемой с двух сторон при наличии
> понимания и более-менее консенсуса с обоих сторон - эффективнее.

А вот здесь вижу смешение понятий. Если драйвера нет, что кооперировать? Потенциальную возможность?

>[оверквотинг удален]
> совсем другие экосистемы и подходы и с точки зрения R&D это
> вообще-то их баг а не фича.
> В лучшем случае за майками можно выгрести их фекальи. В хучшем вы
> там %$^тесь как хотите и всем похрен. И на разработку кернела
> - так же. На его перфонмас. Фичи. И их отсутствие. Косяки.
> И даже откровенные баги. Гнилая экосистема и уж не ее адептам
> линуксоидов учить как надо. Просто сравнивая какие вещи напрягавшие меня и
> где удалось загасить и сколько усилий это от меня потребовало так
> и сяк. А майкрософт был отклассифицирован как "враждебный апстрим". И теперь
> "хорошо что это не у меня".

Я не понял, к чему это. Они контролируют ОС, но не могут запретить использовать ЯП.

> Торвальдс предпочитает быть более конструктивным
> апстримом. И кроме всего прочего не собирается счастье к глотку саплгами
> заталкивать, кроме некоторых сильно принципиальных моментов, что выгодно отличает его
> от майкрософта, чей маркетинг практикует это с завидным постоянством.

И это не понял.

>> При этом "сишники" никак не мешали, поскольку не было походов со своим
>> уставом в чужой монастырь. В итоге оно заработало (при этом драйвер
>> работал гораздо раньше, чем появилась поддержка исключений, которая в ядре нужна
>> не очень, но помогала не писать тесты, а брать готовые). У
>> растоманов уже есть какой-то драйвер, или только вот этот процесс внедрения?
> Ну так хрустикам придется интерфейситься к овердофига сишной начинки, нравится им это
> или нет.

Это само собой разумеется. ZFS on Linux приходится, и Reiser 4 приходится.

> Никто не будет ради них все ядро переписывать да
> и не смогли бы в следующие цать лет. Они это или
> осилят или пойдут в пень, какие еще варианты есть? Если осилят,
> малацца, значит на хрусте можно и правда косиить под типа этакий
> си до кучи :)

На самом деле сишникам придётся качать сорцы на Rust, нравится им это или нет. Судя по комментариям, не всем нравится. И потом придётся смотреть патчи на Rust. И ревьювить... ну или так принимать. ;)

> Что до виндовых дров - я не очень в курсе что там
> у них, их DDK и подходы меня всегда вымораживали оверинженерностью и
> сложностью, и тем что без огромной и нахреннужной мне студии шагу
> ступить невозможно. В паре с общей враждебностью майков к ядерным девам
> пусть им там кто другой дрова пишет, имхо. В _моей_ системе
> (где я могу _моим_ ключем влепить подпись на модуль себе) такие
> развлечения как-то сильно проще той порнографии которую по этому поводу предлагали
> майки.

Ну это сейчас так всё плохо, раньше было получше, в том числе и потому что Студия не умела собирать дрова.)

Ответить | Правка | Наверх | Cообщить модератору

471. "YOU are full of Bullshit!"  +/–
Сообщение от Аноним (-), 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ообщить модератору

482. "YOU are full of Bullshit!"  +/–
Сообщение от 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ообщить модератору

486. "YOU are full of Bullshit!"  +/–
Сообщение от Аноним (-), 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 это проклятое место походу. Они почему-то мнят что их технологии такие офигенные что позволяют выкрутку рук. Поэтому все годное что случается в этом направлении стало почему-то в пингвине :). Иногда майкрософт в своей жабе походу начинает жрать свой же хвост.

Ответить | Правка | К родителю #482 | Наверх | Cообщить модератору

503. "YOU are full of Bullshit!"  +/–
Сообщение от 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-м веке, когда принимали мост, ставили инженеров под него и сверху пускали паровоз.

Ответить | Правка | К родителю #486 | Наверх | Cообщить модератору

514. "YOU are full of Bullshit!"  +/–
Сообщение от Аноним (-), 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-м веке, когда принимали мост,
> ставили инженеров под него и сверху пускали паровоз.

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

Ответить | Правка | К родителю #503 | Наверх | Cообщить модератору

515. "YOU are full of Bullshit!"  +/–
Сообщение от 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-м веке, когда принимали мост,
>> ставили инженеров под него и сверху пускали паровоз.
> Мне эта идея нравится и я хочу дойти до состояния когда я
> реально не зассу полагаться на мои фирмвари даже зная что их
> отказы могут меня угробить.

А просто надо не ссать. Опыт приходит сразу после того как был нужен. :)

Ответить | Правка | К родителю #514 | Наверх | Cообщить модератору

518. "YOU are full of Bullshit!"  +/–
Сообщение от Аноним (-), 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 с программным управлением. При фэйле никто не умрет, но серьезный фэйл достаточно заметен.

Ответить | Правка | К родителю #515 | Наверх | Cообщить модератору

526. "YOU are full of Bullshit!"  +/–
Сообщение от 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 и железом обычно минимум.

Да, "обычно минимум". То есть разница есть.

Ответить | Правка | К родителю #518 | Наверх | Cообщить модератору

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

345. "YOU are full of Bullshit!"  +/–
Сообщение от n00by (ok), 24-Июн-22, 09:04 
.
Ответить | Правка | Наверх | Cообщить модератору

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

37. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (37), 22-Июн-22, 11:25 
> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++?

Можно. Пиши, что тебе мешает-то?

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

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

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

62. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (62), 22-Июн-22, 12:15 
На C++ был BeOS: https://en.wikipedia.org/wiki/BeOS_API
Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

68. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (58), 22-Июн-22, 12:19 
И haiku!
Ответить | Правка | Наверх | Cообщить модератору

5. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +13 +/–
Сообщение от Аноним (5), 22-Июн-22, 09:40 
Всё читал смехушечки про ужасный синтаксис Rust. Потом сам столкнулся. Да даже C++ более читаемым выглядит.

fn main -> std::io::Result<()>{

Вот чем думали разработчики языка? Удобно такое набирать? Нет.

Ответить | Правка | Наверх | Cообщить модератору

8. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –24 +/–
Сообщение от Аноним (8), 22-Июн-22, 09:44 
дада, тебя забыли спросить
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

21. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (21), 22-Июн-22, 09:56 
Ладно, передумал не любить rust. Включайте в ядро.
Ответить | Правка | Наверх | Cообщить модератору

64. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (120), 22-Июн-22, 12:15 
Сначала в GCC включайте.
Ответить | Правка | Наверх | Cообщить модератору

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

93. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (120), 22-Июн-22, 12:53 
Название поменять.
Ответить | Правка | Наверх | Cообщить модератору

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

201. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +3 +/–
Сообщение от snmp agent (?), 22-Июн-22, 21:16 
GNURust
Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

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

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

36. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +2 +/–
Сообщение от warlock66613email (ok), 22-Июн-22, 11:18 
А в чём проблема, и почему неудобно? Ну и `std::` лучше убрать, импортировав `io`, тогда будет 
fn main() -> io::Result<()> {
}

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

47. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +5 +/–
Сообщение от Аноним (47), 22-Июн-22, 11:55 
Думаю проблема в этом <()>.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

257. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от InuYasha (??), 23-Июн-22, 11:19 
typedef goatse :D
Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

430. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:31 
> Думаю проблема в этом <()>.

Рыба камбала :))

Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

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

78. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +3 +/–
Сообщение от Cucumber (?), 22-Июн-22, 12:33 
Если не используется код выхода, то просто пишешь:
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...

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

141. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –2 +/–
Сообщение от Аноним (141), 22-Июн-22, 14:56 
>интересно зачем, когда есть всякие

Сорян, но у тебя со здоровьем всё хорошо? Большего бреда от любителей раста я ещё не встречал.

Ответить | Правка | Наверх | Cообщить модератору

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

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>

Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

459. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от warlock66613email (ok), 26-Июн-22, 13:47 
> Агаблин, это вместо сишного return 42. Стало проще, красивее, удобнее... </sarcasm>

Точно красивее. И удобнее, если брать не настолько синтетический пример.

И например в C вы можете сделать `return -42;`. А POSIX говорит, что код должен быть в пределах `0 ..= 255`. И вот попробуй догадайся, 1) к чему такой код приведёт, 2) зачем язык позволяет писать это.

Ответить | Правка | Наверх | Cообщить модератору

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ообщить модератору

473. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от warlock66613email (ok), 26-Июн-22, 18:29 
> вы можете вот так костыльнуть, но точку с запятой дескать вот тут ставьте а вот тут нет. Вот это я понимаю - наколень в дизайне ЯП, в отличие от сей, с оправданием что г@вно в синтаксисе так и задумано...

Это как раз одна из самых красивых вещей. Одна из тех, пр которые давно стало понятно как надо делать правильно, и вот Rust (не считая, конечно, Haskell и т.п.) наконец воплотил.

> оно может из функции несколько параметро вернуть кроме как struct'ом каким?

Туплом.

> почему имена нельзя назначать на выход? Они решили сделать все это вообще так же педальненько как в сях?

Так и на вход нельзя. Симметрия. Ну и если уж нужны имена, то может стоит придумать ещё всего одно имя  и сделать именованную структуру? Ну и почему прямо как в сях? В хаскеле тоже так, например.

> У них эта тема вообще не раскрыта.

Эта тема общая для всех языков с ADT, никакой Rust специфики в ней нет.

> И чем это от ubsan в сях отличается, например?

Тем, что здесь это не UB.

> И почему & в референсе структов вон там надо а вон там можно не ставить?

Это вопрос из серии из серии "почему в русском языке тут надо запятую ставить, а тут не надо". Потому что такие правила. Чтобы обсуждать предметно, нужна альтернатива. Только лучше не получится.

> можно ли там сделать допустим тип у которого валидное значение только от 3 до 8

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

> Здорово конечно но прогать какие-то более-менее реалистичные программы по этому не особо научишься.

Потому что это учебник языка, а не учебник программирования.

> требование допустим u128 ставит раком некоторые платформы

А что, длинную арифметику отменили? Атомарности Rust не требует от такого типа.

Ответить | Правка | Наверх | Cообщить модератору

478. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от warlock66613email (ok), 26-Июн-22, 20:05 
> Так и на вход нельзя. Симметрия.

Точнее так: на вход имена не может указывать вызывающая сторона (нет вызова функции с именованными параметрами), а на выход, наоборот, вызываемая (функция не может специфицировать имена для полей результата). И наоборот, функция при описании специфицирет имена входных параметров, а вызывающая сторона может декомпозировать результат в набор именованных параметров.

Ответить | Правка | Наверх | Cообщить модератору

488. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 27-Июн-22, 17:26 
> Точнее так: на вход имена не может указывать вызывающая сторона (нет вызова
> функции с именованными параметрами), а на выход, наоборот, вызываемая (функция не
> может специфицировать имена для полей результата).

А симметрия тут в каком месте возникает? Может, имелась в виду АНТИсимметрия? Вот в это я готов поверить :)))

Ответить | Правка | Наверх | Cообщить модератору

501. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от warlock66613email (ok), 28-Июн-22, 02:28 
Антисимметрия — это частный случай симметрии.
Ответить | Правка | Наверх | Cообщить модератору

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 врядли приблизятся в обозримом будущем. Они там сингулярность запилили втихаря?

Ответить | Правка | К родителю #473 | Наверх | Cообщить модератору

502. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от warlock66613email (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ообщить модератору

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ообщить модератору

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

225. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (138), 22-Июн-22, 23:32 
Тем временем C++ (орфография сохранена, ... - это именно троеточие, прямо в коде)

template<class T, class... Args>
inline T& fn(Args&&... args) {

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

252. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 23-Июн-22, 10:25 
> Тем временем C++ (орфография сохранена, ... - это именно троеточие, прямо в
> коде)
> template<class T, class... Args>
> inline T& fn(Args&&... args) {

Точнее, многоточие. Внезапно, в данном случае оказывается интутивно-понятно. Хотите "грузить" - налегайте на && и move semantics. Я бы уже загрузился. ;)

Ответить | Правка | Наверх | Cообщить модератору

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

265. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 23-Июн-22, 13:19 
> Это код из реального проекта, который судя по всему пишут компетентные разработчики,
> может поэтому и понятен.

Не сочиняйте. Fn - это foo.

> Но даже это кажется бессмысленной лапшой для
> человека, котрый знаком с хорошими языками.

"Интуитивно-понятно" в моём ответе выше следует понимать как "исходя из знания грамматики русского языка".

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

В живом проекте кто-то назвал функцию fn? Это невозможно.

> Нет, исходя только из грамматики русского языка, смысл этого кода понять не
> получится.

Пишите честно: "мне не удалось понять".

Ответить | Правка | Наверх | Cообщить модератору

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

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ообщить модератору

244. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –1 +/–
Сообщение от Онаним (?), 23-Июн-22, 08:59 
Вот о <()> они и думали.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

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

28. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –1 +/–
Сообщение от Аноним (4), 22-Июн-22, 10:54 
Тоже ниасилил прочитать новость?

Вообще предлагаю модераторам сделать следующие: вместо числа на картинке при отправке комментария отвечать на вопросы по содержанию новости.

Ответить | Правка | Наверх | Cообщить модератору

31. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +10 +/–
Сообщение от microsoft (?), 22-Июн-22, 10:57 
> преподносится как опция

Лицемерие. Ровно до тех пор пока драйвер видео или клавиатуры не будет на нем. Ню ню.

Ответить | Правка | Наверх | Cообщить модератору

45. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +7 +/–
Сообщение от Аноним (45), 22-Июн-22, 11:51 
>> преподносится как опция
> Лицемерие. Ровно до тех пор пока драйвер видео или клавиатуры не будет
> на нем. Ню ню.

Ну, сперва на одну восьмую шишечки вставят, а потом и всё ядро проржавеет.

Чот мне это напомнило... ЕМНИП, нужно вроде было старый инит на более быстрый и без фатального недостатка, переделать, но это не точно, давно это было.

Ответить | Правка | Наверх | Cообщить модератору

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

121. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –2 +/–
Сообщение от anonymous (??), 22-Июн-22, 13:56 
То есть RedHat вместо того чтобы втихаря ночью под одеялом накопить бесценный многолетний опыт по решению проблем тысяч промышленных установок, десятки тысяч проблем с обслуживающим персоналом, обобщить это и выяснить что башпортянки и есть главный источник проблем а значит источник бабла для проходимцев мнящих себя "я такой сисадмин юникса в свитере и знаю чем отличаются "" от '' на колени предо мной платите миллиарды за мои башзнания и нелтленные башпортянки, а то уволюсь и ппц фирме" нанял Лёню и решил проблемы, причем в открытую все документировано и свободно.

Но тут как солнце из за туч от Дебиановских начетчиков :

> нужно вроде было старый инит на более быстрый и без фатального недостатка

Ваш главный дебиановец кто эту мутную волну на RedHаt гнал уже не снами но дело его живет.

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

467. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 16:42 
Вообще-то волну гнать начал еще специалист по шаттлам из убунты. Но у него апстарт получился, скажем так, и хотя идея была прикольная (реакция на эвенты) оказалось что она в комплекте с некоторыми довольно специфичными граблями.

А именно
1) В этой штуке было не особо предусмотрено как притащить системные дефолты с одной стороны, дать админу их перекрыть с другой и чтобы пакетник при апдейте это все не выпилил к хренам. Об этом убунтуи просто не подумали на фазе дизайна а потом поздняк метаться было. Посмотрел на это поттеринг и сделал деление на системные дефолты притаскиваемые пакетником и более приоритетный админский оверрайд, который пакетники трогать не смеют просто по регламенту.

2) Прописать СВОЮ программу "до" или "после" чьей-то еще? В СВОЕМ конфиге запускалки? Да сейчас! Это надо конфигу той программы трогать. Опачки, а это уже полный залет, надо чужую программу и ее компонент портить оказывается. Посмотрел на это все поттеринг и сделал инверсию зависимостей. И вот тогда стало хорошо. Можно вот именно своим юнитом стартануть перед или за кем-то совсем посторонним, если мы уверены что надо именно вот так. Ну например если я запускаю прогу которой надо впн - я могу запуститься после того как впн запустился, а не до того как его интерфейса даже еще нету блин, так что подвиснуть на нем точно ой -> FAILED.

А sysv init вообще подобной фигней и много чем еще - не особо парился, вы там и...сь как хотите, дескать. Ну и творился трэш, угар и содомия.

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

432. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:35 
> На самом деле, логичным должен быть вопрос не "когда С++", а "когда
> Fortran, ADA, objective C".

Когда ты покажешь как на всем этом великолепии системщину делать и чтобы это не было еще более жутким чем все остальное.

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

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

44. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Попандопала (?), 22-Июн-22, 11:48 
Интим не предлагать?XD
Ответить | Правка | Наверх | Cообщить модератору

89. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Sw00p aka Jerom (?), 22-Июн-22, 12:45 
без смс и рекламы :)
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

мы же когда подходим к бармену не говорим "сделай мне смузи по такому вот рецепту".

Ответить | Правка | Наверх | Cообщить модератору

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

433. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:36 
> Здорово. А я уже лет 6 не запускал gdb за ненадобностью, потому
> что перешёл с C++ на Rust.

Круто, оказывается, хруст как-то делает программы без багов. Нюню, пылесосы иди продавай, Кирби позавидует.

Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

456. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от burjui (ok), 26-Июн-22, 13:26 
>Круто, оказывается, хруст как-то делает программы без багов.

Это я сказал или ты придумал? Вопрос риторический. Rust "делает программы" без некорректных обращений к памяти. А для поиска логических ошибок я gdb практически не использую, потому что гораздо удобнее вывести структуры данных в нужном формате через println!(), нежели ковыряться в сырых данных в gdb.

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

Ответить | Правка | Наверх | Cообщить модератору

468. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 16:53 
> практически не использую, потому что гораздо удобнее вывести структуры данных в
> нужном формате через println!(), нежели ковыряться в сырых данных в gdb.

Ну надо же, а у нас это "дебажный printf" называлось лет так .. дофига. Только у вас он оверинженернутый и можно поспорить баг сие или фича. И вдруг я что-то проприетарное пишу? Тогда я не хочу чтобы тем мордам утекали сведения о внутренней начинке программы в таких объемах, особенно с именами и прочим.

> Это тебе, Онаниму, нужно идти продавать пылесосы, потому что твоим навыки демагогии
> в программировании не только бесполезны, но ещё и вредны. В этой
> профессии и без тебя дураков хватает.

Просто напомноло уж очень логику продажников кирби. Мол покупайте пылесосы, смотрите, сколько пыли после вашего! Ух, а оказывается столько же и после их пылесоса будет, только про это не говорят :)

Ответить | Правка | Наверх | Cообщить модератору

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. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +2 +/–
Сообщение от Аноним (46), 22-Июн-22, 12:05 
Ох уж эти сказочки...
Ответить | Правка | Наверх | Cообщить модератору

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

182. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (182), 22-Июн-22, 18:48 
> Подробнее - в статье =)

Почти нажал. Но - нет.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

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

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

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

189. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (189), 22-Июн-22, 19:33 
Поддерживаю интерес!
Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

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

76. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 22-Июн-22, 12:30 
Если начнут писать модули на Расте каков их будет среднестатистический бинарный размер? Только не говорите мне, что надо каждый раз отключать включёные по умолчанию функции дебага.

Если начать компилировать исходные коды на Расте, сколько ждать? Половину дня? Люди говорят, что исходники на Расте и C++  компилируются очень долго.

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

Короче, в голову приходят страшные мысли. Ребята передайте Линусу пусть он пока не пускает Раст в ядро! А корпорасты, которые лоббируют продвижение Раста пусть идут лесом.

Ответить | Правка | Наверх | Cообщить модератору

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

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

Раст, внезапно, функциональный. Так что, в общем случае, меньше. Другое дело, что железо "императивно".

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

258. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (258), 23-Июн-22, 11:22 
> Раст, внезапно, функциональный.

в расте функции - первоклассные объекты, можно ими жонглировать как душе угодно?

Ответить | Правка | Наверх | Cообщить модератору

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ообщить модератору

286. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (258), 23-Июн-22, 15:00 
> Вот обычные для ФЯ конструкции:

Уровень детсада. Где передача функций, как объектов, каррирование, композиция функций и прочая ненизкая математика?

Ответить | Правка | Наверх | Cообщить модератору

291. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 23-Июн-22, 15:34 
>Уровень детсада.

В системном программровании нужна только процедурщина.

>Где передача функций, как объектов, каррирование, композиция функций и прочая ненизкая математика?

А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном программировании не нужна.

Ответить | Правка | Наверх | Cообщить модератору

299. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 23-Июн-22, 16:25 
> А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном
> программировании не нужна.

Смысл функционального программирования не в этих всех замыканиях. Если процедура хранит состояние, то для одних и тех же входных данных она может давать различный результат. Отсюда следует идея чистых функций и иммутабельности: если состояние не хранить, тогда можно на этапе трансляции доказать корректность кода -- как раз это в Rust и называют "безопасность". По той же причине в императивных языках по возможности стараются писать const. Но в реальном железе имеем const volatile. =)

Ответить | Правка | Наверх | Cообщить модератору

444. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 13:00 
> в реальном железе имеем const volatile. =)

Это что еще за порнография? Типа регистр RO для софта, но который может со своей стороны менять железо?

Ответить | Правка | Наверх | Cообщить модератору

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

Это когда регистр железно выполнен как RO, софт может туда и писать, но ничего не изменит.

Ответить | Правка | Наверх | Cообщить модератору

470. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (-), 26-Июн-22, 17:03 
> Это когда регистр железно выполнен как RO, софт может туда и писать,
> но ничего не изменит.

А, обычный RO регистр, что-то я тупанул тут. Вообще регистры логично референсить как адреса в памяти, то-бишь указатели, и там чуть сложнее получается - const'ов может быть ДВА. У указателя (как индикатор что адрес регистра прибит на гвозди, зачем нам баги если мы сдуру указатель сменим?!) - и потом у его типа. Как бы именно volatile const'ом регистр вообще не референсится, скорее указателем на него.

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

Интересно как хрустики кстати volatile делают и вот это самое, раз кудахчут про системность.

Ответить | Правка | Наверх | Cообщить модератору

442. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:58 
> В системном программровании нужна только процедурщина.

А ты уверен что даже просто ioctl какой попадает под именно такое определение? :)

А еще - в сях можно функции переназначать на лету, передавать как параметры и проч. Указателями на функцию, прикинь?! Это позволяет делать довольно забавные вещи.

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

>>Где передача функций, как объектов, каррирование, композиция функций
>>и прочая ненизкая математика?
> А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном
> программировании не нужна.

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

Ответить | Правка | К родителю #291 | Наверх | Cообщить модератору

298. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 23-Июн-22, 16:07 
>> Вот обычные для ФЯ конструкции:
> Уровень детсада. Где передача функций, как объектов, каррирование, композиция функций
> и прочая ненизкая математика?

Наберите интересующие слова в поисковике и читайте. Как должно быть понятно из первой ссылки, которую Вы заботливо вырезали при цитировании, там всё это можно найти. Я лишь намекаю, что функциональное программирование это не только лямбда исчисление.

Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

301. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (258), 23-Июн-22, 16:30 
> Я лишь намекаю, что функциональное программирование это не только лямбда исчисление.

Еще один невзрослый тезис. Не надо приравнивать некоторые элементы ФП и само ФП.
Функциональное программирование - это именно жонглирование функциями.

Как в расте передать композицию функций, особенно вернуть как результат, особенно с захватом локальных значений?

Ответить | Правка | Наверх | Cообщить модератору

339. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 24-Июн-22, 07:34 
> Функциональное программирование - это именно жонглирование функциями.

Поскольку "жонглирование" не формализовано, процитированное "определение" ФП - демагогическая чушь. Поскольку цирковой термин повторяется дважды - похоже на мантру для некоей секты.

Ответить | Правка | Наверх | Cообщить модератору

347. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 24-Июн-22, 10:01 
> "определение" ФП - демагогическая чушь

Вот именно, сегодня. Сегодня "определение" ФП - это "парадигма", что есть не формальное определение, а демагогия. Сегодня любой новый модный молодежный язык, в котором есть термин "функция" - это "язык ФП". А вот раньше трава была зеленее.

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

435. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:40 
> Он же компилируемый - так что есть нюансы с eval. Через пару
> лет можно будет оформить в виде llvm.ko.

Чочо, модуль на 60 метров, да еще на плюсах? Ух блин нет, за это Торвальдс таки все же прилюдно люстрирует, имхо :)

Ответить | Правка | К родителю #260 | Наверх | Cообщить модератору

447. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 26-Июн-22, 13:12 
>> Он же компилируемый - так что есть нюансы с eval. Через пару
>> лет можно будет оформить в виде llvm.ko.
> Чочо, модуль на 60 метров, да еще на плюсах? Ух блин нет,
> за это Торвальдс таки все же прилюдно люстрирует, имхо :)

Так это будет потом. Когда привыкнут, что Rust уже и так есть, выйдет версия 2.0. Окно Овертона же.

Ответить | Правка | Наверх | Cообщить модератору

489. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 27-Июн-22, 17:37 
> Так это будет потом. Когда привыкнут, что Rust уже и так есть,
> выйдет версия 2.0. Окно Овертона же.

Скорее, научат хруст eBPF какой генерить и в юзермод вывесят :))). Но между нами, вон там LLVM или кто еще GPUшке в юзермоде шейдеры как-то так и компиляет.

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

Ответить | Правка | Наверх | Cообщить модератору

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

259. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (258), 23-Июн-22, 12:35 
А в расте - больше, потому что динамическая линковка с libc.
Ответить | Правка | Наверх | Cообщить модератору

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

436. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +2 +/–
Сообщение от Аноним (-), 26-Июн-22, 12:40 
> А в расте - больше, потому что динамическая линковка с libc.

Господа, а вас не смущает что кернел с libc не линкуется, ни там ни там? :)

Ответить | Правка | К родителю #259 | Наверх | Cообщить модератору

149. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (149), 22-Июн-22, 15:23 
> Если начнут писать модули на Расте каков их будет среднестатистический бинарный размер?

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

> Только не говорите мне, что надо каждый раз отключать включёные по умолчанию функции дебага.

А зачем у тебя по умолчанию включён дебаг?

> Если начать компилировать исходные коды на Расте, сколько ждать?

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

> Одинаковая реализация в процедурном стиле среднестатистического алгоритма на чистом Си будет занимать меньше строк чем на Расте?

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

> Ребята передайте Линусу пусть он пока не пускает Раст в ядро!

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

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

174. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Андрей (??), 22-Июн-22, 18:31 
> Без разницы - конечные пользователи устанавливают готовый бинарь. Даже если захочется самому собрать - это разовая операция.

Особенно, когда тебе говорят попробовать найти баг с помощью git bisect.

Да и корректирующие релизы ядра выходят не раз в полгода. Так что далеко не разовая.

Ответить | Правка | Наверх | Cообщить модератору

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

437. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:42 
> Ты модуль ядра решил компилировать что ли, раз тебе бисект потребовался? Тогда
> бы ты знал что занимаешься его разработкой и не говорил что
> бинарно бисектить собрался. Короче мимо парень

А в чем прикол стандартное стоковое ядро компилить? Bisect это как раз вполне валидная причина компилежки и время оного очень даже интересует.

Ответить | Правка | Наверх | Cообщить модератору

190. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +2 +/–
Сообщение от Аноним (189), 22-Июн-22, 19:46 
> Прогресс в развитии языков наоборот, позволяет писать код менее громоздко, но при этом более понятно.

Ну все, Я понял, почему программы так пожирнели последнее время. ;) Это чтобы понятность не изменилась! ;) ;) ;)

Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

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

230. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (138), 23-Июн-22, 00:24 
Сначала такой
>адаптируйся или деприсируй 🤣

а потом
>меня-то защооо?!!

Ответить | Правка | Наверх | Cообщить модератору

247. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (189), 23-Июн-22, 09:39 
Оптимизации люблю до определённого предела. Но, постоянная память и особенно ОЗУ они же не резиновые, что бы бросать туда всякий ненужный мусор. Но Вы же (ИМХО) гооооораздо выше таких мелочей (пока Вам этот мусор на голову не начнет сыпаться).

Дико извеняюсь, но...
Как же Я люблю это Но, оно как правило дремлет, но, как иногда бывает, вот заблудился человек в дебрях технического прогресса, потерялся, растерялся, запутался в чужой да и в собственной лжи, и тут о чудо, Но вдруг неожиданно просыпается, да как подпрыгнет как подскочит, надает заблудшему аплпеух да подзатыльников, повернет в сторону Истины и даст хорошего пинка, что бы Прогрессу было за кем гнатся! ;)
А бывает, Но не просыпается. И приходится Прогрессу плеваться и плестись, блудить и плеваться. Грустно?!? :(
НО, мы не будем, строить разлапистые теории заговоров, а просто спишем все на простую человеческую ... мудрость! ;)

Если под словом деприсируй Вы имели ввиду пресс, то мне больше нравится, элиминируй, в данном контексте.

О своих желаниях Я тайно поведал в предыдущем своем посте. Об остальных, скромно умолчу ;)

Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

173. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Андрей (??), 22-Июн-22, 18:25 
> Если начать компилировать исходные коды на Расте, сколько ждать? Половину дня? Люди говорят, что исходники на Расте и C++  компилируются очень долго.

А до включения Раста ядро можно было скомпилировать прям на ходу при запуске с помощью tcc (Tiny C Compiler).

Не говоря уже про время сборки самого компилятора. Ведь Раст - это не только сам Раст, но ещё и монстр LLVM.

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

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

235. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +4 +/–
Сообщение от burjui (ok), 23-Июн-22, 03:08 
> Короче, в голову приходят страшные мысли.

А вот если будешь изучать язык, читать документацию и писать программы, будут приходить ещё и умные. На все твои вопросы есть очевидные ответы. Но тебе нужны не ответы, а солидарность таких же хейтерков, у которых других проблем нет в жизни, кроме Rust, который прямо-таки давит на мозги, покоя не даёт. Ну как же, придётся работать не с сырыми указателями, а со ссылками, думать, кто владеет памятью, у кого доступ на чтение, а у кого - на запись, а то же "буручекир заругаит", ещё всякие дженерики и трейты - того гляди, последняя извилина перегорит. А ещё скобочек много, глаза болят. То ли дело православная сишка, в которой скобок меньше и код красивый, как женская сися, накидал указателей, погонял немного (код, а заодно и лысого на код)... ну, раз не падает, значит багов нет. Статическая верификация - для слабаков, а настоящий программист не примет помощи от какого-то там компилятора, и вместо 100 строк unsafe кода будет читать столько кода, сколько потребуется. Заодно и наизусть выучит, чтобы потом зайти на сервер и набрать заново, потому что Git - тоже для слабаков.

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

323. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Sw00p aka Jerom (?), 23-Июн-22, 22:15 
>А вот если будешь изучать язык,

совет на вес золота, С бы так изучали

Ответить | Правка | Наверх | Cообщить модератору

330. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от burjui (ok), 24-Июн-22, 01:21 
Можно его изучать хоть 40 лет, но от ошибок в работе с памятью это не спасёт. Если даже лучшие программисты на планете их совершают, то про опеннетных экспертов я вообще молчу. К тому же, готов поспорить, что большинство из последних не знает и половины ситуаций с undefined behaviour в их любимом языке, потому что компиляторы в большинстве случаев услужливо генерят вменяемый код, а не мусор, как могли бы, согласно стандарту. А в остальных случаях эксперты вынуждены запускать отладчик и с переменным успехом искать, из какой щели сыпется мусор. Заметь, я нигде не говорю, что С - говно и т.п., как здесь принято у местной элиты по отношению к другим языкам. Я просто перечисляю объективные недостатки языка.

Если вдруг непонятно, вездесущий undefined behaviour и полное отсутствие проверки указателей со стороны компилятора - это недостатки. Мы не в 80х живём, программы сейчас намного функциональнее, соответственно, их код намного больше, и уже только из-за этого становится практически невозможно писать код на C, лишённый багов, связанных с некорректным обращением к памяти. Чем больше компилятор предотвращает ошибок, тем лучше для всех - и разработчиков, и пользователей. По-моему, это очевидно. Поэтому разработчики ядра, наученные горьким опытом, и готовы включить поддержку Rust в ядро, коль уж сишные стандартизёры, мягко говоря, не очень торопятся улучшать свой ЯП.

А вот почему на техническом ресурсе ошиваются толпы луддитов-нарциссов с гипоманией и нездоровой фиксацией на C, мне совсем не очевидно. Может, это религия такая, секта? Это как если бы ты на городской улице сел перекусить бутербродом, а к тебе подбежал небритый косматый человек, одетый в шкуры, и стал бы учить, как разводить баранов и выращивать пшеницу - дескать, это азы выживания, и ты не можешь считаться мужиком, если не бегал полдня с копьём за будущим обедом.

Ответить | Правка | Наверх | Cообщить модератору

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

Может им приходилось принимать участие в разработке ядра? Если они знают Си, это вероятный сценарий. Если это так, значит часть "луддитов" говорит о том, что их так или иначе касается (насколько они правы или ошибаются - это вопрос второй). А вот что делают остальные?

Ответить | Правка | Наверх | Cообщить модератору

349. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от burjui (ok), 24-Июн-22, 10:14 
> Может им приходилось принимать участие в разработке ядра? Если они знают Си,
> это вероятный сценарий.

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

Ответить | Правка | Наверх | Cообщить модератору

352. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 24-Июн-22, 10:41 
А у Вас есть коммиты в ядро?
Ответить | Правка | Наверх | Cообщить модератору

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

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ообщить модератору

392. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Sw00p aka Jerom (?), 25-Июн-22, 12:01 
>штука, как когнитивная ригидность. Стойкость убеждений, если по простому.

нет, была бы болгарка в руках Микеланджело его бы скульптуры были бы щедевральнее чем тем же зубилом? Принял бы он болгарку, если всю жизнь учился мастерству работы с зубилом? А в чем разница он бы сразу сказал бы.

Ответить | Правка | Наверх | Cообщить модератору

445. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 13:02 
Черт его знает, но если болгарка будет маленькой и CNCшной, я могу попробовать забахать что-то прикольное. И в отличие от Микеланджело не обломлюсь повторить на бис 50 раз. Или 50 000 000 раз. Иногда это по своему прикольно.


Ответить | Правка | Наверх | Cообщить модератору

454. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Sw00p aka Jerom (?), 26-Июн-22, 13:20 
> и CNCшной

вот тут надо задуматься, ибо ЧПУшку надо программировать (пошагово) и получается, что мы придерживаемся строгих правил движения, это как черчение. Но ведь мы не "ценим" черчение так как "ценим" изобразительное искусство (графику к примеру, без красок), вопрос - почему.


Ответить | Правка | Наверх | Cообщить модератору

472. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 18:26 
> вот тут надо задуматься, ибо ЧПУшку надо программировать (пошагово)

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

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

Зубилом тоже не любой объект сможешь. Попробуй им полость внутри сделать без изъянов? И не любой материал сможешь. Ну, отзубиль кусок титана, допустим. А какой-нибудь 3D принтер в принципе может это обойти, другая технология - другие лимиты. При том модель он сожрет в общем то ту же самую.

> Но ведь мы не "ценим" черчение так как "ценим" изобразительное искусство
> (графику к примеру, без красок), вопрос - почему.

С другой стороны, лично я вполне оценил ролик про "костюм железного человека" на ютубе. Из титана, выдерживает попадание пуль, и даже летает (хоть и оказалось что есть нюансы). И хотя его можно повторить, это дорого, возни много, а смысла мало, к тому же надо с правообладателем опять согласовывать. Поэтому он такой один на всю планету. Зачетный артефакт так то. В общем то ценим мы, имхо, талант, креативность, оригинальные идеи и что-то неординарное. Вот именно черчеба в чистом виде как и рутинная трансляция команд этим не является. А оригинальная модель и проект в целом - уже вполне. Ну и когда оно масспродакшн то оно просто приедается и начинает восприниматься как должное.

Ответить | Правка | Наверх | Cообщить модератору

356. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Sw00p aka Jerom (?), 24-Июн-22, 13:57 
>Участник 'burjui' запретил публикацию ответов

ожидаемо

>Можно его изучать хоть 40 лет, но от ошибок в работе с памятью это не спасёт.

если складывать все яйца в одну корзину, кто виноват? Продавец или курица которая несет ломающиеся яйца?

пс: все беды людские - от ума.

"""
В комедии «Горе от ума» кто умное действующее лицо? ответ: Грибоедов. А знаешь ли, что такое Чацкий? Пылкий, благородный и добрый малый, проведший несколько времени с очень умным человеком (именно с Грибоедовым) и напитавшийся его мыслями, остротами и сатирическими замечаниями. Все, что говорит он, очень умно. Но кому говорит он все это? Фамусову? Скалозубу? На бале московским бабушкам? Молчалину? Это непростительно. Первый признак умного человека — с первого взгляду знать, с кем имеешь дело и не метать бисера перед Репетиловыми и тому подоб.
"""

Свои критические замечания о произведении высказал А. С. Пушкин в конце января 1825 года в письме А. А. Бестужеву из Михайловского в Петербург.


Ответить | Правка | К родителю #323 | Наверх | Cообщить модератору

77. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (58), 22-Июн-22, 12:31 
>Линус Торвальдс упомянул о возможности скорой интеграции в ядро Linux компонентов для разработки драйверов устройств на языке Rust

А c++ ему не нравится! И в защиту плюсов скажу что HaikuOS (как и BeOS) от ядра и загрузчика и до самого юзерспейса написана на c++! И вот-вот нагнёт этот ваш линукс на декстопах! Уже сейчас почти работает vulkan-видеодрайвера для radeon карт!

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

129. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +3 +/–
Сообщение от Аноним (138), 22-Июн-22, 14:29 
> от ядра и загрузчика и до самого юзерспейса написана на c++

Как что-то хорошее. Приходи, когда нагнёт.

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

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

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

373. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от warlock66613email (ok), 24-Июн-22, 22:44 
Про SEH я в курсе. Интересно именно про C++ и HaikuOS / BeOS.

> Штатный RTTI есть в Qt.

Ого. Пожалуй стоит сильнее прислушаться к хейтерам современного Qt. Возможно они не так уж неправы.

Ответить | Правка | Наверх | Cообщить модератору

386. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 25-Июн-22, 07:43 
> Про SEH я в курсе. Интересно именно про C++ и HaikuOS /
> BeOS.

Что именно интересно про Си++? Когда дизайнили ядро NT, насколько понимаю, языка С++ не было. SEH точно так же хранит некоторую информацию времени исполнения о типе ошибки. Точно так же есть проблемы, не работает на высоких IRQL. И ещё объекты ядра обмениваются сообщениями. :)

Ответить | Правка | Наверх | Cообщить модератору

393. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от warlock66613email (ok), 25-Июн-22, 13:04 
> Что именно интересно про Си++?

Интересно, написаны HaikuOS/BeOS на C++ с эксепшенами или на C++ без эксепшенов.

Ответить | Правка | Наверх | Cообщить модератору

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ообщить модератору

397. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от warlock66613email (ok), 25-Июн-22, 16:17 
Из приведённого вами куска кода ответ на мой вопрос не получить никак.

Врочем, действительно, если поискать (для ответа на мой вопрос искать надо конечно в первую очередь `dynamic_cast`, а во вторую `catch`, в то время как наличие/отсутствие `throw` совершенно иррелевантно), то похоже что используется именно то, что называется «C++ без эксепшенов».

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

86. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +2 +/–
Сообщение от iPony129412 (?), 22-Июн-22, 12:42 
Это знак 😮. С сегодняшнего дня начну учить Rust.
Найду книгу хорошую и начну.
Ответить | Правка | Наверх | Cообщить модератору

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

101. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от iPony129412 (?), 22-Июн-22, 13:01 
> "Rust за 21 час с нуля" или "Rust для тинейджеров" ещё не написали.

Жаль, хотя мне всё равно.
Вот с функциональщиной плохо - это может помешать наверно...

Ответить | Правка | Наверх | Cообщить модератору

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

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

127. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от iPony129412 (?), 22-Июн-22, 14:25 
> лучше сначала изучите организацию ЭВМ, архитектуру железа и ядра. а потом хоть JS

Уже есть. Только JS не это. Но не хочу как-то 🤷♂

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

151. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (151), 22-Июн-22, 15:35 
>На нём явно поприятнее писать

Субъективщина же. Я в своё время с радостью свалил с Паскаля на C++, не в последнюю очередь из-за многословности синтаксиса первого. Предполагаю, большинству кодеров больше по душе C-like.

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

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

519. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 01-Июл-22, 00:01 
Автодополнение видите ли может и ложно сработать, что так то тоже бесит.

И это, визуально код с парными скобками и форматированием схватывается лучше чем какой-то текст begin-end который к тому же - цуко - разной длины, что как бы FAIL т.к. блоки кода косые малость получаются. И это не круто.

Ответить | Правка | Наверх | Cообщить модератору

232. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +3 +/–
Сообщение от _kp (ok), 23-Июн-22, 02:42 
А смысл? По проблемам человечкого фактора с Си он одинаков.
А синтаксис, помимо многословности, деревянный, логика исполнения неоднозначная.
Помимо begin end, в исходнике ещё круглых скобок требуется заметно больше чем на Си.

За одно объявление переменных,там, далеко, где то вначале, неплохо бы автору по пальцам настучать.

Во времена Delphi приходилось переписывать с Си на Паскаль. В итоге получали, более многословный и менее читаемый код, с проблемами из за неоднозначной логики его исполнения. Битовые поля и работа с указателями зерез задницу, плюс куча костыльных пременных.
В общем, выходит только хуже.

В принципе, если хочется, драйвер возможно написать и на Паскале и на Си++, но он будет в таком виде никому не нужен.

И... если человек утвержает, что на Паскале __поприятнее__ писать "дрова", то именно драйвера он точно не писал.

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

267. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +2 +/–
Сообщение от Аноним (138), 23-Июн-22, 13:23 
Как же вам печёт от begin end и объявления переменных, любо дорого посмотреть. Видимо си правда оказывает какое-то влияние на мышление.

>круглых скобок требуется заметно больше чем на Си

Медитируй:

if (!((ch >= 0x0FF10) && (ch <= 0x0FF19)) ||
     ((ch >= 0x0FF21) && (ch <= 0x0FF3A)) ||
     ((ch >= 0x0FF41) && (ch <= 0x0FF5A)))

Код на паскале сам осилишь.

Ответить | Правка | Наверх | Cообщить модератору

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

275. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (138), 23-Июн-22, 13:57 
Про С89 интересно.

Как это не холивар? А что тогда?

Ответить | Правка | Наверх | Cообщить модератору

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

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 блока элегантнее не становится.

Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

309. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (138), 23-Июн-22, 18:39 
В том примере прямой перевод if (без всяких case) убирает половину сишных скобок.

>подобных и хуже конструкций

Почему-то не удивлён увидеть именно сишный код.

Ответить | Правка | Наверх | Cообщить модератору

505. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (505), 28-Июн-22, 12:11 
> Медитируй:
>
> if (!(ch >= 0x0FF10 && ch <= 0x0FF19 ||
>       ch >= 0x0FF21 && ch <= 0x0FF3A ||
>       ch >= 0x0FF41 && ch <= 0x0FF5A))

Починил. У автора вашего варианта проблемы с приоритетами операторов, причём явные, раз уж он даже не знает, чей приоритет выше: логического умножения или логического сложения.

А в Паскале, да, надо везде ставить скобки, как вы и написали. Да ещё и вместо &&/|| использовать and/or.

Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

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

438. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:45 
> За 30 лет могли бы лучше Pascal впилить в ядро.
> На нём явно поприятнее писать, и дрова в том числе.

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

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

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

115. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +6 +/–
Сообщение от Аноним (61), 22-Июн-22, 13:23 
На windows.
Ответить | Правка | Наверх | Cообщить модератору

193. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 22-Июн-22, 20:03 
Смищно.
Ответить | Правка | Наверх | Cообщить модератору

209. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +9 +/–
Сообщение от Аноним (209), 22-Июн-22, 22:33 
> Смищно.

А что плохого в этом совете?
Ядро windows не написано на rust, не имеет systemd, pulseaudio, gnome и других подобных нехороших вещей которые ненавидят эксперты с opennet, а значит подходит больше чем Linux

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

280. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Онаним (?), 23-Июн-22, 14:35 
Чичиго?
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

336. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от _ (??), 24-Июн-22, 04:55 
FAR bro :)
Ответить | Правка | Наверх | Cообщить модератору

358. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (358), 24-Июн-22, 14:32 
notepad++, mpc-hc
Ответить | Правка | К родителю #322 | Наверх | Cообщить модератору

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

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

446. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 13:11 
> у небезызвестного mc от того же FAR хорошо если треть функционфала
> есть (а если FAR обвесить плагинами, то на mc без желания
> обнять и плакать вообще смотреть не получится).

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

Тем более что миднайт я могу даже на вон том роутере-мыльнице запустить, по ssh. Попробуй так с фарой, особенно в винде. В этом месте мы и понимаем прелесть *никсной консоли: универсальный и очень нетребовательный тул. Лезущий по сети с минимальными требованиями, по неспешным сериальным шнуркам, а по сути всему что отдаленно напоминает коммуникационный канал, даже неторопливый и базовый. А траблшутинг какой-нибудь винды которая не взлетает это вообще например очень отдельный вид жэсти. И в лине - только подумай - миднайт запустится в лысой консоли в single user mode и поможет по ФС при отскребании системы от асфальта навигировать. А в винде ... ну фар ты явно при проблемах такого уровня уже не запустишь.

Ответить | Правка | Наверх | Cообщить модератору

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

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

491. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 27-Июн-22, 17:42 
> Миранда для чего-то пригодна в 2022?

Гм, эту стюардессу оказывается откопали - см. соседнюю новость.

Ответить | Правка | Наверх | Cообщить модератору

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

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

292. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 23-Июн-22, 15:42 
Толсто.

Windows сама по себе Зло!

Ответить | Правка | Наверх | Cообщить модератору

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

Если Linux совсем загрётся и не будет новых вменяемых альтернатив, лично я ливна на опёнка, т.к. Тео не ср@ный толерастный смузибой-макакокодер, а суровый мужик старой закалки с правильным здравым подходом к ненужному.

Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

132. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (138), 22-Июн-22, 14:34 
>BSD

Можешь попробовать.

> Mac OS X

Нет.

Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

196. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (58), 22-Июн-22, 20:13 
>Не подскажете куда лучше переходить? FreeBSD, OpenBSD или может быть Mac OS X?

HaikuOS!

Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

203. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Ан (??), 22-Июн-22, 21:22 
DragonflyBSD
Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

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

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

143. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (143), 22-Июн-22, 15:00 
Ждем дополнения в виде Golang и Ziglang
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Ну, экспертами они видят себя в зеркало. А со стороны больше напоминают потенциальных обитателей психиатрического стационара. Сами-то, поди, в ядро ни строчки не написали за всё время использования Linux, но ни дай бог там кто-то хоть строчку на Rust напишет - всё, конец света, тролльвальдс скатился, луникс пропал, валим на BSD. Ой, а там всё по-другому, разбираться надо, а ещё дров не хватает, бежим назад. Точно так же до этого верещали про systemd, хотя сейчас посади их за дистр с классическим инитом и скриптами - начнутся "вьетнамские" флэшбэки.

Специалисты по архитектуре бреда в комментариях.

Ответить | Правка | Наверх | Cообщить модератору

357. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +4 +/–
Сообщение от Анончик (?), 24-Июн-22, 14:23 
> местные критики - эксперты во всём

Ну так и есть, а что плохого-то? Это вы там в своём загончике пасётесь. Барин сказал systemd, значит systemd. Барин сказал rust, значит rust. Барин сказал, что нужно анализы сдавать, пошли сдавать. Всё для вашей же безопасности, главное не бухтеть, нужно немного подождать и уже скоро будет коммунизм. А пока вот котлетки на ужин.

Вам повезло, что эту информацию тут можно почитать.

Ответить | Правка | Наверх | Cообщить модератору

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

368. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от burjui (ok), 24-Июн-22, 21:01 
Какой ещё барин? Никто никого не заставляет учить Rust, я вот учил по собственному желанию, т.к. нравятся языки ML-семейства и borrow checker. И даже пользоваться Systemd никто не заставляет, дистрибутивов Linux - гора и маленькая тележка. Мне как пользователю Systemd не мешает, конфигурация намного проще, чем с инит-скриптами, система грузится быстрее.

Вы - не эксперты, а демагоги с раздутым самомнением и синдромом Даннинга-Крюгера. И то, что вы здесь генерируете - не информация, а информационный шум. На весь Опеннет хорошо если с десяток толковых разработчиков наберётся из активно комментирующих, результаты работы которых можно посмотреть в опенсорсных проектах, а остальные только и могут, что хамить, безосновательно критиковать и рассказывать сказки про то, как они без ошибок пишут на C чуть ли не для космических аппаратов. Невоспитанная школота, начитавшаяся умных книжек, но без критического мышления, которая возомнила себя экспертами.

Ответить | Правка | К родителю #357 | Наверх | Cообщить модератору

370. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –1 +/–
Сообщение от Анончик (?), 24-Июн-22, 21:33 
> Я - хороший, это они плохие!

Понятно.

Ответить | Правка | Наверх | Cообщить модератору

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

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

448. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 13:13 
> сказки про то, как они без ошибок пишут на C чуть
> ли не для космических аппаратов. Невоспитанная школота, начитавшаяся умных книжек, но
> без критического мышления, которая возомнила себя экспертами.

И тем не менее полно софта, в том числе и для космоса, писаного на си. А на эмбедовке без MMU хруст так то даже от элементарного переполнения стэка не защищает, внезапно.

Ответить | Правка | К родителю #368 | Наверх | Cообщить модератору

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

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

186. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –1 +/–
Сообщение от Аноним (138), 22-Июн-22, 19:05 
Почему не добавить GC в ядро?
Ответить | Правка | Наверх | Cообщить модератору

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

449. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 13:15 
> Почему не добавить GC в ядро?

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

А, самое стебное? Хруст почему-то у них можно в системщине но для приложух не заявлено. Логика.

Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

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

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

451. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 13:16 
> Ты думаешь, тебе будут делать безопасные языки, приносить прямо в руки, пиарить
> на весь интернет, только возьми? Как это должно работать, по-твоему?

Zig и Hare ... примерно как-то так и образовались. А чего в этом такого?

Ответить | Правка | Наверх | Cообщить модератору

154. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (154), 22-Июн-22, 16:01 
Интересая новость. Вот недавно Линус разрешил-таки наконец использовать С11. Через 11 лет после появления стандарта.

Отсюда вопрос. Какая версия rust будет доступна в ядре?

Ответить | Правка | Наверх | Cообщить модератору

156. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (156), 22-Июн-22, 16:09 
Ты новость читал? Прочитай с места

> Торвальдс упомянул о возможности скорой интеграции в ядро Linux компонентов для разработки драйверов устройств на языке Rust. Не исключается, что патчи с поддержкой Rust будут приняты в ближайшем окне приёма изменений, формирующем состав ядра 5.20...

Ответить | Правка | Наверх | Cообщить модератору

162. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (154), 22-Июн-22, 16:45 
И? Какая версия rust?

И как часто ее можно будет увеличивать?

Ответить | Правка | Наверх | Cообщить модератору

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

266. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (154), 23-Июн-22, 13:20 
> По факту наличия стабильной версии наверняка и главное есть кому поддерживать, иначе финн бы не одобрил.

Насколько я понимаю, он на данный момент смотрит только на "возможна ли хоть какая-то польза". На инфраструктуру внимания не обращал.

Хотя, конечно, учитывая опыт использования системы контроля версий, я был бы за такой вариант.

Посмотреть как и что, и запилить свое без cargo и бабочек.

Ответить | Правка | Наверх | Cообщить модератору

293. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 23-Июн-22, 15:44 
>чухает.

Переведи.

Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

288. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 23-Июн-22, 15:23 
>И? Какая версия rust?

Модная, модная.

Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

452. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 13:17 
> И? Какая версия rust?

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

Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

155. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (156), 22-Июн-22, 16:07 
>  Использование Rust для разработки драйверов позволит с минимальными усилиями создавать безопасные и более качественные драйверы, избавленные от таких проблем как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера...

Эта мантра также обязательна в любом тексте про Rust как и "<Организация> запрещена на территории РФ"?

Ответить | Правка | Наверх | Cообщить модератору

200. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от microsoft (?), 22-Июн-22, 21:16 
Фанатики, сэр.
Ответить | Правка | Наверх | Cообщить модератору

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

164. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (164), 22-Июн-22, 17:22 
> обязательной инициализации значений переменных перед использованием

А разве может быть иначе?

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

374. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от warlock66613email (ok), 24-Июн-22, 23:10 
> Обязательная инициализация означает необходимость тратить время процессора и память на
> ненужную оптимизацию переменных. Для системного программирования, где важен каждый такт,
> она неприемлема.

И поэтому в Rust есть переменные типа `MaybeUninit`. (Для которых, разумеется, также обязательна инициализация, но она не тратит время процессора и память (если использовать для инициализации значение `MaybeUninit::uninit()`.)

Ответить | Правка | Наверх | Cообщить модератору

388. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (278), 25-Июн-22, 10:24 
Какой ужасный синтаксис
Ответить | Правка | Наверх | Cообщить модератору

398. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от warlock66613email (ok), 25-Июн-22, 16:53 
> Какой ужасный синтаксис

Именно синтаксис здесь плюсовый. И что в нюм ужасного? Двойное двоетчие? А `MaybeUninit`, `uninit` — это не синтаксис, это просто идентификаторы, имя типа и тмя метода.

Ответить | Правка | Наверх | Cообщить модератору

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

"Синтаксис не важен!", скажут многие, окей, если синтаксис неважен, то почему его нельзя было сделать проще?

Ответить | Правка | Наверх | Cообщить модератору

385. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от n00by (ok), 25-Июн-22, 07:29 
> Обязательная инициализация означает необходимость тратить время процессора и память на
> ненужную оптимизацию переменных.

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

> Для системного программирования, где важен каждый такт,
> она неприемлема.

Ответить | Правка | К родителю #364 | Наверх | Cообщить модератору

440. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:49 
> Если переменная в памяти, память "потрачена" независимо от инициализации.

А вот это - совсем не факт. Оптимизатор может все пох@рить в ноль если видит что side effects от этого ровно ноль. И кода не будет вообще. И данных тоже. С железным аргументом "а если не видно разницы, зачем генерить больше?"

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

С чего бы это вдруг такие гарантии вот так безаппеляционно?

>> Для системного программирования, где важен каждый такт, она неприемлема.

С другой стороны факапнуться с uninitialized variable в нем тоже так себе радость. Особенно когда все работает но раз в месяц почему-то палка все же стреляет.

Ответить | Правка | Наверх | Cообщить модератору

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

Так я описал худший случай, поскольку отвечал на: "Обязательная инициализация означает необходимость тратить время процессора и память на ненужную оптимизацию переменных".

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

Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет прочитана), а потом кеш скидывается в ОЗУ. А если нет записи, тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе придётся ждать.

Ответить | Правка | Наверх | Cообщить модератору

520. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 01-Июл-22, 00:09 
> Так я описал худший случай, поскольку отвечал на: "Обязательная инициализация означает
> необходимость тратить время процессора и память на ненужную оптимизацию переменных".

Не уверен что это настолько уж масштабная проблема.

> Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет
> прочитана), а потом кеш скидывается в ОЗУ. А если нет записи,
> тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе
> придётся ждать.

У нормальных людей инициализация переменных не настолько частая чтобы это было проблемой. Более того - при генерации кода компилер вообще может целиком заинлайнить все. При том возможно что 90% нужного уже было в других регистрах.

А с каким-нибудь LTO зависимость вообще нелинейная. Иногда казалось бы более плохой код генерит более короткий и резвый код. В чем прикол? А вон там глобальному оптимизатору константы лучше легли. С ним вообще приходится эмпирически, на конкретном коде подбирать :). Но он круто лишнее выпиливает. Может треть кода аннулировать без какого либо изменения скорости или логики. И вот тут оно стоит того чтобы погреть проц при компиле, как минимум релизной версии.

Ответить | Правка | Наверх | Cообщить модератору

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

Это всё субъективно. Вон то про кеш - оно не зависит от наших убеждений. То есть инициализация переменных оправдана, как оптимизация по скорости. :)

Ответить | Правка | Наверх | Cообщить модератору

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

521. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 01-Июл-22, 00:10 
> Пока в Вилларибе дрочат на такты и дебажат код в поисках мемори
> лика, в Виллабаджо уже завезли многопроцессорность.

Если ты так развлечешься в кернеле, вероятно, ты еще и не так потом будешь др@чить в дебаге внезапно падающего кернела.

Ответить | Правка | Наверх | Cообщить модератору

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

Ништяк. А то этот пакет в генте иногда напоминает маньяка своим упорным стремлением прописаться в мир.

Ответить | Правка | Наверх | Cообщить модератору

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

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

177. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –1 +/–
Сообщение от Аноним (149), 22-Июн-22, 18:39 
> Нафиг раст? Надо просто пользоваться

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

206. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +3 +/–
Сообщение от Bdfybec (?), 22-Июн-22, 22:09 
Аналогия не твой конёк.
Ответить | Правка | Наверх | Cообщить модератору

223. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (46), 22-Июн-22, 23:14 
> плёночным фотоаппаратом

Не поверишь, до сих пор есть студии проявки киноплёнки... Да, её используют профессионалы.

Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

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

302. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (154), 23-Июн-22, 16:51 
Я так понимаю, ты из тех, кто уже купил электрокар с автопилотом и во время езды ...

книжки читает?

Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

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

354. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (154), 24-Июн-22, 13:40 
> Ты хочешь сказать что индусам из мелланокса, которые из сетевого драйвера общий slab портят, доверия больше?

Такие виды ошибки лекго отлавливаются.

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

Для их отлова нужно интенсивное использование в других - более простых проектах.

Отсюда вопрос, сколько времени должно будет пройти пред внедрением новой версии компилятора rust в ядро, если он практически нигде не используется?

Ответить | Правка | Наверх | Cообщить модератору

416. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Ананимус (?), 25-Июн-22, 22:49 
> Такие виды ошибки лекго отлавливаются.

Супер, отлови пожалуйста. А то её уже полтора года отловить не могут. Стектрейс скинуть?

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Это ты так решил, что не сделает? И какие у тебя для таких заявлений основания?

Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

362. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Анонимemail (362), 24-Июн-22, 17:17 
Пруфов, как всегда не будет, да?
Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

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

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

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

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

207. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от ilowryemail (?), 22-Июн-22, 22:12 
Будет теперь инклюзивное ядро.
Ответить | Правка | Наверх | Cообщить модератору

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

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

256. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (258), 23-Июн-22, 11:16 
> не исключил возможность

Это надо срочно в новость!

Ответить | Правка | Наверх | Cообщить модератору

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

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

328. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от warlock66613email (ok), 23-Июн-22, 23:33 
Вам ответить отвлечённо или прагматично?

Потому что на Rust приятно писать код. А на SPARK упорешься. Потому что Rust как современный язык отвечает требованиям, предъявляемым современному языку (репозиторий пакетов, вменяемая система сборки, избавление программиста от обезъяньей работы вроде копипаста заголовков методов в интерфейсную часть модуля, и др.), а SPARK — штука древняя. Потому что Rust целенаправленно создавался и создаётся под подобные задачи, и из коробки имеет достойный FFI с Си.

Потому что есть инициативная группа (и более широкая масса менее инициативных сочуствующих), желающая видеть Rust в ядре, а для SPARK такой группы не собралось.

Ответить | Правка | Наверх | Cообщить модератору

381. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –1 +/–
Сообщение от Аноним (381), 25-Июн-22, 03:38 
> репозиторий пакетов, вменяемая система сборки

Прямо перечислил априори не нужное

> избавление программиста от работы головой

Фиксанул, не благодари

Ответить | Правка | Наверх | Cообщить модератору

387. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (358), 25-Июн-22, 10:22 
>> избавление программиста от работы головой
> Фиксанул, не благодари

Как что-то плохое. Хотя страх всяких сишников можно понять, ведь повторяется история с станками жаккара.

Ответить | Правка | Наверх | Cообщить модератору

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

Ага, репы контролирует "некомерческий" фаундейшн с некоммерческими директорами из амазона, гугла и майкрософта. И вот это уже выглядит как годная заявка на сдачу им в рабство. Почему-то. Хотя белый человек так то давно просек что папуас на бусы ведется и активно пользовался...

Ответить | Правка | Наверх | Cообщить модератору

532. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –1 +/–
Сообщение от Аноним (532), 06-Окт-22, 13:05 
> Потому что на Rust приятно писать код.

Ну ты и Петросян!

Ответить | Правка | К родителю #328 | Наверх | Cообщить модератору

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

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

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

340. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от yet another anonymous (?), 24-Июн-22, 07:47 
s/SPARK/Rust/g

И что, что-то по сути поменялось в месседже?

Ответить | Правка | Наверх | Cообщить модератору

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

359. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –1 +/–
Сообщение от Аноним (154), 24-Июн-22, 14:35 
> Если думать не головой, а задницей, то нет.

Ну так покажи эту разницу тем, кто думает задницей...

Или ты то же из таких?

Ответить | Правка | Наверх | Cообщить модератору

360. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Анончик (?), 24-Июн-22, 14:48 
А то! 4.332
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

401. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Анлним (?), 25-Июн-22, 18:53 
Ответ: массового заказчика нет.

SPARK уже занял свою нишу. Заказчик должен платить за надежность, безопасность и верифицируемость ПО.

Есть надежная, безопасная и верифицируемая ОС: https://muen.sk

Кажется стандарт в гражданской авиации. Даже в РФ бортовое ПО на ADA-SPARK пишут?

Кроме атомной энергетики, военные SPARK любят в своих АСУ.

Сегодня просто уникальный исторический момент. Прошло около 45 лет со дня заказа разработки этого языка программирования, сменилось несколько поколений программистов и на конец в GNU смогли написать свободный компилятор RUST. Вхождение в мир надежного, безопасного и верифицируемость ПО стоит не десятки миллиардов долларов, а 0.0$

Я категорически против зоопарка. Убежден, что Linux должен писался на C и ASM, как это было изначально. А добавление любого другого языка в ядро Linux только запустить его, затруднит поддержку и использование. А конкретно Rust вместо безопасности добавит новые классы уязвимостей.

Ответить | Правка | Наверх | Cообщить модератору

407. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от burjui (ok), 25-Июн-22, 20:03 
>Вхождение в мир надежного, безопасного и верифицируемость ПО стоит не десятки миллиардов долларов, а 0.0$

Из крайности - в крайность. Типичный опеннетный эксперт.
>0.0$

Это если не писать контракты в том же SPARK. Правда, тогда и код не скомпилируется. А контрактов придётся писать больше, чем кода. Так что совсем не 0$.
> А конкретно Rust вместо безопасности добавит новые классы уязвимостей.

На каком основании вы сделали такой вывод?

Ответить | Правка | Наверх | Cообщить модератору

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ообщить модератору

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

522. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 01-Июл-22, 00:13 
> Вы так и не привели ни одного примера "новых классов уязвимостей", которые
> якобы привнесёт именно Rust.

Кодер подумал что безопасТно и забил на использование мозга. Маркетологи гамадрила корп сказали же что безопасТно!

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

376. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от yet another anonymous (?), 24-Июн-22, 23:50 
Там продвигаются более интернсные вещи, хотя на них обращают внимание сильно меньше. Это
   - сборочная система
   - легкий update компилятора
   - пакетная система с автоподгрузкой из сетки by demand в процессе сборки

Демпфировать это, в принципе, можно, но en masse это неустранимо (см. npm, pip, доустановка deb-пакетов на лету в CI, аналогичное подтягивание docker'ов, ...).

Ответить | Правка | Наверх | Cообщить модератору

402. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Анлним (?), 25-Июн-22, 18:56 
> пакетная система с автоподгрузкой из сетки by demand в процессе сборки

Это смерть безопасности.

Ответить | Правка | Наверх | Cообщить модератору

523. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 01-Июл-22, 00:20 
>    - сборочная система

Лизать ботинки гугла, амазона и майкрософт с их Единственно Правильной Экосистемой - вообще баг а не фича.

>    - легкий update компилятора

Безопасным curl | sh? :) Где ремотным джентльменам верят на слово.

>    - пакетная система с автоподгрузкой из сетки by demand
> в процессе сборки

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

Ответить | Правка | К родителю #376 | Наверх | Cообщить модератору

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

382. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –1 +/–
Сообщение от Аноним (381), 25-Июн-22, 03:44 
> косяк работы с памятью

Проблемы квалификации программиста, а не языка как такового. Хотя, глядя на то что творится в IT и какие макаки-гуманитарии туда идут, за будущее не страшно, т.к. выдумки о скайнете так и останутся выдумками.

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | К родителю #382 | Наверх | Cообщить модератору

404. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Анлним (?), 25-Июн-22, 19:19 
> Неужели самим непонятно, что любой потенциальный косяк работы с памятью будет локализован в этих блоках unsafe

Тебя обманули и ты вводишь в заблуждение других.

В ядро Linux, уже очень давно, лет 20 как, можно компилятором gcc собрать безопасно:
  гарантии безопасной работы с памятью получить МОЖНО!!!
  гарантии надежности НЕТ.
  автоматической математической верификации корректности на уровне исходныых текстов НЕТ.

Гарантии безопасности работы ядра Linux с памятью:
config_pax_kernexec
config_grkernsec_randstruct

Безопасность работы с памятью в ядрах некоторых UNIX, Linux, NetBSD, частично OpenBSD уже есть! И все на C. Она достигнута логически следуя правилу: все, что исполняется не должно изменятся, а что изменяется не должно исполнятся. Используя инструкции процессоров (постранично) или даже полностью софтварно (посегментно). Эксплуатация переполнения буфера невозможна! Цена использования C: невозможность дать гарантии надежности при дачи гарантий безопасности работы с памятью.

Ответить | Правка | К родителю #377 | Наверх | Cообщить модератору

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ообщить модератору

408. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от burjui (ok), 25-Июн-22, 20:14 
>> Неужели самим непонятно, что любой потенциальный косяк работы с памятью будет локализован в этих блоках unsafe
>Тебя обманули и ты вводишь в заблуждение других.

Аргументы будут или пука в лужу, по вашему мнению, достаточно?

>все, что исполняется не должно изменятся, а что изменяется не должно исполнятся.

Такой способ безопасной работы с памятью не бесплатен, а имеет накладные расходы во время выполнения кода, в отличие от статической верификации.

Ответить | Правка | К родителю #404 | Наверх | Cообщить модератору

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ообщить модератору

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

Здесь был неправ, признаю.

Тем не менее, от некорректного обращения к памяти эта технология не защищает. Она защищает от последствий некорректного обращения к памяти - то есть, вместо того, чтобы дать прочитать мусор или переписать адрес возврата, сгенерирует аппаратное исключение, а ОС, скорее всего, грохнет процесс. То есть, код по-прежнему может попытаться прочитать мусор или переполнить буфер, после чего упасть. При статической же проверке некорректных обращений к памяти вовсе не будет.

Ответить | Правка | Наверх | Cообщить модератору

423. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (423), 26-Июн-22, 11:13 
> Тем не менее, от некорректного обращения к памяти эта технология не защищает. Она защищает от последствий некорректного обращения к памяти - то есть, вместо того, чтобы дать прочитать мусор или переписать адрес возврата, сгенерирует аппаратное исключение, а ОС, скорее всего, грохнет процесс. То есть, код по-прежнему может попытаться прочитать мусор или переполнить буфер, после чего упасть.

Там есть разные варианты в разных ситуациях:

1. Не убивать процессы, а только логировать ошибки.

2. Убивать процессы и логировать ошибки.

3. Убить ВСЕ процесы пользователя, запретить создание новых и логировать ошибки.

4. При угрозе изменения логов с ошибками, убивать все процесы и само ядро ОС, для сохранения лога.

> При статической же проверке некорректных обращений к памяти вовсе не будет.

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

Заметь, технология практичной защиты, обеспечила гарантии безопасности ОС, не допустила эксплуатации некорректного обращения к памяти, и способствовала передачи в логах необходимой информации программисту, для локализации и устранения ошибки в программе. А вот надежности работы программы не дает!

Ответить | Правка | Наверх | Cообщить модератору

453. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от burjui (ok), 26-Июн-22, 13:17 
> А вот надежности работы программы не дает!

И правильно, кому она нужна? Главное - уязвимостей нет, а то что прога падает - так это проблемы пользователя, поэтому будем фанатично упираться и продолжать писать на C. Лучше пожертвуем пользователем, но на Rust принципиально писать не будем.

Ответить | Правка | К родителю #423 | Наверх | Cообщить модератору

477. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (477), 26-Июн-22, 19:52 
> уязвимостей нет,

Уязвимость есть они никуда не денутся. Криворукий сишник таки ошибку сделал. Благодаря проактивной защите реализованной в ОС и процессоре, бажную прогу убили и записали лог о ошибке.

> а то что прога падает - так это проблемы пользователя,

Да. Сишники, когда им лог падения высылаешь и пальцем показываешь на баг, иногда с патчем, так и говорят,- да пошли вы со своими проблемами и вашей "проактивной защитой"...

> на Rust принципиально писать не будем.

Я стал противником go и по инерции Rust когда увидел список зависимостей к ipfs, при компиляции мне с инета начало тянуть >1200 никем не подписаных пакетов. Также считаю Rust в ядре Linux неуместным, пусть оно остается на C и ASM.

Ответить | Правка | К родителю #453 | Наверх | Cообщить модератору

411. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Анлним (?), 25-Июн-22, 21:03 
Узри саму убогость и ущербность идеи Rust иметь частичную (ибо есть unsave) проверку во время сборки только для одной программы написанные на Rust, по сравнению с глобальной гарантией корректности и безопасности работы с памятью всех программ без любых исключений (включая даже блоки unsave) от ядра ОС и процессора. И без любых накладных расходов для x86_64.

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

Незыблимый принцип безопасности:

ГАРАНТИИ защиты и корректности работы с памятью дает ядро ОС с процессором. А не аккуратность програмиста, продвинутость компилятора (хотя это тоже очень важно) или какой-то очередной ЯП.

Да, у технологии Проактивной безопасности есть цена - отсутствие гарантий надежности работы программы. И на сегодня единственным рабочим вариантом дающим математически доказанные гарантии надежности и безопасности на уровне исходных текстов есть - SPARK.

Ответить | Правка | К родителю #408 | Наверх | Cообщить модератору

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ообщить модератору

422. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (423), 26-Июн-22, 10:49 
> Внимательно прочитал? Не defectless, а ultra-low defect. Не дают они "математическиие гарантии надёжности и безопасности", потому что это невозможно.

Имеется в ввиду ОБЩЕЕ решение "ultra-low defect".

SPARK это верификатор подмножества языка программирования ADA, дающий гарантии отсутствия ошибок и корректности работы с памятью на уровне исходных текстов. Проверяются ТОЛЬКО исходные тексты, а не запускаемые бинари.

Есть еще компилятор языка програмирования ADA, который тоже разрабатывался как высоконадежный и очень безопасный.

Незабываем о CPU с его асемблером в котором тоже иногда просачиваются ошибки.

Общие решение:

  исходный код на SPARK + компилятор языка программирования ADA + исполняющий бинарь процессор -- 100% гарантий не имеет,

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

Ответить | Правка | Наверх | Cообщить модератору

427. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от burjui (ok), 26-Июн-22, 12:28 
>100% гарантий не имеет,

Вот именно.

>Но дает достаточные гарантии для использования в бортовых системах авиации, на критических производствах, военных АСУ, а также в обеспечении государственной информационной безопасности.

Согласен, с этим я не спорю.

Впервые за долгое время дискуссия на опеннете привела к чему-то кроме уничтожения нейронов головного мозга: кто-то признал, что 100% гарантий не даст ни один ЯП без серьёзных ограничений множества возможных программ, а я узнал о новом для себя ЯП, который имеет смысл изучить хотя бы для кругозора. Это повод принести в жертву компьютерным богам содержимое /tmp.

Ответить | Правка | К родителю #422 | Наверх | Cообщить модератору

476. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (477), 26-Июн-22, 19:34 
> кто-то признал, что 100% гарантий не даст ни один ЯП

Конечно не даст. В верификаторах SPARK наверняка есть ошибки, программист может "неаккуратно что написать" и бажный верификаторах пропустит дыру. Со временем вылежут и баги.

> я узнал о новом для себя ЯП, который имеет смысл изучить хотя бы для кругозора

Мне точно известно что версия SPARK-2021 у них получилась наконец рабочая. И компилятор GNU для ADA в 2021 году так-же наконец получился рабочим и пригодным для промышленного использования. Год прошел, а я так и не решилась что-то написать, другие задачи.

Меня интересуют ответы на вопросы:

1. Насколько готовый бинарь со SPARK медленнее бинаря скомпиленого с C.

2. Задачи жесткого реального времени. В ASM и C можно рассчитать количество тактов проца необходимых для работы проги. А в SPARK  можно дать гарантии исполнения бинаря за определенное количество тактов процессора?

3. Насколько долго писать на SPARK по сравнению с C или Python? Трудозатраты?

Ответить | Правка | К родителю #427 | Наверх | Cообщить модератору

479. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от warlock66613email (ok), 26-Июн-22, 20:14 
> В ASM и C можно рассчитать количество тактов проца необходимых для работы проги.

А вот объясните, как специалист, каким образом можно рассчитать количество тактов в асм, если оно зависит как минимум от того как удачно бранч предиктор справится со своей задачей?

Ответить | Правка | К родителю #476 | Наверх | Cообщить модератору

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

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

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

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

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

Ответить | Правка | К родителю #411 | Наверх | Cообщить модератору

497. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (499), 27-Июн-22, 18:40 
> секты свидетелей прямых рук

Есть еще свидетели секты мозготраха, веруют, что он позитивно влияет на безопасность и без него ИТ безопасности не бывает.

К стати а на каком из уровней ИТ безопасности в США требуется чистка персонала?

C: DAC
B: MAC
A1: математическое доказательство корректности кода.

Ответить | Правка | Наверх | Cообщить модератору

400. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Анлним (?), 25-Июн-22, 18:28 
> Сами идите, пишите на обоих языках, а потом сравнивайте объём кода, трудозатраты и КПД своей работы.

Ты правильные вопросы задал:
  объем кода
  трудозатраты
  КПД
молодец.

Теперь в твою модель добавь следующие переменные:
  надежность (авиация, еретические производства, оборонка - сбой, падение программы неприемлемо)
  безопасность (требуется уровень не ниже A1 - математическое доказательство корректности, отсутствия ошибок и уязвимостей на уровне исходных текстов)
И перещетай заново свои критерии оценки языка:
  объем кода
  трудозатраты
  КПД
И где теперь Rust с C по сравнению со SPARK?

> А заодно подумайте, почему ни один из формально верифицируемых языков даже близко не пошёл в массы.

Это смотря кто заказчик. Массовому заказчику надо:
  быстро и дёшево
а не
  надежно, безопасно, верефицируемо.
По этому пишут на Python.

За SPARK стоит самый крутой заказчик, которому необхожим язык дающий сразу гарантии:
  надежности
  безопасности
  верефицируемости
всем написанным на нем програмам. Трудозатраты на мат верификацию исходного кода на отсутствие уязвимостей и збоев работы программы на SPARK равны 0.

Ответить | Правка | К родителю #369 | Наверх | Cообщить модератору

405. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от burjui (ok), 25-Июн-22, 19:39 
Как я и писал выше, опеннетовский эксперт не умеет читать [1] и мыслить критически [2]. А в вашем случае ещё и минимально грамотно писать [3] - это при наличии спеллчекера в браузере. Зато всё на свете знает. И правильно - зачем думать, если можно просто знать?

[1] Выше я писал: "И тебе придётся каждую строчку кода обложить пачкой контрактов, далеко не всегда тривиальных, и тебе это очень быстро надоест, потому что успеешь постареть, пока напишешь хоть какой-то функционал. Для космических аппаратов и ядерных электростанций это приемлемо, а для менее критичного софта - нет. Никто не будет ждать 2 года, пока ты напишешь супернадёжный медиаплеер."

[2] "Трудозатраты на мат верификацию исходного кода на отсутствие уязвимостей и збоев работы программы на SPARK равны 0."
Ага, а про трудозатраты на написание нескольких контрактов на одну строчку кода мы, конечно же, забудем. Видимо, компилятор сам догадается, что ты имел ввиду и напишет контракты за тебя. Только непонятно тогда, зачем нужен программист, если компилятор такой умный.

[3] Не люблю докапываться до орфографии, но это же просто ужас какой-то - "перещетай", "збоев", "верефицируемо", "програмам".

Ответить | Правка | Наверх | Cообщить модератору

409. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Анлним (?), 25-Июн-22, 20:17 
Не хами. Писал грамотно, а вражеский спелчекер поменял слова.

Вот Ыксперту по безопасной работе с памятью еще:

https://www.opennet.me/openforum/vsluhforumID3/127824.html#404
https://www.opennet.me/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ообщить модератору

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ообщить модератору

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ообщить модератору

419. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (423), 26-Июн-22, 10:33 
> поэтому компилируем функцию как обычную ADA.

Язык SPARK это верифицируемое подмножество языка программирования ADA.

SPARK своего компилятора не имеет, для компиляции программ на SPARK используется обычный компилятор ADA.

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

В автоматический верификации добавляются новые верификаторы добавляя синтаксис ADA в верифицируемое подмножество SPARK.

Ответить | Правка | К родителю #412 | Наверх | Cообщить модератору

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

Ответить | Правка | К родителю #412 | Наверх | Cообщить модератору

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

450. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 26-Июн-22, 13:16 
> Я тоже умею копипастить и знаю, что делает инструкция cli.

Я это не заметил в "Мамой клянусь, эта функция только X86_64.State меняет!".


Ответить | Правка | Наверх | Cообщить модератору

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 не гарантирует.

Ответить | Правка | К родителю #450 | Наверх | Cообщить модератору

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

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

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

474. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 18:30 
> procedure Asm (
>   Template : String;
>   Outputs  : Asm_Output_Operand_List;
>   Inputs   : Asm_Input_Operand_List;
>   Clobber  : String  := "";
>   Volatile : Boolean := False);

Что это за ужас? Это вроде не хруст? Они даже хрустиков по ужасному синтаксису сделали, с отрывом.

Ответить | Правка | К родителю #458 | Наверх | Cообщить модератору

475. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (477), 26-Июн-22, 19:01 
> Мамой клянусь ...

Не клянись, никогда, ничем.

Тем более в вопросах языка на котором здесь никто не написал ни одной строчки кода. И никто не проверял что компилятор ADA эще с этим делает.

Клястся не хорошо.

Ответить | Правка | К родителю #412 | Наверх | Cообщить модератору

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. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 27-Июн-22, 17:51 
> Эх, не тот язык выбрали добавлять в линукс

А откоменть в рассылку по приколу, если пользуешься им и можешь аргументировать? На первый взгляд Zig прикольнее хруста, но я активно им не пользовался и не смогу аргументировать на должном уровне :)

Ответить | Правка | Наверх | Cообщить модератору

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ообщить модератору

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

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

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


Ответить | Правка | Наверх | Cообщить модератору

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

У тебя проводка дома без изоляции лежит? Нет? А чо ты как лох, изоляция для слабаков которые не смотрят под ноги.

Ответить | Правка | Наверх | Cообщить модератору

524. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 01-Июл-22, 00:23 
> У тебя проводка дома без изоляции лежит? Нет? А чо ты как
> лох, изоляция для слабаков которые не смотрят под ноги.

Однако хватает и проводов без изоляции. Контактный рельс метро не очень заизолируешь на все сто. И вон ту высоковольтку - тоже. Слой изоляции больно уж непотребный надо.

Ответить | Правка | Наверх | Cообщить модератору

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

Поэтому там регулярно люди и умирают :))))

Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру