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

"Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
Сообщение от opennews (?), 01-Сен-19, 10:24
Джош Триплет (Josh Triplett),  работающий в компании Intel и входящий в комитет, курирующий развитие Crates.io, в своём выступлении на конференции Open Source Technology Summit представил (https://hub.packtpub.com/rust-is-the-future-of-systems-progr.../) рабочую группу, нацеленную на доведение языка Rust до паритета с языком Си в области системного программирования. В рабочей группе, которая находится в процессе создания,  разработчики Rust совместно с инженерами из компании Intel подготовят спецификации с определением функциональности, которую необходимо реализовать в Rust для системного программирования. Системное программирование часто требует низкоуровневых манипуляций, таких как выполнение привилегированных процессорных инструкций и получение детальных сведений о состоянии процессора. Из уже развиваемых для Rust подобных возможностей  отмечается поддержка неименованных структур, объединений (union), ассемблерных вставок (макрос "asm!") и формата чисел с плавающей запятой BFLOAT16. Джош считает, что будущее системного программирования за Rust, а язык Си в современных реалиях претендует на место, которое в прошлые годы занимал Ассемблер. Rust не только избавляет разработчиков от свойственных языку Си проблем, возникающих из-за низкоуровневой работы с памятью, но и предоставляет возможность применения при разработке современных парадигм программирования. В ходе обсуждения (https://lwn.net/Articles/797714/) выступления Джоша была высказана идея добавления в ядро Linux возможности разработки драйверов на языке Rust, что позволит с минимальными усилиями создавать безопасные и более качественные драйверы, избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.   Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за поддержку стабильной ветки ядра Linux, выразил готовность добавить в ядро фреймворк для разработки драйверов на языке Rust, если он будет обладать реальными преимуществами по сравнению с Си, например, будет предоставлять безопасные обвязки над API ядра. Кроме того, Грег рассматривает данный фреймворк только как опцию, не активную по умолчанию, чтобы не включать Rust в число сборочных зависимостей к ядру. Оказалось, что несколько команд уже работают в данном направлении. Например, разработчики из компании "Fish in a Barrel" подготовили (https://github.com/fishinabarrel/linux-kernel-module-rust) инструментарий для написания  загружаемых модулей для ядра Linux на языке Rust, используя для повышения защиты набор абстрактных прослоек над интерфейсами и структурами ядра. Прослойки автоматически генерируются на базе имеющихся заголовочных файлов ядра при помощи утилиты bindgen (https://github.com/rust-lang/rust-bindgen). Для сборки прослоек используется Clang. Собираемые модули помимо прослоек используют пакет  staticlib. Параллельно развивается (https://github.com/lizhuohua/linux-kernel-module-rust) ещё один проект, сосредоточенный на разработке драйверов для встраиваемых систем и устройств интернета вещей, который также использует  bindgen для генерации прослоек на основе заголовочных файлов ядра. Фреймворк позволяет добиться  повышения безопасности драйверов без внесения изменений в ядро  - вместо создания в ядре дополнительных уровней изоляции для драйверов, предлагается блокировать проблемы на этапе компиляции, применяя более безопасный язык Rust. Предполагается, что подобный подход может оказаться воспребован производителями оборудования,  разрабатывающими проприетарные драйверы на скорую руку  без проведения должного аудита. Не вся задуманная функциональность пока реализована, но фреймворк уже вполне пригоден для работы и использован для написания рабочего драйвера для Ethernet-контроллера LAN9512 USB, поставляемого в плате  Raspberry Pi 3. В качестве эталонной  реализации при написании  Rust-драйвера был использован существующий драйвер smsc95xx, написанный на языке Си. Отмечается, что размер модуля и накладные расходы от runtime-компонентов при разработке драйвера на Rust незначительные, что позволяет применять фреймворк для устройств с ограниченными ресурсами. URL: https://linux.slashdot.org/story/19/08/31/2138249/should-the... Новость: https://www.opennet.dev/opennews/art.shtml?num=51401
Ответить | Правка | Cообщить модератору

Сообщения

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

2. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–9 +/–
Сообщение от Аноним (2), 01-Сен-19, 10:25
>BFLOAT16 И где в системном программировании растоманы видели 16-тиразрядные числа с плавающей точкой? А также где он видели соответствующе аппаратные ускорители?
Ответить | Правка | Наверх | Cообщить модератору

	40. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+12 +/–
	Сообщение от Аноним84701 (ok), 01-Сен-19, 12:14
	>> BFLOAT16 > И где в системном программировании растоманы видели 16-тиразрядные числа с плавающей точкой? > А также где он видели соответствующе аппаратные ускорители? Наверное, вне криокамеры? > The bfloat16 format is utilized in upcoming Intel AI processors, such as Nervana NNP-L1000, Xeon processors, and Intel FPGAs,[2][3][4] Google Cloud TPUs,[5][6][7] and TensorFlow.[7][8] Arm Neon and SVE also supports bfloat16 format.[9] (c) wikipedia Можно ведь догадаться из контекста ("работающий в компании Intel") или хотя бы пробежать глазами оригинал: > BFLOAT16 support into Rust > Many Intel processors including Xeon Scalable ‘Cooper Lake-SP’ now support BFLOAT16, a new floating-point format. > This truncated 16-bit version of the 32-bit IEEE 754 single-precision floating-point format was mainly designed for deep learning. > This format is also used in machine learning libraries like Tensorflow that work with huge datasets.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Ю.Т. (?), 01-Сен-19, 12:26
	Не смотрел, но предполагаю: обычный float с 16 десятичными знаками. А что, в системном программировании запрещено использовать вещественные числа?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	51. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (51), 01-Сен-19, 12:36
	Возможно, имелось в виду, что в ядре FPU и всяческие векторные инструкции не юзаются, чтоб не тратить ресурсы на сохранение контекста (за редкими исключениями вроде криптографии)
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 01-Сен-19, 15:08
	float и любые другие похожие числа не вещественные.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	138. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
	Сообщение от asdasdasd (?), 01-Сен-19, 20:52
	Математики проснулись? XD
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (223), 02-Сен-19, 23:10
	> float и любые другие похожие числа не вещественные. И не (обязательно) числа.
	Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

	189. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от fi2fi (?), 02-Сен-19, 11:47
	может тут Intel FPGAs???
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+3 +/–
Сообщение от zo0M (ok), 01-Сен-19, 10:26
Ржавчина распространяется, радует)
Ответить | Правка | Наверх | Cообщить модератору

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

	30. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–2 +/–
	Сообщение от burjui (ok), 01-Сен-19, 11:37
	Rust даже с unsafe намного лучше C
	Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

	32. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от заминированный тапок (?), 01-Сен-19, 11:48
	судя по всему, opennet тоже на раст переписан :D
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (253), 16-Мрт-20, 11:33
	Скорей тогда уж - на ассемблере. Но, это/оптимзированность и компактность нужные вкупе для формата комментариев - главный же его плюс, в т.ч.в ср.с ЛОР с почти нечитабельными своей несвязанностью комментариями и многостраничностью. Если бы не цензура просто противозаконного уровня, начиная с моего ника, вообще был бы идеал, а так что есть, т.б.что кому сказать нечего - того же и небанят/незачищают тут.
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от заминированный тапок (ok), 16-Мрт-20, 13:43
	реплика была не на тему чёткости опенета а на тему любви его анонов к расту
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (257), 16-Мрт-20, 19:37
	Это то - на здоровье... Но, ведь не все. Не все. Ну и на сайте, да всё же есть она проблемка неизлечимая похоже - в головах админов (может на Brainfuck слепивших реально сайт?) - позорнейшая невозможность правки своих же сообщений безаакаунтно, хотя бы пока IP не сменился или Cookies там(хоть у меня выклченны они, и IP сам меняется, падлой провайдером - чтобы деньги доп-но брать ещё и за стабильность динамического IP...), но всё же было бы лучше чем ничего. А то приходится и самому оставлять и другим тоже опечатки всякие. В итоге, часто перечитываешь и сам ужасаешься - я же это только что вычитавал перед отправкой! А, часто бывает особенно невыспавшись или к вечеру [пока напишешь] - уже сил нет дописывать, не то что вычитывать, тем более и клавиатура сама - то ненажмётся, то наоборот отошлёт чего не жал, не говоря про уже мимо, иногда так что весь текст теряется, так что приходится доп-но спешить оттослать. А, глянешь затем - а, там... И неисправишь уже, ну не маразм?...
	Ответить | Правка | Наверх | Cообщить модератору

	258. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от заминированный тапок (ok), 17-Мрт-20, 10:30
	>[оверквотинг удален] > брать ещё и за стабильность динамического IP...), > но всё же было бы лучше чем ничего. > А то приходится и самому оставлять и другим тоже опечатки всякие. В > итоге, часто перечитываешь и сам ужасаешься - я же это только > что вычитавал перед отправкой! А, часто бывает особенно невыспавшись или к > вечеру [пока напишешь] - уже сил нет дописывать, не то что > вычитывать, тем более и клавиатура сама - то ненажмётся, то наоборот > отошлёт чего не жал, не говоря про уже мимо, иногда так > что весь текст теряется, так что приходится доп-но спешить оттослать. А, > глянешь затем - а, там... И неисправишь уже, ну не маразм?... всё верно, что написано пером (или напечатно на форуме), то не вырубишь топором а первая опечЯтка дороже второй
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (183), 02-Сен-19, 11:20
	чем? если писать что-то для ядра, то ты почти всегда пишешь unsafe
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	200. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Wilem (?), 02-Сен-19, 14:49
	Есть такая штука - переиспользование кода. С unsafe ты пишешь что-то базовое, хорошо тестируешь, а потом делаешь надстройки поверх, без unsafe. Так весь растовый stdlib построен. Есть например проект, где на расте пилят операционку с нуля в формате блога - https://os.phil-opp.com/ , и там далеко не всё unsafe. Также есть куча библиотек-драйверов для embedded устройств, построенных поверх unsafe-кода и в них unsafe практически нет, например https://github.com/japaric/l3gd20/blob/master/src/lib.rs.
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (254), 16-Мрт-20, 11:48
	Rust это ниасилятором Си, включая его грабли как dumbtest, (да и в Rust есть полезное, но их 1 может 2 и то недоработанные так - что нафиг! за то вредных фич - куча... А, синтаксис - хуже BASIC'a из самых первых версий в ч.н. с префиксами, номеров строк только не хватает дл полноты :] ну так и в BASIC давно их их, а тот намного приятней... и для новичков - несравнимо проще. - тогда смысл делать УберBASIC-2 под С++, но с извратским синтаксисом, ещё и теряющим совместимость с BASIC) и такое ощущение что он и направлен именно на BASICовцнев[на микроконтроллерах прежде всего] и может C#ников (но и тут без вариантов по кр.мере массово), и т.б.реальным системным программистам т.е.Сяшникам т.е.даже не С++сникам(в смысле - с гуаноклассами алгоритмов, чужих+вечно баговых и лаговых) - на нём делать просто нечего. И дело тут вовсе не только в синтаксисе, а в рациональности. А, так - и на C# уже писались ОС, где они все теперь... Так и тут будет.
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от burjui (ok), 02-Сен-19, 16:44
	> чем? borrow checker, move semantics, ADT (Enum), pattern matching, generics Да хотя бы этим. Пожалуй, если начну перечислять каждое преимущество Rust над C, случайно напишу ещё одну Rust Book, только хуже.
	Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

	245. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Аноним (245), 04-Сен-19, 01:19
	Пока что ты написал типовой список баззвордов.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от имя (ok), 04-Сен-19, 02:20
	> ADT > pattern matching > типовой список баззвордов Вы всё ещё собираете-разбираете tagged union руками, с ручной копипастой, например, else if (s.type = JSON_ARRAY) или else if (s instanceof JSONArray) ? Хотя о чём это я, на опеннете ведь кроме суровых энтерпрайзников и программистов GNOME никого нет…
	Ответить | Правка | Наверх | Cообщить модератору

	249. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от burjui (ok), 04-Сен-19, 21:36
	> Пока что ты написал типовой список баззвордов. Аргумент, достойный высоко просвещённого мыслителя. Ну да, сложно спорить, когда не понимаешь смысл "баззвордов". С такими аргументами, как у вас, я бы вам посоветовал разыменовать указатель на всем известное направление (гугл).
	Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

	43. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
	Сообщение от user90 (?), 01-Сен-19, 12:23
	Энтропия, приятель. В запущенных случаях, без должного ТО все гниет и ржавеет..
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	255. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (255), 16-Мрт-20, 11:51
	без должного и штрафующего стороннего ТО
	Ответить | Правка | Наверх | Cообщить модератору

	240. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+4 +/–
	Сообщение от Аноним (240), 03-Сен-19, 14:02
	>Ржавчина распространяется Нужно антикоррозийное средство.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	246. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+3 +/–
	Сообщение от Аноним (245), 04-Сен-19, 01:19
	Палец линуса.
	Ответить | Правка | Наверх | Cообщить модератору

4. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
Сообщение от Аноним_t (?), 01-Сен-19, 10:26
> В качестве эталонной реализации при написании Rust-драйвера был использован существующий драйвер smsc95xx, написанный на языке Си. Даже здесь не смогли написать сами, а как всегда - "переписали". Интересно, это свойство языка или свойство программистов на этом языке?
Ответить | Правка | Наверх | Cообщить модератору

	11. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (11), 01-Сен-19, 10:37
	А что такого? Более чем нормально переписать с языка, где половина разработки - борьба с самим языком, его дырами, утечками, ub и т.д.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от заминированный тапок (?), 01-Сен-19, 11:32
	>Более чем нормально переписать с языка, где половина разработки - борьба разработчика с самим собой, его дырами, криворукостью, ub и т.д.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+4 +/–
	Сообщение от имя (ok), 01-Сен-19, 19:17
	А вот и внимательные гении без единого double free в огромном хелоу-ворлде подошли.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от аноним3 (?), 01-Сен-19, 20:28
	они все думают что их инструмент единственно верный. и не понеимают того , что ключь на 10 не нужно сравнивать с разводным)))
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Урри (?), 02-Сен-19, 09:21
	Для неосиляторов и макак давно придуманы удобные библиотеки. Например, https://github.com/Snaipe/libcsptr
	Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

	173. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+3 +/–
	Сообщение от имя (ok), 02-Сен-19, 10:23
	> smart struct log_file *log = unique_ptr(struct log_file, { .fd = … }, cleanup_log_file); > void cleanup_log_file(void *ptr, void *meta) { close(((struct log_file *) ptr)->fd); } Ну ооооочень удобные библиотеки. Кому там ржавые закорючки не нравились? И, к слову, ни одного примера с передачей владения в вызываемую функцию.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Совершенно другой аноним (?), 02-Сен-19, 10:37
	>> smart struct log_file *log = unique_ptr(struct log_file, { .fd = … }, cleanup_log_file); >> void cleanup_log_file(void *ptr, void *meta) { close(((struct log_file *) ptr)->fd); } > Ну ооооочень удобные библиотеки. Кому там ржавые закорючки не нравились? Посмотрите APR, это которая Apache Portable Runtime, ну это если мы про C.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Аноним (152), 02-Сен-19, 03:11
	Печально, что жалкие людишки не подходят для написания кода на этом великолепном ЯП.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	247. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от draw1 (?), 04-Сен-19, 02:01
	Жалкие людишки, в базовой комплектации, вообще мало для чего подходят. Но обучение и практика, и, как следствие, знания и опыт (в это сложно, наверное, будет поверить) творят прям чудеса (включая rocket science, не говоря уж про какие бы то ни было ЯП).
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+6 +/–
	Сообщение от Аноним (12), 01-Сен-19, 10:39
	так здесь наоборот, позволит сравнить пригодность языка для подобных задач эсть наглядный и рабочий "эталон", а не конь в вакууме
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	201. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Wilem (?), 02-Сен-19, 14:52
	Это демонстрация того, что оно работает. Что бы показать, что что-то работает правильно, надо иметь эталон для сравнения. И вот непонимание таких очевидных вещей - это свойство не языка, а комментаторов не имеющих отношения не то, что к разработке, а даже к здравому смыслу.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

7. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+8 +/–
Сообщение от Аноним (-), 01-Сен-19, 10:33
> Джош считает, что будущее системного программирования за Rust > а язык Си в современных реалиях претендует на место, которое в > прошлые годы занимал Ассемблер. Скорее всего соглашусь, но, опять же, это дело достаточно отдалённого будущего. Через 8-9 лет, это в лучшем случаем. В худшем случае (если индустрия и энтерпрайз будут со скрипом переходить на новый язык) раст может никогда и не заменить чистый си - у этих двух языков может быть своего рода паритет. Ассемблер, да, очень специальный язык. Он всегда будет, но будет лишь в необходимой минимальной мере. И вообще мы слишком завязаны на корпорациях. Если _тебе_, программист, нравится тот или иной язык, тебе должно быть фиолетово на какие-то там тенденции - ты просто пишешь на том языке, который любишь.
Ответить | Правка | Наверх | Cообщить модератору

	14. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+15 +/–
	Сообщение от Аноним (14), 01-Сен-19, 10:49
	> тебе должно быть фиолетово на какие-то там тенденции - ты просто пишешь на том языке, который любишь О, уже безусловный базовый доход ввели, а я и пропустил.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+8 +/–
	Сообщение от Аноним (28), 01-Сен-19, 11:35
	Анон, не все готовы продать душу за лишний динар, как ты. Кое-кто может что-то делать и для души, как говорится, ради удовольствия.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от пох. (?), 01-Сен-19, 21:42
	а детей твоих кормить кто будет - штандартенфюрер?! "для души" хорошо работать, пока ты не закончил универ по курсу гендерных штудий (если злой препод нагружает заданиями - надо пожаловаться на харасмент и анэквалити)
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+5 +/–
	Сообщение от Штандартенфюрер (?), 02-Сен-19, 06:50
	Аргумент так себе. Потому что нет такого преступления, которое человек не попытался бы оправдать необходимостью кормить своих детей. Это никогда им не помогает, но они пытаются снова и снова.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от пох. (?), 02-Сен-19, 11:01
	да неважно, детей или себя самого - важно что жрать все хотят. И никакого способа кроме ежедневного офисного рабства в общем-то для получения этого жрат не придумано. "и хрен вы меня найдете" удается на самом деле единицам, да и те часто через пару лет возвращаются изрядно пощипанными и поджав огрызок откусанного хвоста
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (194), 02-Сен-19, 12:06
	не понимаю что мешает на работе на одном языке для себя на другом если желание есть и хобби такое.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от пох. (?), 02-Сен-19, 13:12
	то что когда начинается работа за жрат - никакого "для себя" уже, к сожалению, не остается. По краней мере, последние десять лет. Ну то есть хеловорд ты еще в режиме хобби осилишь, а драйвер необычной железки - вряд ли. Что, собственно, все происходящее в мире открытого софта и показывает. Нет больше ни разработчиков не на подсосе у корпораций, ни независимых проектов-хобби уровня хотя бы того же sqlite. Одни школьные поделки (и то стараются в "summer of code" проскочить, чтоб гугль кормил)
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Anonymoustus (ok), 02-Сен-19, 18:07
	> то что когда начинается работа за жрат - никакого "для себя" уже, > к сожалению, не остается. По краней мере, последние десять лет. > Ну то есть хеловорд ты еще в режиме хобби осилишь, а драйвер > необычной железки - вряд ли. Что, собственно, все происходящее в мире > открытого софта и показывает. Нет больше ни разработчиков не на подсосе > у корпораций, ни независимых проектов-хобби уровня хотя бы того же sqlite. > Одни школьные поделки (и то стараются в "summer of code" проскочить, > чтоб гугль кормил) Ты не вполне прав. Dlang — самый что ни на есть проект-хобби уровня <подставьте_ваше_любимое>. Из-за отсутствия его стандартизации и широкой поддержки со стороны бизнесов он как раз попадает в категорию независимых любительских проектов.
	Ответить | Правка | Наверх | Cообщить модератору

	229. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
	Сообщение от Аноним (229), 03-Сен-19, 05:22
	Не был в офисе уже 12 лет, на доход не жалуюсь, зарабатываю программированием. Что я делаю не так?
	Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

	235. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от пох. (?), 03-Сен-19, 11:47
	> Не был в офисе уже 12 лет, на доход не жалуюсь, зарабатываю > программированием. Что я делаю не так? сказки рассказываешь, вот что не так. а не жаловаться - это молодец, не жалуйся и дальше.
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (-), 03-Сен-19, 16:10
	Ну я 5 лет там не был, но оно когда как - бывает, что зарабатываю ощутимо меньше офисосидельцев. Хотя ну и что.
	Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

	203. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Wilem (?), 02-Сен-19, 14:57
	> О, уже безусловный базовый доход ввели, а я и пропустил. Валидный аргумент, и в этом смысле непросто - вакансий на раст мало. Но. Я например завтра иду на собеседование на фул-тайм писать на расте. Микросервисы и embedded. И это в небольшом городе. Полагаю, в Москве или крупных европейских городах с этим ещё лучше. Хотя про вакансии на раст есть одна оговорка. Их может быть мало, но это не значит, что на нём не пишут внутри компаний (а на нём пишут) потому, что на него переходят программисты, которые уже в штате, и нужды кого-то тащить извне особо нет. Что правильно. Если у тебя есть толковые инженеры, они на чём угодно смогут, если посчитают это разумным.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	61. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
	Сообщение от Аноним (61), 01-Сен-19, 12:56
	Си это удобный ассемблер.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	65. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от Anonymoustus (ok), 01-Сен-19, 13:12
	> Си это удобный ассемблер. Си ни в каком виде не ассемблер. Небось вычитал где-то красивую метафору и понравилась? Си _был_ чем-то вроде макроассемблера для системы команд PDP, но для других архитектур он ничем принципиально не отличается от прочих языков. Яблоки в своё время вообще сделали системным языком объектный Паскаль с музыкой и танцами — и ничего.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Аноним (99), 01-Сен-19, 15:14
	> Си это удобный ассемблер. Знаю, как удобно написать на С команду cvttsd2si. А как написать cvtsd2si -- не знаю.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

8. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+6 +/–
Сообщение от Hellraiser (??), 01-Сен-19, 10:34
вот чем оказывается занимаются в штеуде вместо фикса уязвимостей в их процах
Ответить | Правка | Наверх | Cообщить модератору

	10. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+8 +/–
	Сообщение от Аноним (10), 01-Сен-19, 10:36
	Ты обнаглел гой. Чтоб барин что там исправлял. Побежал покупать новый процессор на 3% быстрее прошлого поколения
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+5 +/–
	Сообщение от Аноним (68), 01-Сен-19, 13:35
	> На 3% медленнее с новым Intel ME и свежим спектром. Fixed.
	Ответить | Правка | Наверх | Cообщить модератору

16. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
Сообщение от Аноним (16), 01-Сен-19, 11:10
>более качественные драйверы, избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера   строго говоря, в самом расте выше перечисленное достигается не с помощью какой-то особой магии, а например тупо рантайм-проверками в выражениях вроде "a[i]". Переходить ради такого на новый язык, в котором к тому же из всех архитектур полноценная поддержка есть только у x86? Сильно сомневаюсь. Раст пилится не как язык системного программирования, а как замена C++ в браузерах и прочем юзерспейсе. На нишу Си он претендовать не может (в обозримом будущем)
Ответить | Правка | Наверх | Cообщить модератору

	21. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от Аноним (223), 01-Сен-19, 11:20
	> Переходить ради такого на новый язык, в котором к тому же из всех архитектур полноценная поддержка есть только у x86? А в чём проблема с другими архитектурами? Он же на LLVM. Впрочем, автора «инициативы» ввиду места работы другие архитектуры и не волнуют.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+7 +/–
	Сообщение от Илья (??), 01-Сен-19, 11:51
	> строго говоря, в самом расте выше перечисленное достигается не с помощью какой-то особой магии, а например тупо рантайм-проверками в выражениях вроде "a[i]". Есть проверки в рантайме, а так же есть статический анализатор, "борроу-чекер". Например, анализатор не даст вам разделить какую-нибудь область памяти между двумя потоками, пока вы явно не дадите слово пацана за то, что вы предусмотрели все возможные последствия. Вы не сможете создать две мутабельные ссылки на какой-нибудь участок памяти без явного заворачивания их в какой-нибудь <Arc<Mutex<...>>>.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	36. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от JL2001 (ok), 01-Сен-19, 12:07
	> Например, анализатор не даст вам разделить какую-нибудь область памяти между двумя потоками, > пока вы явно не дадите слово пацана за то, что вы > предусмотрели все возможные последствия. и много то слово пацана стоит? компилятор вообще не должен бы верить программисту без тридцати трёх подписей и печатей "да я понимаю что я делаю"
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от Илья (??), 01-Сен-19, 12:10
	Ну так и есть вообще.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–2 +/–
	Сообщение от Аноним (58), 01-Сен-19, 12:46
	Если вся разница только в статическом анализаторе, то (сюрприз!) для C они тоже есть.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	63. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от red75prim (?), 01-Сен-19, 13:01
	Сюрприз! Теорема Райса. Если язык не разработан для того, чтобы обеспечивать, скажем, отсутсвие висящих указателей, то статический анализатор сможет отловить только какие-то частные случаи, или отловить всё, но при этом выдавать и false positives.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–8 +/–
	Сообщение от Аноним (28), 01-Сен-19, 14:01
	> Сюрприз! Теорема Райса. Сюрприз! Это теорема из _теории_ алгоритмов. То есть это теория, а не истина. Слышал о теории большого взрыва? Часть физиков её принимает, часть физиков нет. Понимаешь? Каждые N столетий те или иные теории могут подвергнуться опровержению. Таким образом мы не можем в споре аппелировать к теореме Райса, как к конечной истине. Это всего лишь одна из _интерпретаций_ рельности. В рамках своей интерпретации ты прав абсолютно! В рамках теории Большого взрыва ты прав абсолютно! Но в рамках теории космологической модели эволюции крупномасштабных структур ты неправ. Так как же ты можешь быть неправ в рамках неевклидовой геометрии.
	Ответить | Правка | Наверх | Cообщить модератору

	84. Скрыто модератором	+/–
	Сообщение от Аноним84701 (ok), 01-Сен-19, 14:38
	>> Сюрприз! Теорема Райса. > Сюрприз! Это теорема из _теории_ алгоритмов. То есть это теория, а не истина. > Слышал о теории большого взрыва? Успокойтесь, приложите лед к пострадавшей части тела, откройте словарь и посмотрите значения слов "теория" и "теорема". > Часть физиков её принимает, часть физиков нет. Понимаешь? Каждые N столетий те или иные теории могут > подвергнуться опровержению. Таким образом мы не можем в споре аппелировать к > теореме Райса, как к конечной истине. Еще раз посмотрите внимательно в словарь: https://en.wikipedia.org/wiki/Rice%27s_theorem#Proof_by...'s_recursion_theorem https://en.wikipedia.org/wiki/Rice%27s_theorem#Proof_by...
	Ответить | Правка | Наверх | Cообщить модератору

	89. Скрыто модератором	–1 +/–
	Сообщение от Anonymoustus (ok), 01-Сен-19, 14:47
	> откройте словарь и посмотрите значения > слов "теория" и "теорема". Это было жестоко, но красиво!
	Ответить | Правка | Наверх | Cообщить модератору

	91. Скрыто модератором	–4 +/–
	Сообщение от nox. (?), 01-Сен-19, 14:54
	>[оверквотинг удален] >> Сюрприз! Это теорема из _теории_ алгоритмов. То есть это теория, а не истина. >> Слышал о теории большого взрыва? > Успокойтесь, приложите лед к пострадавшей части тела, откройте словарь и посмотрите значения > слов "теория" и "теорема". >> Часть физиков её принимает, часть физиков нет. Понимаешь? Каждые N столетий те или иные теории могут >> подвергнуться опровержению. Таким образом мы не можем в споре аппелировать к >> теореме Райса, как к конечной истине. > Еще раз посмотрите внимательно в словарь: > https://en.wikipedia.org/wiki/Rice%27s_theorem#Proof_by...'s_recursion_theorem > https://en.wikipedia.org/wiki/Rice%27s_theorem#Proof_by... чувак, ты это... если обосрaлся, то прими это как должное. хватить хeрнeй заниматься, будь мужиком.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	95. Скрыто модератором	+/–
	Сообщение от Аноним84701 (ok), 01-Сен-19, 15:09
	> чувак, ты это... если обосрaлся, то прими это как должное. хватить хeрнeй > заниматься, будь мужиком. Кто и где? Ты опять читаешь между строк и додумываешь? ЗЫ: чей-то ты странный какой-то. пох такой керней обычно не мается. Кстати, вообще-то пох это пох (русскими буквами П О Х) а не N O X и ты https://www.opennet.dev/~nox. совсем-совсем не палишься опять на самовосхвалении :) Ниче, бывает.
	Ответить | Правка | Наверх | Cообщить модератору

	92. Скрыто модератором	+/–
	Сообщение от nox. (?), 01-Сен-19, 14:59
	Аноним84701, кестати, это не тебя вчера овнили в топике про i2p? если это ты, то всё понятно
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	98. Скрыто модератором	+/–
	Сообщение от Аноним84701 (ok), 01-Сен-19, 15:11
	> Аноним84701, кестати, это не тебя вчера овнили в топике про i2p? если это ты, то всё понятно В смысле, "овнили" == грозились вычислить меня по айпи и прислать товарища майора, брызгали слюной и обзывались, потом тихо-мирно сдулись, но так и не привели ни одного технического аргумента и проигнорировали все технические вопросы? Тогда да, "овнили". А ты случайно не тот самый, обделавшийся^W "заовнивший всех и вся" в том топике аноним, пишуший из под его ника? ЗЫ: Не зря мне формулировки показались странными. О анонимный аноним, ты совсем-совсем не палишся: https://www.opennet.dev/~nox. и https://www.opennet.dev/~%D0%CF%C8. Хотя рассказывать о том, как это низко -- писать из под чужого ника, я не буду. Судя по усердному раскидыванию минусиков и плюсиков, замены внятной аргументации  своих утверждений хамством и ad hominem -- до осознания этого ты еще не дорос.
	Ответить | Правка | Наверх | Cообщить модератору

	112. Скрыто модератором	–3 +/–
	Сообщение от Аноним (28), 01-Сен-19, 16:05
	> как это низко Согласен. Твоё поведение низкое и истеричное. Ставить себе плюсики, ставить оппоненту минусики, устраивать истерики, зачем-то давать ссылки на словарные статьи, хотя предложение очень простое было "Теорема Райса это утверждение из теории алгоритмов". Довольно простое предложение для уяснения, но наш Аноним84701 не смог выполнить процедуру чтения и восприятия. А чувачёк-то дешёвый оказался. Ещё и глупости про чужие ники. Я не могу использовать никакие ники, так как надо для это регистрироваться и иметь учётную запись. Я же просто анонимный пользователь. Обратись к модератором, может быть они тебе разъяснят что к чему.
	Ответить | Правка | Наверх | Cообщить модератору

	113. Скрыто модератором	+/–
	Сообщение от лол (?), 01-Сен-19, 16:14
	> Ещё и глупости про чужие ники. Я не могу использовать никакие ники, так как надо для > это регистрироваться и иметь учётную запись. Я же просто анонимный пользователь. И тут ты тоже обделался )))
	Ответить | Правка | Наверх | Cообщить модератору

	115. Скрыто модератором	+/–
	Сообщение от Аноним (28), 01-Сен-19, 16:27
	> И тут ты тоже обделался ))) Продолжай цирк ) У всех анонимных пользователей здесь уникальные идентификаторы. У меня 28 в этой ветке. Все сообщения под 28-м идентификатором написал лично я. Могу продолжить лекцию о том, как работает опеннет - специально для клоунов.
	Ответить | Правка | Наверх | Cообщить модератору

	121. Скрыто модератором	+1 +/–
	Сообщение от кек (?), 01-Сен-19, 16:43
	> Продолжай цирк ) У всех анонимных пользователей здесь уникальные идентификаторы. У меня 28 в этой ветке. Все сообщения под 28-м идентификатором написал лично я. > Могу продолжить лекцию о том, как работает опеннет - специально для клоунов. http://wiki.opennet.ru/ForumHelp > Иконки рядом с именем участника > (ok) - сообщение от зарегистрированного участника; > (?) - сообщение от не зарегистрированного участника; > (??) - сообщение с ником зарегистрированного участника, но добавленное без авторизации > (-) - анонимный аноним, например, использующий Tor. > (номер) - номер первого сообщения данного анонима в обсуждении, Вот такие вот "лекции, как работает" от Знатоков и Экспертов )))
	Ответить | Правка | Наверх | Cообщить модератору

	117. Скрыто модератором	+/–
	Сообщение от Аноним84701 (ok), 01-Сен-19, 16:30
	>> как это низко > Согласен. бла-бла-бла > зачем-то давать ссылки на словарные статьи, Вообще-то, это два доказательства теоремы, на что намекает "proof" в ссылке. Но видимо пройти по ссылке слишком сложно, как и уточнить значение слова "теорема", лучше продолжать   нелепые оправдания в комментариях? > простое было "Теорема Райса это утверждение из теории алгоритмов". Довольно простое > предложение для уяснения, но наш Аноним84701 не смог выполнить процедуру чтения Т.е. сказать этим ты хотел ровным счетом ничего и сравнение фиолетовой теории большого взрыва и теплой _теоремы_ Райса было болтологией? Примерно это я и подозревал. Загугли хотя бы "проблема остановки", "машина тьюринга", "полнота по Тьюрингу" и не делай нам больше смешно.
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	109. Скрыто модератором	–3 +/–
	Сообщение от Аноним (-), 01-Сен-19, 15:56
	> Успокойтесь, приложите лед к пострадавшей части тела, откройте словарь и посмотрите значения > слов "теория" и "теорема". Да, посмотрел. Как это отменяет тот факт, что "Теорема Райса это утверждение из теории алгоритмов"? Довольно простое предложение для уяснения, но обделался ты конечно знатно в его восприятии. Ничего, бывает.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	102. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Илья (??), 01-Сен-19, 15:28
	> false positives. Не знаю как вам, а мне "ложные срабатывания" гораздо понятнее, чем "false positives."
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	228. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Илья (??), 03-Сен-19, 01:20
	> false positives. Справедливости ради стоит сказать, что раст тоже зачастую вполне валидный код не пропускает.
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	59. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (16), 01-Сен-19, 12:47
	в других языках разделение памяти между потоками успешно решается указанием "это потоко(не)безопасно" в документации. Не самая большая проблема. правило двух мутабельных ссылок введено для специфических случаев вроде инвалидации итератора при vector.push_back() (которые в C++ и так прекрасно ловятся и самим компилятором, и всеми возможными санитайзерами), а в остальном это мерзкое ненужное ограничение. Недаром в расте из коробки есть костыли вроде RefCell.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	104. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–3 +/–
	Сообщение от Илья (??), 01-Сен-19, 15:43
	> Не самая большая проблема. не соглашусь.
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Омномним (?), 02-Сен-19, 11:44
	>замена C++ в браузерах и прочем юзерспейсе Пока допилят, C++ превратится в прекрасного лебедя. Уже C++20 не за горами.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	199. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от red75prim (?), 02-Сен-19, 13:17
	Прекрасного лебедя в органических наростах 10, 20, 40 летней давности. Напильник прилагается: c++ core guidelines.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Wilem (?), 02-Сен-19, 15:00
	> Переходить ради такого на новый язык, в котором к тому же из всех архитектур полноценная поддержка есть только у x86 А в чём неполноценность? Код на расте под разные армы собирают и запускают и оно работает.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

17. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+17 +/–
Сообщение от Аноним (17), 01-Сен-19, 11:11
> Предполагается, что подобный подход может оказаться воспребован производителями оборудования, разрабатывающими проприетарные драйверы на скорую руку без проведения должного аудита. Знаете к чему это приведет? К тому, что потом часть производителей, что все же пишут нормальные драйвера с должным аудитом, под давлением эффективных менеджеров будут писать их на скорую руку.
Ответить | Правка | Наверх | Cообщить модератору

	20. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от анонимус12345 (?), 01-Сен-19, 11:17
	плюсану тебе анонимный сборат
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–2 +/–
	Сообщение от Аноним (22), 01-Сен-19, 11:23
	А какая разница? Всё равно не нужно > производителями оборудования, разрабатывающими проприетарные драйверы > проприетарные
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

19. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+9 +/–
Сообщение от анонимус12345 (?), 01-Сен-19, 11:16
>Предполагается, что подобный подход может оказаться воспребован производителями оборудования, разрабатывающими проприетарные драйверы на скорую руку без проведения должного аудита. ооо, это то, о чём мечтают все "эффективные менеджеры": "пишите на Расте, там само собой всё становится безопасно и можно не тестить!" >_< (слов нет)
Ответить | Правка | Наверх | Cообщить модератору

	24. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
	Сообщение от KaE (ok), 01-Сен-19, 11:24
	И самое главное за памятью и указателями не следить. А если за памятью не следить, то работы меньше. А если работы меньше, то и зп ниже, а жиробасу во главе конторы прибыли больше. В этом и суть работы эффективного менеджмента.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Илья (??), 01-Сен-19, 12:01
	> А если за памятью не следить, то работы меньше. А кто сказал, что в расте не нужно следить за памятью? Там только что и делаешь, что "следишь за памятью" в момент написания кода.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Forth (ok), 01-Сен-19, 12:22
	Там не за памятью следят, а за использованием ссылок. Где ненужно ссылки не распихивают по переменным.
	Ответить | Правка | Наверх | Cообщить модератору

26. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
Сообщение от Аноним (26), 01-Сен-19, 11:27
надо sysvinit на rust переписать и вернуть в debian, ubuntu
Ответить | Правка | Наверх | Cообщить модератору

	39. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от n80 (?), 01-Сен-19, 12:12
	Как будто сейчас в Debian нет sysvinit. Право, замучали уже это форсить. > $ dpkg -l | grep sysvinit > ii  sysvinit-core                                               2.96~beta-1                                             amd64        System-V-like init utilities > ii  sysvinit-utils                                              2.96~beta-1                                             amd64        System-V-like utilities > $ lsb_release -a > No LSB modules are available. > Distributor ID: Debian > Description:    Debian GNU/Linux bullseye/sid > Release:        stable-updates > Codename:       sid (это Debian testing, если что) Наличие единственной библиотеки systemd можно и пережить, хоть и немного не хватает порой аналога гентушных USE-флагов, тогда б можно было выпилить неиспользуемые зависимости от libatk, libavahi, libsystemd и прочего неиспользуемого на конкретной системе. Но библиотеки — чай, не сервисы, пусть уж валяются, на десктопе не стоит их выпиливание пересборки мира. > $ dpkg -l | grep systemd > ii  libsystemd0:amd64                                           242-4                                                   amd64        systemd utility library > ii  libsystemd0:i386                                            242-4                                                   i386         systemd utility library
	Ответить | Правка | Наверх | Cообщить модератору

29. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+4 +/–
Сообщение от Адекват (ok), 01-Сен-19, 11:35
"Тревога!Тревога! Волк унес зайчат!!" "Джош считает, что будущее системного программирования за Rust, а язык Си в современных реалиях претендует на место, которое в прошлые годы занимал Ассемблер". Школьники-неосиляторы добрались до программирования ? Вообще дико видеть такие высказывания, учитывая, что ядро Линукса написано на СИ, кстати ядра виндов и маков на чем написаны ? Или что им движет ? зачем нужно "это", если давно уже есть и активно используется СИ ? Что может "это", что НЕ может СИ ? ЗЫ: Жду агрессивных высказываний вида "ты ретроград, против технического прогресса, иди вообще откатись на самую первую версию СИ, а лучше на БИ, и не мешай прогрессу своими высказываниями ретроградными".
Ответить | Правка | Наверх | Cообщить модератору

	31. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от KaE (ok), 01-Сен-19, 11:39
	>Что может "это", что НЕ может СИ ? кто НЕ может на СИ может на "этом".
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от n80 (?), 01-Сен-19, 12:24
	Вот это, кстати, вряд ли. Писать на C гораздо легче, как по мне (в C умею, а вот растопрограммы пока что даже читать практически не получается, возможно, надо начать пытаться писать и тогда дело пойдёт, но это как-то не в приоритете совсем). Другое дело, что раст упрощает нахождение (а местами и вообще избегание) некоторого класса ошибок, которые нельзя просто так взять и совсем не допускать в C (не говоря уж про обнаружение в имеющемся коде), так что не надо тут про неосиляторов. Но как по мне, конечно, лучше бы пилили статический анализатор для C, пусть даже и требующий добавления нестандартных расширений языка. Но раз уж так, пусть делают.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Forth (ok), 01-Сен-19, 22:35
	Ты попробуй. У меня где-то с неделю ушло на въезжание что к чему. Конечно есть еще неясные темы, но в целом пишется и как то пока обратно на C не хочется.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Anonymoustus (ok), 02-Сен-19, 06:45
	> Ты попробуй. У меня где-то с неделю ушло на въезжание что к > чему. > Конечно есть еще неясные темы, но в целом пишется и как то > пока обратно на C не хочется. Так вот почему тебе так припекло, что ты удалил мои комментарии. Вот так молодец! Предвзятые «модераторы» — это то, что на следующий год лишит опеннет ещё половины донатов.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
	Сообщение от имя (ok), 02-Сен-19, 07:12
	> Так вот почему тебе так припекло, что ты удалил мои комментарии. Вот так > молодец! Да-да, а бесполезные крики про макак, рукожопость и умственную отсталость всех, кто попытался написать хоть что-то сложнее hello world и быстрее, чем за выходные, тут, конечно же, вообще ни при чём. И эти люди ещё смеют что-то говорить про переход на личности в соседнем треде.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Anonymoustus (ok), 02-Сен-19, 07:28
	Атмосферу на форуме всегда создают модераторы. Это разве новость? Если бы вахтёры не стирали наши содержательные комментарии, разжирев на донатах, не было бы этих потоков яда. У приличного уважающего себя анонима нет иного выхода, кроме заниматься троллингом. В этом виноваты исключительно местные вахтёры. Я уже дал опеннету чорную метку и не рассматриваю форум как место для содержательного общения.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Maxim Chirkov (ok), 02-Сен-19, 08:02
	Провёл аудит недавно удалённых ваших сообщений, всё удалено по существу.  Ваши сообщения удаляют исключительно за оскорбления собеседников, хамство и неуместный троллинг. Примеры из сообщений, удалённых за несколько последних дней: "На сдаче едят свои ноги или Вождя?" "Наш вождь Сатья Наделла не ест свои ноги" "ногоеды насовали внутрь архива" "294-й утёнок, никто не осудит" "В первый класс я ходил с твоей мамой" "Уж теперь-то заживём!" "От тебя невероятно смердит убожеством даже анонимно. Эта вонь летит впереди тебя." "Вижу, чадо, что тебе в школе на уроке информатики ещё не объяснили" Манера вашего общения сильно напоминает пользователя "КГБ СССР" (https://www.opennet.dev/soft/troll_log.html) который оскорблял всех подряд, а потом прикидывался невинно пострадавшим.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
	Сообщение от Anonymoustus (ok), 02-Сен-19, 09:00
	То есть когда в мой адрес пишут буквально эти же самые слова, никто не замечает? Какая поразительная избирательность. Донатов будет всё меньше — это главное.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Maxim Chirkov (ok), 02-Сен-19, 11:58
	Я в последнее время модерирую почти только на основе жалоб через "Сообщить модератору" и уведомлений бота. В вашем случае в логе модерирования много удалений вместе с подветкой, в которых ваше сообщение удалялось как часть подветки вместе с верхними сообщениями, т.е. первичным было удаление исходного оскорбления, а не вашей ответной реакции.
	Ответить | Правка | Наверх | Cообщить модератору

	217. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
	Сообщение от Anonymoustus (ok), 02-Сен-19, 18:13
	Зачем вообще заниматься безрезультатным лечением прыщей, а не самой болезни? Сделайте обязательную регистрацию — и все начнут немного думать, что пишут, исчезнет часть соблазна тупого троллинга. Уберите этот чёртов плюсомёт: он ничего не отражает, только играет на низменном у самых недоразвитых анонимов. А удалять комментарии — это вообще какое-то первобытное варварство, даже если в них оскорбления, хамство и маты. Комментарии можно просто скрывать. Кому интересно, тот себе откроет. Боты — тоже варварство. Какой смысл людям писать содержательные комментарии, если их запросто жрёт тупой скрипт? Почему капча для зарегистрированных пользователей, если комментарии со ссылками? Не первый же год всё это продолжается, неужели нельзя сделать какие-то выводы…
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Anonymoustus (ok), 02-Сен-19, 07:31
	А такой сверхсодержательный комментарий они оставили: https://www.opennet.dev/openforum/vsluhforumID3/118332.html#104 Я считаю, что излишне что-то ещё по этому поводу пояснять. Опеннет мёртв как площадка для общения. Здесь ничего не будет, кроме яда и срачей.
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

	221. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Илья (??), 02-Сен-19, 21:09
	>  А такой сверхсодержательный комментарий они оставили: Тут, пожалуй, соглашусь
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
	Сообщение от JL2001 (ok), 01-Сен-19, 12:09
	> Школьники-неосиляторы добрались до программирования ? > Вообще дико видеть такие высказывания, учитывая, что ядро Линукса написано на СИ, > кстати ядра виндов и маков на чем написаны ? Или что > им движет ? зачем нужно "это", если давно уже есть и > активно используется СИ ? Что может "это", что НЕ может СИ ? процитирую сам себя: > да и вообще. если код на си или си++ вылизан, то такому > по ничего не грозит. вот именно что вылизать код на расте (лично я за D) гораздо быстрее, легче, требует меньшего опыта и знаний даж на жаве есть неочевидные и странные соглашения по работе кода, но в сях - он весь из такого
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	48. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от Аноним (48), 01-Сен-19, 12:33
	Остожонее, не переполни буфер!
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	49. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–3 +/–
	Сообщение от n80 (?), 01-Сен-19, 12:34
	> учитывая, что ядро Линукса написано на СИ, кстати ядра виндов и маков на чем написаны ? Строго говоря, не от хорошей жизни они на C написаны. > зачем нужно "это", если давно уже есть и активно используется СИ ? Ещё бы стандарт у C развивался /хотя бы/ со скоростью стандарта плюсов (казалось бы, куда уж медленнее, но нет). Имеющееся положение дел у C очень огорчает, но переходить на плюсы или что-то с ещё более требовательным рантаймом как-то совсем не хочется. > Что может "это", что НЕ может СИ ? Кое-что таки может. Говоря коротко, чем больше можно выловить проблем на этапе компиляции, тем меньше лишней преждевременной седины, сей инструмент как раз на такое вылавливание очень ориентирован. Вообще говоря, стоит читать примеры из документации на инструмент, прежде чем говорить о школьниках-неосиляторах.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	55. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
	Сообщение от Anonymoustus (ok), 01-Сен-19, 12:40
	> Строго говоря, не от хорошей жизни они на C написаны. Вот это новости! На чём же они должны быть написаны? > Ещё бы стандарт у C развивался /хотя бы/ со скоростью стандарта плюсов (казалось бы, куда уж медленнее, но нет). Имеющееся положение дел у C очень огорчает, но переходить на плюсы или что-то с ещё более требовательным рантаймом как-то совсем не хочется. Назови-ка с аргументами, чего тебе не хватет в C89/90. > Кое-что таки может. Говоря коротко, чем больше можно выловить проблем на этапе компиляции, тем меньше лишней преждевременной седины, сей инструмент как раз на такое вылавливание очень ориентирован. Вообще говоря, стоит читать примеры из документации на инструмент, прежде чем говорить о школьниках-неосиляторах. Вот и выросло поколение, не знающее историю Сишечки.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от n80 (?), 01-Сен-19, 13:39
	> Вот это новости! На чём же они должны быть написаны? Ха, как будто на этот вопрос есть простой ответ. У всех имеющихся инструментов есть довольно крупные недостатки. Можно перечислить свойства, которыми должен обладать язык, но ни в одном они не сочетаются. Говорю же, не от хорошей жизни был сделан выбор, когда они начинались — выбора по факту и не было, а дальше уже тянут лямку legacy. Но это не значит, что нельзя иначе. > Назови-ка с аргументами, чего тебе не хватает в C89/90. Судя по выбору стандартов, автор поста — явный тролль, у которого на всё готовы аргументы в духе «это не нужно / это для неосиляторов / это можно сделать портянкой макросов или сторонними библиотеками / это ошибка, которую не заметит только скорбный разумом, внимательнее нужно быть / всегда так делали и это работает» и т.д. Я в курсе стандартных контраргументов по поводу фич того же C99, только вот тема слишком субъективная и холиварная, а мне это не упёрлось. Некоторое из того, нехватка чего недавно в очередной раз всплывала: типизированные enum (нет, -fshort-enums или #define с приведением типа на каждую константу — не решение), возможность вывести известное на этапе компиляции (но не очень известное кодеру) число в сообщении static_assert без извращений (всего-то нужно было понять, какого размера структура получилась вместо ожидаемого, обычно это делают через скрипты и autotools или через совсем уж негуманные хаки на макросах, но это реально отвратительный путь для такого простого действия), возможность объявить union из структуры (саму структуру объявлять прямо внутри union, а не отдельно) и массива байтов / uint16_t для чтения содержимого структуры (так, чтобы при этом чтобы не было нужно указывать размер этого массива, а он вычислялся исходя из размера структуры, т.е. typedef union { struct { ... }; uint8_t bytes[]; } some_type_t;, а ещё чтобы использование такого объявления не было UB, если заранее известна целевая архитектура), возможность явным образом разрешить/запретить компилятору переставлять поля конкретных типов структур (а не только вставлять выравнивания) и вообще выкидывать те, которые в конкретном варианте сборки не используются или всегда константны. > Вот и выросло поколение, не знающее историю Сишечки. Мал^WМолодой человек, а ты готов эту клевету подтвердить аргументами (чего именно из истории C и его предшественников я упустил и как это может помочь делу) или кроме отсылки к возрасту, как водится, аргументов нет? Конкретику, конкретику в студию. На всякий случай, уточню: я не топлю за rust, но того уровня статического анализа, который даёт -Wall -Wextra -Werror -Wnarrowing -Wwrite-strings -Wcast-qual (и ещё немного флагов) мне мало. А более продвинутому статическому анализу некоторые вещи в стандарте C, скажем так, не помогают. Зачем я серьёзно отвечаю троллю, косящему под олда — вопрос, конечно, интересный. "В интернете кто-то не прав.pcx", мда.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от JL2001 (ok), 01-Сен-19, 14:20
	> Зачем я серьёзно отвечаю троллю, косящему под олда — вопрос, конечно, интересный. хороший серьёзный ответ прочтут и другие
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Anonymoustus (ok), 01-Сен-19, 14:23
	>> Вот это новости! На чём же они должны быть написаны? > Ха, как будто на этот вопрос есть простой ответ. У всех имеющихся > инструментов есть довольно крупные недостатки. Можно перечислить свойства, которыми должен > обладать язык, но ни в одном они не сочетаются. Говорю же, > не от хорошей жизни был сделан выбор, когда они начинались — > выбора по факту и не было, а дальше уже тянут лямку > legacy. Но это не значит, что нельзя иначе. На этот вопрос есть ответ и он давно дан в написанном ПО. Выбор для написания системного ПО всегда стоял и стоит между непереносимыми ассемблерами или переносимыми языками. Си был условно низкоуровневым _переносимым_ языком. Выбор был очевиден для всех тогда и таковым остаётся доныне. Legacy тут совершенно ни при чём. Си даёт квалифицированному программисту возможности, которых не дают, например, Паскаль или Фортран при написании системного ПО. Удивительно, что приходится объяснять столь банальные и общеизвестные вещи на как бы айтишном форуме. Так от какой такой «не от хорошей жизни»? С конкретикой, пожалуйста. У Си, впрочем, есть очень серьёзный недостаток: Си требует развитых мозгов и поэтому совершенно не подходит обезьянам. >> Назови-ка с аргументами, чего тебе не хватает в C89/90. > Судя по выбору стандартов, автор поста — явный тролль, у которого на > всё готовы аргументы в духе «это не нужно / это для > неосиляторов / это можно сделать портянкой макросов или сторонними библиотеками / > это ошибка, которую не заметит только скорбный разумом, внимательнее нужно быть > / всегда так делали и это работает» и т.д. Я в > курсе стандартных контраргументов по поводу фич того же C99, только вот > тема слишком субъективная и холиварная, а мне это не упёрлось. Автор просто в курсе, что большинство жалобщиков не смогут объяснить даже себе различий между стандартами, ибо тех стандартов никогда не читали, но плачут о недостатке прогресса развития инноваций. Жалобщикам постоянно чего-то не хватает: то прямых рук, то мозгов, то денег. И постоянно что-то мешает: то ноги, то legacy, то «морально устаревшие» языки программирования, то другие люди. > На всякий случай, уточню: я не топлю за rust, но того уровня > статического анализа, который даёт -Wall -Wextra -Werror -Wnarrowing -Wwrite-strings > -Wcast-qual (и ещё немного флагов) мне мало. А более продвинутому статическому > анализу некоторые вещи в стандарте C, скажем так, не помогают. А мне показалось, что ты как раз чуть ли не за деньги тут рекламируешь обезьянохруст, противопоставляя его сишечке. Почему не С++, почему не Objective-C, почему не D наконец? А, анон? Чем тебе так приглянулся недоязык с уродливым дегенеративным синтаксисом, созданный в берлоге браузерных макак и продвигаемый, как ни странно, обос**вшимся по уши производителем процессоров? > косящему под олда Вот так одной фразой и палится школота.
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

	83. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Forth (ok), 01-Сен-19, 14:38
	Фортран да, не годится. А что мешает на паскале писать системное ПО? Не могу вспомнить примера, когда на C будет заведомо проще и удобнее писать.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Anonymoustus (ok), 01-Сен-19, 14:44
	Да ничего, в принципе, не мешает, просто сейчас не модно. А Яблоки же таки писали на своём варианте. Но есть всё же обоснованные мнения против, пусть и относящиеся к старым версиям языка: https://wiki.lazarus.freepascal.org/Why_Pascal_is_Not_My_Fav... Да и сам Вирт для создания ПО предлагает всё-таки другие языки. Не вижу оснований сомневаться в компетентности Вирта. :)
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от n80 (?), 01-Сен-19, 15:54
	> На этот вопрос есть ответ и он давно дан в написанном ПО. > Выбор для написания системного ПО всегда стоял и стоит между непереносимыми > ассемблерами или переносимыми языками. Си был условно низкоуровневым _переносимым_ языком. > Выбор был очевиден для всех тогда и таковым остаётся доныне. Legacy > тут совершенно ни при чём. Си даёт квалифицированному программисту возможности, которых > не дают, например, Паскаль или Фортран при написании системного ПО. Удивительно, > что приходится объяснять столь банальные и общеизвестные вещи на как бы айтишном форуме. А тут кто-то спорил с тем, что он даёт возможности? Я лишь говорю про возможности, которых в C очень не хватает. > Так от какой такой «не от хорошей жизни»? С конкретикой, пожалуйста. Сам же выше и перечислил. Асм не переносим (не говоря уж про то что код получается либо читабельным, либо оптимизированным, либо крайне тяжёлым в поддержке, если не подходить по принципу "время студентов ничего не стоит, пусть и в машкоды руками транслируют"), фортран (при всех его плюсах, одни лишь модули вместо пары из заголовочных файлов и объектников/исходников мне греют душу невыразимо, что бы там фанаты разделения объявления и реализации не говорили) не подходит, ибо лишён многих нужных фич (ну не предполагалось его использовать для этого вообще), у паскаля были хуже компиляторы и тоже фич не хватает (а Модула-2 опоздала, да и не сказать, что сильно лучше Си), остальные языки или уже отмерли (и были такие, что не жалко), или ещё не появились (в смысле наличия библиотек и хорошего оптимизирующего компилятора, а не только ранних спецификаций). > У Си, впрочем, есть очень серьёзный недостаток: Си требует развитых мозгов и > поэтому совершенно не подходит обезьянам. И зачем здесь эта очередная хлипкая попытка самоутверждения? А потом он удивляется, почему его посты к срачам приводят, хотя всего-то стоит подавлять в себе эти абсолютно неинформативные вставки, не добавляющие по сути ровно ничего, кроме попыток автора возвыситься над «сирыми и убогими». Не надо возвышаться, факты надо. > Автор просто в курсе, что большинство жалобщиков не смогут объяснить даже себе > различий между стандартами, ибо тех стандартов никогда не читали, но плачут > о недостатке прогресса развития инноваций. Жалобщикам постоянно чего-то не хватает: то > прямых рук, то мозгов, то денег. И постоянно что-то мешает: то > ноги, то legacy, то «морально устаревшие» языки программирования, то другие люди. Разницу между стандартами я знаю в достаточной мере, чтобы заниматься дополнительным ручным трудом только в случае, когда это действительно необходимо (т.е. когда под целевую платформу компилятора нормального нет и не будет), а не тупо везде по принципу «ну ничего страшного же». И как по мне, предлагать что-то старше С99 могут либо бедолашные (кто по каким-то причинам очень ограничен в выборе компилятора), либо откровенно лютые ретрограды, которые отрицают stdint.h (а мне потом за ними чистить код, написанный в предположениях вида sizeof(int) == 2 и тому подобных) и считают необходимым заводить переменные строго в начале функции, а не минимизировать их область видимости (хотя это и холиварный тезис, но чем меньше контекст, тем проще код анализировать мозгами, и это нужно, не потому что мозги маленькие, а потому что если где-то можно накосячить, то рано или поздно накосячено будет и нужно минимизировать такие возможности by-design, а заодно не добавлять лишних сложностей для поиска косяков) и заводить разные переменные для разных нужд (которые компилятор всё равно сольёт в одну область памяти, если так можно), а не делать эту работу за компилятор (добавляя нелепые ошибки при этом, конечно же). Уже ради этих двух вещей нужен C99 (ими дело не ограничивается, но я про достаточный критерий). А если нужны атомарные операции, потоки (системное программирование ядром не ограничивается), static_assert и прочие мелкие радости — уже C11 нужен. Только вот мой тезис в том, что останавливаться на этом не нужно. Понятно, что можно закат Солнца вручную организовывать, только вот зачем, разве что ради сомнительного самоутверждения (путь школоты, которая не по возрасту, а по строению души) и job security. > А мне показалось, что ты как раз чуть ли не за деньги > тут рекламируешь обезьянохруст, противопоставляя его сишечке. Почему не С++, почему не > Objective-C, почему не D наконец? А, анон? Чем тебе так приглянулся > недоязык с уродливым дегенеративным синтаксисом, созданный в берлоге браузерных макак > и продвигаемый, как ни странно, обос**вшимся по уши производителем процессоров? Что-что? Где это я такой тезис толкал? Наоборот, про синтаксис (и вообще читабельность) один из моих первых постов в этой теме был. Как и в случае не к ночи помянутого systemd, я вижу определённый смысл в том направлении (в самом направлении, подчёркиваю), в котором они работают, но конкретная реализация меня очень не устраивает. Но работать-то нужно. Рано Сишечке останавливаться на достигнутом. >> косящему под олда > Вот так одной фразой и палится школота. Если что-то можно сказать лаконично и доходчиво, на наиболее понятном для оппонента языке, — не вижу причин этого не делать, меня это школотой не делает, возможно, даже напротив: показывает что ещё не совсем мозги одеревенели (впрочем, с моей работой это вряд ли грозит). А вот чьё-либо брызгание слюной на тему дегенератов, макак, маленьких мозгов, школотунства и прочих далёких от техники понятий — как раз такого оратора показывает со стороны если не возраста, то уж точно состояния души. В среде зрелых персонажей это лишнее.
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	159. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Anonymoustus (ok), 02-Сен-19, 06:50
	> В среде зрелых персонажей это лишнее. В среде зрелых комментаторов, дружок, не переходят на личность, друг друга не называют персонажами и не бывает предвзятых модераторов, которые стирают комментарии старших товарищей исключительно из-за жжения у себя пониже спины.
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Аноним (152), 02-Сен-19, 04:12
	Я тоже добавлю, хоть вопрос и не мне. >Вот это новости! На чём же они должны быть написаны? На паскале, на модуле, на обероне, да хотя бы на плюсах. >Назови-ка с аргументами, чего тебе не хватет в C89/90. Не слишком ли жирный? Или серьезно? В антиквариате даже машиннонезависимых типов нет. Нитей нет. Моделей памяти нет. И это "системный" язык! На этом вообще нельзя писать без гамака, весь код сразу же становится непереносимым, все нужно обмазывать макросами и ассемблером. Ах да, для прикладного программирования тоже не подходит - вместо строковой библиотеки какой-то ад. Ну, может хоть байтовые трюки можно попробовать, язык же для этого? А нет. Тут не кастуй, это UB. Знаковое переполнение - UB. Битовые поля - UB. Сдвиги - UB. Битовые хаки снабжены таким количеством UB, что нужно 10 лет опыта чтобы примерно понимать что не делать, ессно компилятор ничего не скажет - все развалится когда нибудь само. Поддержки такой стандартной концепции как атомик - нет (а в "современном" С11 нет векторов). Может быть, метапрограммирование хорошо реализовано? Нет, препроцессор убогий. Вот и получается, что язык-то - говно.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	156. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Anonymoustus (ok), 02-Сен-19, 06:39
	> Я тоже добавлю, хоть вопрос и не мне. >>Вот это новости! На чём же они должны быть написаны? > На паскале, на модуле, на обероне, да хотя бы на плюсах. В этом вашем ИТ не ценятся интеллектуальные изобретения, потому что надо продавать инновационные прогрессивные новинки, а значит для программирования нужны не учёные, а индусы и умственно равные им эмигранты. >>Назови-ка с аргументами, чего тебе не хватет в C89/90. > Не слишком ли жирный? Или серьезно? В антиквариате даже // дальше поскипано Нет, в самый раз, причём жир натуральный, а не пальмовый. Антиквариат, напоминаю повторно, был написан для системы команд PDP. Антиквариат отражает собой _эту_ архитектуру. Он не предназначался для написания программ для x86, которой вообще не было во дни его создания. Сишечку, наверное, не стоило бы преподавать и учить для работы на иных архитектурах, и такое мнение нередко высказывают, но так уж сложилось, что антиквариат востребован повсюду. Однако регулярно находятся дурачки, повторяющие мантру про Си как ассемблер. Это какой-то позор. Да, для PDP Си действительно был заменителем ассемблера, но для x86 таковым не является. Открываешь любой толковый учебник по ассемблеру штеудовского хлама и начинаешь прозревать, как всё на самом деле плохо в этом вашем винтеловском ИТ, сколько внутри паутины, костылей, подпорок и распорок. Но кто ж нынче читает те учебники… Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца. А я недавно начал изучать малоизвестный среди опеннетовских аналитиков D. Не могу нарадоваться — так хорош этот язык. Уже написал несколько хеллоуворлдов и не останавливаюсь на достигнутом.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Совершенно другой аноним (?), 02-Сен-19, 10:01
	>> Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца. Всё-же PAE, которая (Physical Address Extension) это немного другое, поменьше, чем AMD64. PAE это до 36-ти битов физического адресного пространства (32-х битах виртуального), а AMD64 - по-моему это уже 40+ битов физического адресного пространства(64-х битах виртуального), плюс расширение регистров до 64-х бит (rax и т.д.), плюс доп. регистры (r8 - r15), ну и что SSE теперь должно быть обязательно, возможно и ещё, что-то по мелочи, что так на вскидку не вспомнилось.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Anonymoustus (ok), 02-Сен-19, 10:37
	>>> Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца. > Всё-же PAE, которая (Physical Address Extension) это немного другое, поменьше, чем AMD64. > PAE это до 36-ти битов физического адресного пространства (32-х битах виртуального), > а AMD64 - по-моему это уже 40+ битов физического адресного пространства(64-х > битах виртуального), плюс расширение регистров до 64-х бит (rax и т.д.), > плюс доп. регистры (r8 - r15), ну и что SSE теперь > должно быть обязательно, возможно и ещё, что-то по мелочи, что так > на вскидку не вспомнилось. Не другое. То же самое. И в соответствующих документах это прямо написано (AMD64 без PAE не работает). Отличия сугубо косметические. Можете сказать без обращения к документации, сколько вам и вашим программам доступно для самостоятельной адресации на самом деле? Если помните, как устроена виртуальная память в x86. Уверен, что многих поклонников жирных регистров и 64-битного светлого будущего ждёт большой сюрприз.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Совершенно другой аноним (?), 02-Сен-19, 10:44
	>>>> Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца. >> Всё-же PAE, которая (Physical Address Extension) это немного другое, поменьше, чем AMD64. >> PAE это до 36-ти битов физического адресного пространства (32-х битах виртуального), >> а AMD64 - по-моему это уже 40+ битов физического адресного пространства(64-х >> битах виртуального), плюс расширение регистров до 64-х бит (rax и т.д.), >> плюс доп. регистры (r8 - r15), ну и что SSE теперь >> должно быть обязательно, возможно и ещё, что-то по мелочи, что так >> на вскидку не вспомнилось. > Не другое. То же самое. И в соответствующих документах это прямо написано > (AMD64 без PAE не работает). Отличия сугубо косметические. У нас используется PAE, и PSE36 в самописных системах без 64-х битного режима - т.е. 32-х разрядный защищённый режим - есть, PAE - есть, правда только из-за NX-бита, а вот 64-х разрядности - нету. То, что оно входит в AMD64 в качестве требований, как и тот-же SSE, не означает, что это одно и тоже. > Можете сказать без обращения к документации, сколько вам и вашим программам доступно > для самостоятельной адресации на самом деле? Если помните, как устроена виртуальная > память в x86. Уверен, что многих поклонников жирных регистров и 64-битного > светлого будущего ждёт большой сюрприз. В 32-х битном режиме доступно 4G виртуального адресного пространства. Которые обычно разделяются на две части - ядерную и прикладную, как вариант по 2G каждая, ну или можно сделать и 1G/3G и, на самом деле любое другое.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Anonymoustus (ok), 02-Сен-19, 11:07
	Не хочу тратить своё время на бессмысленные споры. Берите документацию «первооткрывателей» и читайте, она написана очень ясным языком и занимает немногим более тысячи страниц. У Штеуда мануалы  на эту тему потолще будут. AMD64 Architecture Programmer’s Manual Volume 1: Application Programming https://www.amd.com/system/files/TechDocs/24592.pdf Volume 2: System Programming https://www.amd.com/system/files/TechDocs/24593.pdf
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Anonymoustus (ok), 02-Сен-19, 11:09
	> В 32-х битном режиме доступно 4G виртуального адресного пространства. Которые обычно разделяются > на две части - ядерную и прикладную, как вариант по 2G > каждая, ну или можно сделать и 1G/3G и, на самом деле > любое другое. Я не про это, а про доступ к регистрам.
	Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

	190. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Совершенно другой аноним (?), 02-Сен-19, 11:49
	Прошу прощения, всё-же не понял, про что Вы. У нас, в самописной системе используется PAE, при этом все регистры 32-х разрядные (eax и т.д) - сам процессор 64-х разрядность (в виде AMD64) не поддерживает.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Wilem (?), 02-Сен-19, 15:03
	> зачем нужно "это", если давно уже есть и активно используется СИ ? Что может "это", что НЕ может СИ ? > ЗЫ: Жду агрессивных высказываний вида Стоило бы ждать ссылок на описание преимуществ языка над Си. Но на самом деле стоило бы не ждать, а самому пройти почитать, что бы вообще понимать о чём идёт дискуссия, а то неудобно получается.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	244. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Ordu (ok), 04-Сен-19, 00:42
	> Что может "это", что НЕ может СИ ? Что может СИ, чего не может ассемблер? Что может ассемблер, чего не могут машинные коды? Это не риторические вопросы, это вопросы одного типа. И я очень рекомендую подумать их, и подумать почему же ядра сегодня пишут на C, если их можно писать на ассемблере. А зачем от машинных кодов ушли к ассемблерам? Это очень полезные размышления, и никто кроме тебя проделать их за тебя не сможет. > ЗЫ: Жду агрессивных высказываний вида "ты ретроград, против технического прогресса, иди вообще откатись на самую первую версию СИ, а лучше на БИ, и не мешай прогрессу своими высказываниями ретроградными". Я смотрю комментаторы выше тебя разочаровали в твоих ожиданиях. Держи: ты ретроград, против технического прогресса, иди вообще откатись на самую первую версию СИ, а лучше на БИ, и не мешай прогрессу своими высказываниями ретроградными".
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

35. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–4 +/–
Сообщение от Аноним (35), 01-Сен-19, 12:05
> избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера. CONFIG_PAX_KERNEXEC=y Решает проблемы С без всяких *растов
Ответить | Правка | Наверх | Cообщить модератору

	52. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от n80 (?), 01-Сен-19, 12:36
	Даже те проблемы, которые таким путём как бы решаются, и то решаются не полностью, увы. Это совсем не «серебряные пули».
	Ответить | Правка | Наверх | Cообщить модератору

41. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
Сообщение от бублички (?), 01-Сен-19, 12:19
почему не C# или даже VB?
Ответить | Правка | Наверх | Cообщить модератору

	47. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от JL2001 (ok), 01-Сен-19, 12:32
	> почему не C# или даже VB? требуют ж интерпретатор байткода возможно если впихнуть их в llvm, то получится что-то языки с интерпретируемым байткодом имеют особую прелесть в рантаймоптимизациях было бы очень интересно сравнить один и тот же код скомпилированный в машкады и запущеный на виртмашине с хорошей рантаймоптимизацией llvm такое позволяет?
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–4 +/–
	Сообщение от пох. (?), 01-Сен-19, 14:18
	открывай сбор донейтов. Я пожертвую пару рублей (за js, конечно, кому нужен этот ваш устаревший и не имеющий модного npm поделок проклятого m$ который хочет всех пороботить?!)
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	148. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от бублички (?), 02-Сен-19, 00:29
	вижу по теме донейтов ты больной на обе головы. здесь круглый год и в каждой теме подобный комментарий от тебя, хорошо если лишь один а не 5 или 10. нет бы давно уже денег на визит к доктору насшибал, всё здесь словоблудием занимаешься
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (167), 02-Сен-19, 08:50
	От слова робот?
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	105. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (99), 01-Сен-19, 15:47
	> почему не C# или даже VB? Потому что Sign# уже был в MS Singularity.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

46. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
Сообщение от user90 (?), 01-Сен-19, 12:30
> Джош считает Ну, теперь все! раз сам Джош так считает.. Да пусть развлекаются. Мне как-то попадался даже компилятор для bash-скриптов, идея примерно того же уровня.
Ответить | Правка | Наверх | Cообщить модератору

60. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+3 +/–
Сообщение от Адекват (ok), 01-Сен-19, 12:53
Вообщем, в недалеком будущем будет тут новость вида "по причине того, что gcc и СИ пользуются только 3% пользователей линукс, было принято решение дропнуть СИ и gcc, а в замен им предоставить rust и grr, а так же заменить устаревший glibc на новый прогрессивный gliRust, или сокращенно glist"
Ответить | Правка | Наверх | Cообщить модератору

	170. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Урри (?), 02-Сен-19, 09:41
	Судя по количеству уже написанного кода, это новости _далекого_ будущего.
	Ответить | Правка | Наверх | Cообщить модератору

	212. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (99), 02-Сен-19, 15:46
	> Судя по количеству уже написанного кода, это новости _далекого_ будущего. Вопрос не в переписывании существующего кода, а в возможности его трансляции на другой язык.
	Ответить | Правка | Наверх | Cообщить модератору

62. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
Сообщение от Аноним (58), 01-Сен-19, 12:57
Раст не готов для системного программирования, но "в будущем будет как С, а C будет как ассемблер". Похлопаем джошу за раздувание абстракций и бесполезную работу. Когда потомки спросят кто виноват, скажу это все Джош Триплет.
Ответить | Правка | Наверх | Cообщить модератору

	66. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Anonymoustus (ok), 01-Сен-19, 13:18
	Зато хоть стало понятно, почему Штеуд разучился делать процессоры. Давай, Интел, жги сам себя!
	Ответить | Правка | Наверх | Cообщить модератору

67. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+5 +/–
Сообщение от Egan (?), 01-Сен-19, 13:23
По моему опыту си никаким боком не может заменить ассемблер в ядре. На ассемблере пишут то, что вообще непонятно на чем еще можно писать.
Ответить | Правка | Наверх | Cообщить модератору

77. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
Сообщение от Аноним (77), 01-Сен-19, 14:21
Это пропихивание Раста, или да? Кому-то неймётся и он, для раздувания ЧСВ, хочет потеснить С?
Ответить | Правка | Наверх | Cообщить модератору

80. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+5 +/–
Сообщение от Аноним (-), 01-Сен-19, 14:29
почему люди так любят раст? У него же синтаксис страшный как моя жизнь
Ответить | Правка | Наверх | Cообщить модератору

	107. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+3 +/–
	Сообщение от Аноним (107), 01-Сен-19, 15:53
	> синтаксис страшный как моя жизнь +10 к элитарности
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Илья (??), 01-Сен-19, 16:29
	> синтаксис страшный как моя жизнь да, страшный, тут ничего не скажешь, не c# ни разу.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Аноним (11), 01-Сен-19, 16:53
	Так кажется, когда видишь некоторые примеры и не до конца понимаешь, что они делают. Всё встает на свои места, если хоть чуть-чуть разобраться. Так-то в C || C++ можно и похлеще языковые конструкции встретить.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	137. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от qwerty123 (??), 01-Сен-19, 20:52
	>Всё встает на свои места, если хоть чуть-чуть разобраться. Ага. - "Мы не будет использовать указатели! У нас автомагия!" прошло 5 минут... - "Если надо использовать указатели, то вот вам как в Си" А теперь найдите системный код без указателей.
	Ответить | Правка | Наверх | Cообщить модератору

	230. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Анонимкаааа (?), 03-Сен-19, 08:27
	Очередной чукча-писатель. В расте есть указатели, но не сырые, а умные, с владением явным всегда. Хочешь указатели сырые, именно сишные, где никто ничего не гарантирует, хочешь эксплуатировать свои любимые double-free, утечечки, по которым так скучал - пишешь `unsafe` и довольствуешься этим говном. В этом плане, в расте нет указателей настолько же, насколько их нет в плюсах. Только тот, кто ничего не знает о расте будет писать такой комментарий, как ваш, чукча-писатель.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от Проходил мимо (?), 02-Сен-19, 07:08
	Нет там ничего особо страшного.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	206. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Wilem (?), 02-Сен-19, 15:09
	> почему люди так любят раст? У него же синтаксис страшный как моя жизнь Приведи пару примеров.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

123. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–5 +/–
Сообщение от Аноним (11), 01-Сен-19, 16:59
Забавно, что есть искренние защитники языка, в котором нельзя банально стринги сложить без прямого использования функции 💩 Да, толковой альтернативы C не было в 90-ые. Но, люди, на дворе почти 2020-ые.
Ответить | Правка | Наверх | Cообщить модератору

	125. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+4 +/–
	Сообщение от Адекват (ok), 01-Сен-19, 17:22
	> Забавно, что есть искренние защитники языка, в котором нельзя банально стринги сложить > без прямого использования функции 💩 > Да, толковой альтернативы C не было в 90-ые. Но, люди, на дворе > почти 2020-ые. Я си изучаю месяц и уже пришел к выводу, что это не баг а фича. В СИ - все есть ячейка памяти. Если чего-то нет - можно написать свою функцию. Да поначалу дико, что нет explode как в php, но потом выясняется, что все-таки есть (не помню название), а потом - что оно не нужно, ведь можно функцию самому написать. Кстати что значит сложить стринги ? Я вот их не ношу, по этому не в теме. По сабжу - если "стринг" это строка, то в си это массив, со своими элементами и как нужно сложить два массива - если элементы типа int, то что нужно - сложить a[0]+b[0].....a[n]+b[n] или дописать один массив в конец другого ?
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (126), 01-Сен-19, 18:00
	>Я си изучаю месяц щас иксперд нам всё расскажет... и как стринги он не носит
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (11), 01-Сен-19, 18:34
	В C++ строки ВНЕЗАПНО тоже всего лишь массив чаров, но там средства языка позволяют адекватно реализовать std::string, чего нет и никогда не будет в C: std::string str1 = "one", str2 = "two"; std::string str3 = str1 + str2; // "onetwo" Добро пожаловать в мир нормальных языков! Кроме того, это довольно безопасное применение чаров, где можно не выстрелить случайного себе в ногу при работе с сырыми чарами и маллоками, что может допустить и опытный разработчик. > Если чего-то нет - можно написать свою функцию. Круто! Давай писать всё с нуля, к черту многолетние либы. Да к черту и функции, которые в других языках есть в стандартной либе, ведь можно свою написать! :) (надеюсь это был троллинг, тогда лайкос за него)
	Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

	128. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от Dmitry (??), 01-Сен-19, 19:08
	Мне больше нравятся паскалевские строки, когда нулевой элемент строки и есть сама длина строки. С ними гораздо проще выполнять любые действия. Не нужно перебирать по одному байту, в поиске "\0" Никаких выходов за пределы строки и утечек памяти. Единственное неудобство - ограничение такой строки в 255 символов. Но с другой стороны. Загляните в код любого драйвера. Где вы там видели строки больше 100-200 символов ?
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (126), 01-Сен-19, 19:12
	в плюсах, как бы, объект string также содержит длину строки и ничего не перебирается, и ноль в конце есть для совместимости с системными функциями.
	Ответить | Правка | Наверх | Cообщить модератору

	241. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Anonimous (?), 03-Сен-19, 14:38
	В современном Паскале особых ограничений нет (до High(SizeInt)).
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	166. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от pripolz (?), 02-Сен-19, 08:50
	По поводу сложения std::string - это не рекомендованных практика, т.к. несет в себе потерю производительности во столько раз, сколько раз там "+". "А + Б + Ц" несет в себе 3 разных сложения с выделением памяти и т.д.
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	172. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Совершенно другой аноним (?), 02-Сен-19, 10:12
	Вы не правы. В C++ строки это отдельный тип (реализованный через объект, который внутри может быть хранить строки по форме, похожей на паскалевские строки с хранением длины строки отдельно и строки - отдельно). В C, на самом деле, отдельного строкового типа - нет, есть массив, и есть частный, договорной случай ASCIIZ строк - типа, а давайте, то, что ограничивается 0 и будем считать строкой. Со всеми вытекающими последствиями. В C Вам никто не мешает реализовать свой вариант строк, удобный именно Вам, ну или использовать какую-нибудь библиотеку, в которой это уже реализовано до Вас и для Вас.
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	181. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от Аноним (99), 02-Сен-19, 11:09
	> В C++ строки ВНЕЗАПНО тоже всего лишь массив чаров, но там средства > языка позволяют адекватно реализовать std::string, чего нет и никогда не будет > в C: > std::string str1 = "one", str2 = "two"; > std::string str3 = str1 + str2; // "onetwo" > Добро пожаловать в мир нормальных языков! В "нормальном языке" результатом такого должен быть статистический массив символов, созданный на этапе трансляции, а не вот эти вот 3 вызова malloc, убивающие программу при нехватке памяти.
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	184. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Ordu (ok), 02-Сен-19, 11:23
	> std::string str1 = "one", str2 = "two"; > std::string str3 = str1 + str2; // "onetwo" > Добро пожаловать в мир нормальных языков! Но так же никто не делает на практике. Выделять память под третью строку, чтобы просуммировать две предыдущие? Как правило есть предвыделенный буфер, который перевыделяется. Часто этим предвыделенным буфером является первая из суммируемых строк. Если нет, то это часто форматный вывод в динамически выделяемый буфер. Что в C++, что в rust'е.
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	150. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от vitalif (ok), 02-Сен-19, 01:59
	Блин ну сложение строк это конечно просто самая нужная функция в ядре - куда уж без неё
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

132. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
Сообщение от Корец (?), 01-Сен-19, 20:08
А чё не JS-то?
Ответить | Правка | Наверх | Cообщить модератору

	142. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+3 +/–
	Сообщение от JL2001 (ok), 01-Сен-19, 22:43
	> А чё не JS-то? потомучта динамическая типизация должна сдохнуть в муках
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (250), 06-Сен-19, 10:06
	Только скорее ты сдохнешь быстрее :)
	Ответить | Правка | Наверх | Cообщить модератору

139. Скрыто модератором	–1 +/–
Сообщение от Ordu (ok), 01-Сен-19, 21:13
Грег заразился хипстерством. Ха-ха, ему что мама не рассказывала, что хипстерство заразно? Если его не выкинут срочно из разработчиков ядра, с целью ограничить распространение инфекции, то есть риск эпидемии.
Ответить | Правка | Наверх | Cообщить модератору

	154. Скрыто модератором	–1 +/–
	Сообщение от pripolz (?), 02-Сен-19, 04:15
	Его не выкинут а повысят. Он в нужном направлении смотрит. Си - это устаревший кросплатформенный ужас, который позволяет просто взять и собрать весь софт под новый Бродком или прости господи Ексунос. Ну кому такой нужен? Такое программирование совсем не безопасно.
	Ответить | Правка | Наверх | Cообщить модератору

149. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+13 +/–
Сообщение от Аноним (149), 02-Сен-19, 01:52
Объясните, кто-нибудь, на пальцах, почему драйвера, и вообще ядро, нельзя писать на современных плюсах С++? Из-за "тяжелого" рантайма? Или там есть какие-то фундаменталные ограничения? Чесслово не могу понять.
Ответить | Правка | Наверх | Cообщить модератору

	151. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+3 +/–
	Сообщение от НяшМяш (ok), 02-Сен-19, 02:40
	В MacOS X, например, IOKit - это C++ фреймворк для системных драйверов. Но для того чтобы рантайм не был тяжёлым, из него выпилили исключения, множественное наследование, шаблоны и RTTI.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от Аноним (240), 02-Сен-19, 10:43
	А вот шаблоны зря. Они же compile time и потому в runtime ничего не весят.
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (99), 02-Сен-19, 11:28
	> А вот шаблоны зря. Они же compile time и потому в runtime > ничего не весят. Для NT реализована стандартная библиотека C++ https://github.com/icestudent/ontl где всё вышеперечисленное сохранено (с учётом естественных ограничений на использование исключений на высоких IRQL).
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (240), 03-Сен-19, 12:34
	Судя по нику разработчика, дальше курсовика не продвинется.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (99), 03-Сен-19, 13:01
	> Судя по нику разработчика, дальше курсовика не продвинется. Судя по истории в 10 лет коммитов и порядка 50 человеко-лет по некоторым метрикам, тема курсовика того Студента "ненавязчивый троллинг ламеров".
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
	Сообщение от 123 (??), 02-Сен-19, 21:05
	Ну т.е. выпилили всё что делает его С++-ом )))
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	187. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (99), 02-Сен-19, 11:41
	> Объясните, кто-нибудь, на пальцах, почему драйвера, и вообще ядро, нельзя писать на > современных плюсах С++? На С++ возможно написать работающую программу, не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек). Для ядра такое неприемлемо. Язык С отсеивает опасных и потому нежелательных дилетантов. > Из-за "тяжелого" рантайма? Или там есть какие-то фундаменталные ограничения? Рантайм может быть существенно сокращён в объёме и не является обязательным.
	Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

	191. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+5 +/–
	Сообщение от Аноним (149), 02-Сен-19, 11:49
	> На С++ возможно написать работающую программу, не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек). Для ядра такое неприемлемо. Хотите сказать на чистом С _невозможно_ написать работающую программу, невладея на должном уровне языком и/или не понимая принципы работы базовых вещей? Ну ерунда-же.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (99), 02-Сен-19, 12:39
	Возможно, но уровни эти существенно разные. Насмотрелся на PHP-разработчиков, лабающих на плюсах, но впадающих в ступор при виде С.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
	Сообщение от Anonymoustus (ok), 02-Сен-19, 18:17
	> Возможно, но уровни эти существенно разные. Насмотрелся на PHP-разработчиков, лабающих > на плюсах, но впадающих в ступор при виде С. Как же они на плюсах работают? А пример какой-то их работы есть где посмотреть?
	Ответить | Правка | Наверх | Cообщить модератору

	232. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (99), 03-Сен-19, 09:13
	>> Возможно, но уровни эти существенно разные. Насмотрелся на PHP-разработчиков, лабающих >> на плюсах, но впадающих в ступор при виде С. > Как же они на плюсах работают? На плюсах, в отличии от С, можно поставить + между двумя строками, вот и работают, передавая на каждый чих vector<string> по значению. Работает же, а шо тут такого? (с) > А пример какой-то их работы есть > где посмотреть? Специально не искал, видел такое в проприетари, подрабатывая "реаниматором".
	Ответить | Правка | Наверх | Cообщить модератору

	226. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+2 +/–
	Сообщение от Аноним (223), 02-Сен-19, 23:28
	> На С++ возможно написать работающую программу, не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек). Не так. На С++ невозможно написать работающую программу, владея на должном уровне языком и понимая принципы работы базовых вещей. Потому что овладеть всем этим и понять его для человека физически невозможно. Да, Rust стремится раздуться в такого же монстра, но пока отстаёт.
	Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

	231. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (99), 03-Сен-19, 08:30
	>> На С++ возможно написать работающую программу, не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек). > Не так. На С++ невозможно написать работающую программу, владея на должном уровне > языком и понимая принципы работы базовых вещей. Потому что овладеть всем > этим и понять его для человека физически невозможно. Оба тезиса не противоречат друг другу. Таков эффект Даннинга - Крюгера. > Да, Rust стремится раздуться в такого же монстра, но пока отстаёт.
	Ответить | Правка | Наверх | Cообщить модератору

	237. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (240), 03-Сен-19, 12:41
	>не владея на должном уровне языком и/или не понимая принципы работы базовых вещей (таких как аппаратный стек). Для ядра такое неприемлемо. Язык С отсеивает опасных и потому нежелательных дилетантов. Да ладно вам. Как это C вам отсеет HelloWorld-прогеров или запретит им на Сях писать? Ну отсейте производителей железок тогда, которые вам хоть какие-то кривые драйвера на Сях, заметьте, предоставили.
	Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

	207. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Wilem (?), 02-Сен-19, 15:12
	Писать можно что угодно на чём угодно. Если вопрос в "что лучше", а то лучше то, что лучше а не то, что хуже.  Извините.  Список того, чем раст лучше ц++ есть и не один.  Несколько лет назад была конфа где разработчику фейсбука рассказывал о самых жёстких багах в их коде на ц++, так вот каждый баг из этого списка просто бы не существовал на расте, т.к. компилятор бы не позволил такое сделать. https://www.reddit.com/r/rust/comments/cq9rco/cppcon_2017_cu.../
	Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

	210. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (99), 02-Сен-19, 15:35
	> Писать можно что угодно на чём угодно. Если вопрос в "что лучше", Вопрос вообще не в лучше/безопаснее и проч. Группа людей с консервативными взглядами годами совместно работает над ядром. Эта группа решает вопросы на каком языке разрабатывать ядро и в каком месте должна стоять запятая в принимаемых патчах. Про С++ говорят примерно то, что я мягко резюмировал в #187. Тот факт, что Грег заявил "как здорово, давайте посмотрим, что вы нам предложите" совсем не означает, что предложеное не завалят по формальным поводам на ревью.
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (99), 02-Сен-19, 15:39
	> предложеное То есть если вот такое я хочу отправить как патч, мне укажут на ошибку и не примут. Хотя остальное может иметь гарантии в 146% безопасности, подкреплённые 7-ю печатями.
	Ответить | Правка | Наверх | Cообщить модератору

	227. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (223), 02-Сен-19, 23:30
	> Если вопрос в "что лучше", а то лучше то, что лучше а не то, что хуже. Ну какой там ещё C++ или rust, ты русским-то языком мне парсер сломал.
	Ответить | Правка | К родителю #207 | Наверх | Cообщить модератору

	234. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Wilem (?), 03-Сен-19, 10:20
	Извините, не могу как аноним править, поторопился.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (240), 03-Сен-19, 12:48
	>так вот каждый баг из этого списка просто бы не существовал на расте, т.к. компилятор бы не позволил такое сделать А, собственно, что мешает компилятору C++ тоже стать значительно более строгим, даже особо не меняя стандарты языка? Ввести опцию-режим суперстрогости -fsuperstrict
	Ответить | Правка | К родителю #207 | Наверх | Cообщить модератору

155. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	–1 +/–
Сообщение от Аноним (155), 02-Сен-19, 04:21
Тем временем: https://paste.pics/b49d5b5b7eebf3dd595bff89333d4c90
Ответить | Правка | Наверх | Cообщить модератору

176. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
Сообщение от Аноним (176), 02-Сен-19, 10:39
Ну наконец то у Intel пропадут все дырки в процессорах и драйверах. Останутся только электроны, раст и терможвачка.
Ответить | Правка | Наверх | Cообщить модератору

186. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
Сообщение от Аноним (186), 02-Сен-19, 11:28
>будущее системного программирования за Rust За теми, кто ставит компилятор не из пакетов, а скачивая и исполняя баш-скрипты, а потом ставит зависимости из центрального репозитория, сайт которого не заботает без javascript, а система сборки допускает выполнение команд и ставит зависимости в подпапку? Иными словами: * подвергает риску сборщиков пакетов * подвергает риску пользователей собранных пакетов * неэффективно собирает, перерасходуя ресурсы. Как такое может найти популярность в среде программистов, отличных от любителей NPM? А то, что это собираются использовать для системного программирования и что мне придётся использовать ядро, собранное этим, вообще меня в шок подвергает. Можно забэкдорить всю инфраструктуру, забекдорив сборочную систему. Бэкдор можно сделать необнаружимым на системах, использующих забэкдоренные компоненты. То есть на всех системах, потому что без драйверов и ядра ни одна система не работает. И не надо тешить себя иллюзией, что колибри ОС вам поможет. Ведь модули UEFI тоже можно забэкдорить, а бэкдор в них адаптировать для инфицирования Kolibri OS и компиляторов для неё.
Ответить | Правка | Наверх | Cообщить модератору

	195. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (195), 02-Сен-19, 12:22
	Не волнуйся, если хотя бы один такой бекдор вскроется, то это скомпрометирует всю систему целиком.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (186), 02-Сен-19, 15:57
	Ну вскроется, и что дальше? Перекомпилировать весь софт на чистых доверенных системах с новыми бэкдорами, на этот раз завёрнутыми в SGX? Никто это делать не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Wilem (?), 02-Сен-19, 15:16
	> Как такое может найти популярность в среде программистов Для этого можно почитать мнение и аргументацию этих самых программистов. Ничего сложного в этом нет, всё в гугле. Без обид, но твои опасения про пакеты в сравнении с тем, что раст даёт разработчикам - это несоизмеримо.
	Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

	252. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Logarithmus (?), 14-Фев-20, 10:14
	>сайт которого не заработает без javascript Вместо тормозного crates.io есть lib.rs (серверная часть на Rust и работает без JS) >ставит зависимости в подпапку Можно прописать переменную окружения "CARGO_TARGET_DIR", тогда все крейты будут собираться в одной папке. Но при обновлении компилятора и при несовпадении версии крейта он будет собран заново.
	Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

202. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+1 +/–
Сообщение от Аноним (202), 02-Сен-19, 14:55
Интересные замечания по теме https://lwn.net/Articles/797714/
Ответить | Правка | Наверх | Cообщить модератору

209. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
Сообщение от Аноним (-), 02-Сен-19, 15:20
Драйвер nvidia будет? :)
Ответить | Правка | Наверх | Cообщить модератору

	233. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от Аноним (99), 03-Сен-19, 09:14
	> Драйвер nvidia будет? :) Так то не шутите, желанья сбываются. :)
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
	Сообщение от аноним3 (?), 03-Сен-19, 18:01
	раст не создавался как системный язык. не надо народ пугать. когда он дорастет до такого уровня, то он раздуется как с++ и никто уже ничего полностью в нем понять не сможет))) и появится новы сраст какой нибудь. не парьтесь
	Ответить | Правка | Наверх | Cообщить модератору

251. "Фреймворк для написания защищённых драйверов для ядра Linux ..."	+/–
Сообщение от Игорь Николаев (?), 07-Сен-19, 05:28
Всё хорошо. Вот только ethernet в rpi3 виснет. И всю усбню вешает.
Ответить | Правка | Наверх | Cообщить модератору

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

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