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

"Предложение по обсуждению вопроса добавления в ядро Linux средств для разработки на языке Rust"	+/–
Сообщение от opennews (??), 10-Июл-20, 12:49
Ник Десанье (Nick Desaulniers), занимающийся в Google обеспечением поддержки сборки ядра Linux с использованием компилятора Clang и также помогающий исправлять ошибки в компиляторе Rust, предложил провести на конференции Linux Plumbers Conference 2020 сессию для обсуждения предоставления возможности разработки компонентов ядра на языке Rust. Ник занимается проведением микро-конференции, посвящённой LLVM, и считает, что было бы неплохо обсудить технические аспекты возможной интеграции поддержки Rust в ядро (им уже подготовлен рабочий прототип для KBuild) и понять нужно ли вообще добавлять такую поддержку и какие ограничения по использованию Rust следует принять... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53331
Ответить | Правка | Cообщить модератору

Сообщения

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

2. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–24 +/–
Сообщение от Самый Лучший Гусь (?), 10-Июл-20, 12:51
Тогда я перехожу на OpenBSD, так и знайте.
Ответить | Правка | Наверх | Cообщить модератору

	3. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+68 +/–
	Сообщение от Аноним (3), 10-Июл-20, 12:52
	Так и запишем - "гуся вычеркиваем"
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+13 +/–
	Сообщение от Аноним (99), 10-Июл-20, 16:41
	Корпы потирая ручки: "Вот так мы и избавились от Гуся, наш план сработал. Без Гуся мы легко зОхватим все ядро"
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+3 +/–
	Сообщение от Аноним (7), 10-Июл-20, 13:04
	Honk honk
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	13. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+5 +/–
	Сообщение от m.makhno (ok), 10-Июл-20, 13:10
	пока-пока
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	15. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от Аноним (15), 10-Июл-20, 13:15
	скатертью дорога
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	101. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+7 +/–
	Сообщение от Анонимус111ЧЧЧ (?), 10-Июл-20, 16:57
	Протрите хлоркой после него
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	139. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (139), 10-Июл-20, 21:21
	Раст объективно хороший язык, какие проблемы?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	180. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (180), 11-Июл-20, 01:30
	...проприетарные драйверы на скорую руку без проведения должного аудита... - вот тебе и будут проблемы
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+3 +/–
	Сообщение от коржик (?), 11-Июл-20, 06:37
	> проприетарные драйверы на скорую руку без проведения должного аудита. можно и на си писать.
	Ответить | Правка | Наверх | Cообщить модератору

	258. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от microsoft (?), 11-Июл-20, 22:08
	А ты глцпенький... можно, но не будут, будет расто жырно уг код. Удачи вам там на лялексах, пойду пробсдется.
	Ответить | Правка | Наверх | Cообщить модератору

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

	189. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от Аноним (189), 11-Июл-20, 03:50
	> Раст объективно хороший язык, какие проблемы? 1. Часто меняется. 2. Контролируется по сути 1 корпой - мазилой. 3. Навороченные конструкции, гарантии применительно к которым вилами по воде писаны. 4. Вебмакаки в ядре не рулят.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	218. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
	Сообщение от marios (ok), 11-Июл-20, 11:36
	1. Про аспекты языка и std::, которые могут измениться, это известно заранее. 2. К Java не имеешь претензий? 3. Конструкции лаконичные и гарантии строгие. 4. Лол.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–7 +/–
	Сообщение от Аноним (225), 11-Июл-20, 13:04
	java такой же убогий язык. Все нормальные люди пишут на C# Вот если бы C# предложили в ядро включить.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от виндотролль (ok), 11-Июл-20, 18:05
	Так разве ещё не в ядре, nt4.0 которое?
	Ответить | Правка | Наверх | Cообщить модератору

	300. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от max (??), 13-Июл-20, 10:59
	Все нормальные люди пишут на Kotlin, Scala или Java (выбирай по вкусу).
	Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

	224. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–3 +/–
	Сообщение от Аноним (225), 11-Июл-20, 13:02
	1) он небезопастный. В нем unsafe блоки отличии от Си 2) у него ужастный синтаксис 3) на нем невозможно написать ничего сложнее hello world 4) на нем пишут отвратительный, нечитаемый, кривой код 5) он никому не нужен
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	241. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Gogi (??), 11-Июл-20, 19:27
	+1. Кроме того, все эти ужимки с "владением объектом" - полная чушь и околесица. Никто так писать не будет, а "изучать глубоко" - тем более. И это не говоря о том, что там напрочь отсутствует ООП. Без объектов писать большие сложные системы - медленное самоубийство под тонной собственной вермишели.
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от fatlortroll (?), 11-Июл-20, 21:27
	> Без объектов писать большие сложные системы И как же линуксовое ядро на pure C нашкодили-то?
	Ответить | Правка | Наверх | Cообщить модератору

	295. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (295), 13-Июл-20, 05:24
	Сам я не фанат этих ваших растов, но вы явно перегибаете... > там напрочь отсутствует ООП Его поэтому и разрешают. ООП и системное программирование не встречается даже на венде. Железо понимает только структуры данных размещенные в памяти, функции и конечные автоматы всякие. Что там за классы с поведением вы наклепали железу начхать. Ваш чудесный ООП-компилятор даже не соберет это в машинный код. Сначала преобразует в структурную лапшу промежуточного представления, которую можно уже и скомпилировать. > Без объектов писать большие сложные системы - медленное самоубийство под тонной собственной вермишели Легко и радостно. Откройте для себя ECS, например, её даже в расте можно. Опять же, это все не про ядро и драйверы. > все эти ужимки с "владением объектом" - полная чушь и околесица ну все что угодно, лишь бы не GC. Если бы у раста был GC, он бы повторил судьбу D. По-правде, я тоже считаю синтаксис раста уродливым, а его решение вокруг владения не очевидным. Но всё лучше чем С++ с его виртуальными деструкторами и метапрограммированием на шаблонах, расту 30 лет еще до таких граблей.
	Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

	297. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от n00by (ok), 13-Июл-20, 08:29
	> Сам я не фанат этих ваших растов, но вы явно перегибаете... >> там напрочь отсутствует ООП > Его поэтому и разрешают. ООП и системное программирование не встречается даже на > венде. Угу. Именно потому "в венде" имеются объекты ядра https://docs.microsoft.com/en-us/windows/win32/sysinfo/kerne... и семейство ядрёных функций с префиксом Ob* (например, nt!ObCreateObjectType).
	Ответить | Правка | Наверх | Cообщить модератору

	303. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (303), 13-Июл-20, 22:56
	То что это оффтопик, еще не значит, что нужно распространять ложную информацию. Наличие "объекта" не говорит об объектно ориентированном программировании. Так-то в С тоже полным-полно объектов, структуры, например, но ООП там и не пахнет. В статье, которую скинули любую функцию откройте и убедитесь, что там С-функции. И вообще, статья описывает API доступа к открытым публичным объектам из приложений. ПРИЛОЖЕНИЙ КАРЛ! Приложение это в юзерспейсе, так-то. Они могут быть и на С++. Настоящие драйверы пишутся там с использованием KMDF. Вот тебе дока на HelloWorld https://docs.microsoft.com/en-us/windows-hardware/drivers/ge... Обрати внимание на строчку: "The file name extension is .c, not .cpp." Visual Studio такая IDE... Она как бы официально не поддерживает С, только С++, но если создать C++ проект и переименовать файлик из cpp в с, отработает C-compiler в рамках той версии стандарта С, которую он умеет (C89 + куски C99). Это как раз и нужно для KMDF и UMDF. На сайтах MS (docs/msdn) исторически принято не разделять С от C++. Они везде пишут C++ и вводят в заблуждение неграмотных.
	Ответить | Правка | Наверх | Cообщить модератору

	304. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от n00by (ok), 14-Июл-20, 10:06
	> Наличие "объекта" не говорит об объектно ориентированном программировании. Об этом говорят IRP, которыми объекты обмениваются. Но про эти сообщения говорить явно рановато. ;) > В статье, которую скинули любую функцию откройте и убедитесь, что там С-функции. > И вообще, статья описывает API доступа к открытым публичным объектам из > приложений. ПРИЛОЖЕНИЙ КАРЛ! Приложение это в юзерспейсе, так-то. Они могут быть > и на С++. Ну да, приложение в юзерспейсе получает хендл объекта и с ним оперирует. А в ядре хендл транслируется в указатель на объект. Это называется "сокрытие реализации". ;)) > Настоящие драйверы пишутся там с использованием KMDF. Угу. Это для Вас они пишут-ся -- сами собой. =))) А кто-то их пишет. С использованием DDK (+IFS Kit), которое стало WDK, а не этого модно-молодёжного фреймворка. Так что с "вот тебе дока" кое-кто явно промахнулся. Читайте для начала Рихтера, или кого там принято рекомендовать по такому поводу. Только потом Уолтера Они. > То что это оффтопик, еще не значит, что нужно распространять ложную информацию. Согласен, не делайте этого.
	Ответить | Правка | Наверх | Cообщить модератору

	305. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (303), 14-Июл-20, 13:14
	> Это для Вас они пишут-ся -- сами собой. =))) А кто-то их пишет. С использованием DDK (+IFS Kit), которое стало WDK, а не этого модно-молодёжного фреймворка. ._. KMDF - это фреимворк для написания драйверов уровня ядра (в линуксе почти все такие). Эти драйверы всегда пишутся на С. UMDF - это фреимворк для написания драйверов пространства пользователя. То есть не драйверов, на самом деле, а тех самых DLL-ок которые цепляются к какому-то специфическому API, которое ядро выставляет в юзерспейс. Исторически их можно было писать на C++, потому что они работали через шину COM. А потом случилась 8-ка. В 8.1+ наступил UMDFv2 и теперь надо писать как в KMDF на С. Это обёртки над WDM, которые существуют со времен Vista. Это слишком молодежно? А что надо VxD вспоминать? Или может быть писать на голом WDM? Так его уже тоже не рекомендуют для новых драйверов. Опять же, WDM это тоже С. Меня так умиляет ваше желание обойти стороной самое главное, что было сказано в моем комментарии выше про поведении студии. Повторю еще раз громко и отчетливо: Если в "Visual C++" проекте встречается файлы *.c, то они компилируются по стандарту языка С89 + куски С99. KMDF/UMDF и сама WDM - это С. С++ раньше было можно использовать для юзерспейса и то, это померло вместе с 7-кой. > Об этом говорят IRP, которыми объекты обмениваются. Но про эти сообщения говорить явно рановато. ;) > Ну да, приложение в юзерспейсе получает хендл объекта и с ним оперирует. А в ядре хендл транслируется в указатель на объект. Это называется "сокрытие реализации". ;)) И какое отношение это имеет к изначальному утверждению, что ООП не используется для драйверов уровня ядра, они на С? Вы точно понимаете эту фразу правильно? Речь идёт не об академической методологии "всё есть объект". Речь именно о полнофункциональных ООП-языках у которых есть инкапсуляция, полиморфизм, наследование и абстракция, позволяющая определить поведенческие модели для объектов и, как следствие, обязывающая компилировать программу в промежуточное представление, куда транслируется весь этот ООП-шный синтаксический сахар. А если Вы, любезный, вдруг помыслили что "сокрытие реализации" ↔ "инкапсуляция" и наличие этого сокрытия порождает ООП, то вы ошибаетесь, ведь "инкапсуляция" ∈ "сокрытие реализации". ООП-шная концепция инкапсуляции - это один из методов сокрытия, который, среди прочего, подразумевает еще включение методов в объект-класс. Во-первых, пальцем ткните где это внутри WDM, да так чтобы на C++ классом, а не объявление указателей на функции в поле структуры. Во-вторых, наличие инкапсуляции является необходимым, НО НЕ ДОСТАТОЧНЫМ условием для появления объектно ориентированной модели, а то и С и Rust станут объектно-ориентированными языками. События, опять же, тоже не являются частью ООП. Они могут быть реализованы не только при помощи ООП, но и при помощи той же ECS или так как это делают в системном программировании, конечными автоматами,.. по-разному. И то что драйверы обмениваются друг с другом IRP-структурами (СТРУКТУРАМИ КАРЛ!) говорит о наличии шины данных. И что? Если я пропихну структуру с указателями на функции, контексты и прочее через пайп, то это у меня уже ООП появилось?! Ну тогда ядро Linux тоже на ООП (доказательство: наличие unix pipes, structs, function pointers)... тьфу. > Читайте для начала Рихтера, или кого там принято рекомендовать по такому поводу. Только потом Уолтера Они. Меня терзают смутные сомнения... А вы сами-то читали или просто "рекомендуете"? Покажите пальцем, где у того же Уолтера Они код на С++. А если рекомендовать, то может актуальную доку, а не учебник по написанию драйверов для 98/Me/2k/XP.
	Ответить | Правка | Наверх | Cообщить модератору

	308. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от n00by (ok), 14-Июл-20, 17:34
	>> Это для Вас они пишут-ся -- сами собой. =))) А кто-то их пишет. С использованием DDK (+IFS Kit), которое стало WDK, а не этого модно-молодёжного фреймворка. > ._. > KMDF - это фреимворк для написания драйверов уровня ядра (в линуксе почти > все такие). Эти драйверы всегда пишутся на С. Можно писать на плюсах. Как раз во времена KMDF и началось продвижение ограниченного подмножества С++ самой компанией Microsoft. Вы сами то примеры смотрели, или первым попавшимся ограничились? Мне NT давно не интересна, потому за Вас я это делать не хочу, но вот третья строчка из выдачи поисковика: "Случайно наткнулся на примеры аудио-девайсов в WDK. В частности, src\audio\sb16. Вполне себе объектно-ориентированный вполне себе кернел-мод. Вопрос: что это? Огрызки какого-то C++ framework-а от MS? Object-oriented miniport? Когда это появилось и почему про "C++, Kernel-Mode и Microsoft" все привыкли слышать "выберите любые 2"?" все привыкли слышать "выберите любые 2"?." https://www.rsdn.org/forum/asm/3914290.all > WDM? Так его уже тоже не рекомендуют для новых драйверов. Опять > же, WDM это тоже С. Кто-то даже на Дельфи писать умудрялся. > Меня так умиляет ваше желание обойти стороной самое главное, что было сказано > в моем комментарии выше про поведении студии. Повторю еще раз громко > и отчетливо: > Если в "Visual C++" проекте встречается файлы *.c, то они компилируются по > стандарту языка С89 + куски С99. KMDF/UMDF и сама WDM - > это С. С++ раньше было можно использовать для юзерспейса и то, > это померло вместе с 7-кой. Мне не интересна Студия и её ограничения, никогда её под Windows не использовал. Вы не в курсе, каким образом раньше там драйвера собирали, и что изначально Студия их сборку вообще не поддерживала? >> Об этом говорят IRP, которыми объекты обмениваются. Но про эти сообщения говорить явно рановато. ;) >> Ну да, приложение в юзерспейсе получает хендл объекта и с ним оперирует. А в ядре хендл транслируется в указатель на объект. Это называется "сокрытие реализации". ;)) > И какое отношение это имеет к изначальному утверждению, что ООП не используется > для драйверов уровня ядра, они на С? Напомню утверждение из #295 "ООП и системное программирование не встречается даже на венде." На примере совокупности присущих ООП признаков мы видим, что парадигма там используется и положена в основу дизайна ядра, следовательно исходное утверждение -- не соответствует действительности. > Вы точно понимаете эту фразу правильно? Речь идёт не об академической методологии > "всё есть объект". Речь именно о полнофункциональных ООП-языках у которых есть > инкапсуляция, полиморфизм, наследование и абстракция, позволяющая определить поведенческие > модели для объектов и, как следствие, обязывающая компилировать программу в промежуточное > представление, куда транслируется весь этот ООП-шный синтаксический сахар. Это сейчас Вы начали вкладывать в исходную фразу некие дополнительные смыслы, связывая ООП с языками. Но финт опять слегка мимо кассы. В ядре NT можно использовать С++, включая часть стандартной библиотеки, и даже dynamic_cast<> -- если сильно захотеть и никого не бояться https://code.google.com/archive/p/ontl/wikis/Compliance.wiki >[оверквотинг удален] > не только при помощи ООП, но и при помощи той же > ECS или так как это делают в системном программировании, конечными автоматами,.. > по-разному. И то что драйверы обмениваются друг с другом IRP-структурами (СТРУКТУРАМИ > КАРЛ!) В плюсах struct и class практически одно и тоже, разница лишь с видимости членов по умолчанию. > говорит о наличии шины данных. И что? Если я пропихну > структуру с указателями на функции, контексты и прочее через пайп, то > это у меня уже ООП появилось?! Ну тогда ядро Linux тоже > на ООП (доказательство: наличие unix pipes, structs, function pointers)... тьфу. >> Читайте для начала Рихтера, или кого там принято рекомендовать по такому поводу. Только потом Уолтера Они. > Меня терзают смутные сомнения... А вы сами-то читали или просто "рекомендуете"? Покажите > пальцем, где у того же Уолтера Они код на С++. А Стр. 63 -- таблица "виртуальных функций" (ну да, слегка не такая, как привычная VTbl) Стр. 65 "Объекты драйверов". "Считайте их аналогами приватных и защищённых членов классов С++". Это там прям так и напечатано. > если рекомендовать, то может актуальную доку, а не учебник по написанию > драйверов для 98/Me/2k/XP. Актуальная мне не интересна, но вот одна из классических, и уже доступна без подписки: C++ in an NT Driver The NT Insider, Vol 14, Issue 2, March - April 2007 http://www.osronline.com/article.cfm^article=490.htm -- ссылка бьётся по ^, так что копируйте. и ещё https://web.archive.org/web/20101116020047/http://www.micros...
	Ответить | Правка | Наверх | Cообщить модератору

	271. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от коржик (?), 12-Июл-20, 12:04
	> 2) у него ужастный синтаксис В чем ужас?
	Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

	240. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Gogi (??), 11-Июл-20, 19:25
	Он "хороший" только для хипстоты и смузихлёбов. Как таковой, это просто "ещё один" язык для неокрепших умов. Писать на этом г****вне всё равно никто не будет, один только хайп подымают.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	259. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (259), 11-Июл-20, 22:22
	А зоопарк из кучи языков - это разве не проблема?
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	144. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (144), 10-Июл-20, 21:30
	Что-то я как опёнковод со стажем этому совсем не рад.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	167. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Дегенератор (ok), 10-Июл-20, 22:18
	Представляешь, я тоже... Кто-бы мог подумать... Не застрелись там! )))
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (-), 12-Июл-20, 00:36
	та да - во фрю, бывало, дрова из lo0nix'а тащили (некоторые копрорации в поднебесной ведь только для оного и пишут, и то за счастье!), а дрово-растию уже не потащить...
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	178. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от th3m3 (ok), 11-Июл-20, 00:50
	Чтобы писать недостающие драйвера на Rust? :)
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	181. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (180), 11-Июл-20, 01:35
	вот прям раньше никак нельзя было писать эти недостающие дрова? Только достающие?
	Ответить | Правка | Наверх | Cообщить модератору

4. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+3 +/–
Сообщение от Z (??), 10-Июл-20, 12:55
Это неизбежный процесс, слишком много преимушеств даёт Rust
Ответить | Правка | Наверх | Cообщить модератору

	25. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+20 +/–
	Сообщение от Аноним (25), 10-Июл-20, 13:24
	Главное преимущество Rust заключается в том, что на нём сложно написать код с ошибками, поскольку на нём в принципе почти невозможно написать полезный код. Что мы и наблюдаем на примере Redox, Servo и подобных проектов.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (3), 10-Июл-20, 13:37
	но все же бывают и исключения в виде ripgrep, bat, fd. они просто еще мало настоялись
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (60), 10-Июл-20, 13:59
	ripgrep, bat, fd я не против этих "из коробки"
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от анон (?), 11-Июл-20, 12:56
	ag вылизано чуше ripgrep
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	98. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от rioko (?), 10-Июл-20, 16:25
	здесь проблема не в расте как таковом а в сложности упоминаемых проектов первый - ОС второй - браузерный движок у мозилы точно нет денег чтобы потянуть это и раст тут ни при чем.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	107. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+4 +/–
	Сообщение от анонн (ok), 10-Июл-20, 17:18
	> здесь проблема не в расте как таковом а в сложности упоминаемых проектов Здесь скорее проблема в очередном анонимно-диванном анализе вида "возьмем пару подходящих под выводы фактов и озвучим эти выводы с умным видом". Потому что о ржавом CSS движке, которые уже почти 3 года в лисе или том же WebRender или туевой куче ОС уровнем куда хуже RedOx, причем на всевозможных языках https://wiki.osdev.org/Projects - анонимы очень скромно умалчивают. И с умным видом делают выводы уровня "ветер дует потому что деревья качаются - это же всем очевидно!".
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Gogi (??), 11-Июл-20, 19:29
	Почему Си-Сипипям это не мешает??
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	104. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от proninyaroslav (ok), 10-Июл-20, 17:15
	>почти невозможно написать полезный код Разве чтобы написать полезный или бесполезный код нужен специальный язык)?
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	131. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от хрум (?), 10-Июл-20, 20:13
	для того что бы писать полезный код уже был С поэтому придумали руст что бы писать исключительно бесполезный код
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+3 +/–
	Сообщение от анончик (?), 10-Июл-20, 20:38
	Си приктически идеялен, он совмещает в себе быстродействие ассемблера с удобством асемблера.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от proninyaroslav (ok), 10-Июл-20, 20:47
	> для того что бы писать полезный код уже был С А до си уже был ассемблер. Тогда зачем этот бесполезный си? Ну а потом c++ появился, ещё более бесполезный, так как си уже был)
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	190. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
	Сообщение от Аноним (190), 11-Июл-20, 03:54
	> А до си уже был ассемблер. У него был довольно неариятный недостаток, который совершенно случайно заметили разработчики колибри-ОС'а. Решили они как-то перейти с x86 на x86-64 - а тут оказывается вообще все переписывать надо. Представляете себе какое западло? И родили они с горя C--, чтоли, или как там его :). Чота разлюбив ассемблер... (а знаете, прикольно когда драйвер какой-нибудь usb-клавы без изменений взлетает даже на вон том mips'овом роутере, если ему в usb клаву зачем-то подцепить охото)
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (202), 11-Июл-20, 09:00
	C-- был ещё в начале 90х.
	Ответить | Правка | Наверх | Cообщить модератору

	232. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (-), 11-Июл-20, 14:06
	> C-- был ещё в начале 90х. Это 294й из параллельно-альтернативной вселенной. У него там все было по другому - потому и комменты примерно в том же духе.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (139), 10-Июл-20, 21:22
	Что за чушь?
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

5. Скрыто модератором	–1 +/–
Сообщение от A.Stahl (ok), 10-Июл-20, 12:59
>Предложение по обсуждению вопроса добавления Предлагаю обсудить вопрос возможности изменения названия Линукс на Ксидабум-куку.
Ответить | Правка | Наверх | Cообщить модератору

6. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–11 +/–
Сообщение от lockywolf (ok), 10-Июл-20, 13:02
Отлично по-моему. Наконец-то первая операционная система, поддерживающая многоязычное расширение. Кроме Rust неплохо бы ещё C++, GNAT, GFortran, Go и scheme
Ответить | Правка | Наверх | Cообщить модератору

	8. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от danonimous (?), 10-Июл-20, 13:05
	Я бы ещё dart предложил добавить. Canonical поможет.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+15 +/–
	Сообщение от Аноним (14), 10-Июл-20, 13:14
	Про Electron забыли.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от vitalif (ok), 10-Июл-20, 13:17
	Джаббу тогда уже сразу
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	21. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от lockywolf (ok), 10-Июл-20, 13:19
	> Джаббу тогда уже сразу Gcj подзаброшен.
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (190), 11-Июл-20, 03:54
	> Gcj подзаброшен. И даже вроде уже подвыброшен, не?
	Ответить | Правка | Наверх | Cообщить модератору

	306. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (14), 14-Июл-20, 13:38
	Не просто подвыброшен, а выброшен.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (14), 10-Июл-20, 13:21
	Так и Питончик тоже.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	31. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+5 +/–
	Сообщение от Аноним (31), 10-Июл-20, 13:31
	Почему Pascal забыли?
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	48. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+7 +/–
	Сообщение от Аноним (14), 10-Июл-20, 13:44
	Выдаёт недостаточно объёмный размер бинарников.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (-), 10-Июл-20, 13:33
	WASM в ядре пргодлась бы кроме всяких шутоок.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	37. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (7), 10-Июл-20, 13:36
	Подобный проект был на гитхвбе, но автор его удалил. Модуль ядра исполняющий wasm.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (-), 10-Июл-20, 13:43
	Отсюда удалил? https://github.com/wasmerio/kernel-wasm
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (14), 10-Июл-20, 13:43
	Это чтобы ядро в браузере исполнять?
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	68. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от б.б. (?), 10-Июл-20, 14:17
	>  Это чтобы ядро в браузере исполнять? и это в netbsd уже было лет 10 назад, если не больше
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (70), 10-Июл-20, 14:20
	Сравнил самолёт с велосипедом.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Lex (??), 10-Июл-20, 21:06
	Чем ? По сути своей, это тот же JS, который исполняется на базе движка JS, только супер-минифицированный( собсно, в «рекламных буклетах» так и говорят: «ускорение парсинга в сравнении с обычным JS». Про скорость выполнения обычно помалкивают, а то и умалчивают о существующих ограничениях )
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	169. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Весельчак У (?), 10-Июл-20, 22:38
	Это ни разу не js. Это универсальный переносимый формат исполняемых файлов. Выполняется в виртуальной машине. Виртуальная машина решает куда дать доступ и как. Он свободный. Медленный потому что не настоялся.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Lex (??), 11-Июл-20, 06:07
	> Это ни разу не js. Это универсальный переносимый формат исполняемых файлов. Выполняется > в виртуальной машине. Виртуальная машина решает куда дать доступ и как. > Он свободный. Медленный потому что не настоялся. Он исполняется на базе JS-движка, поскольку ключевое применение wasm - это веб и речь о том, применять ли существующие и неплохо работающие штуковины или придумывать совершенно новые, с кучами дыр, багов и это при примерно аналогичном JS функционале( хотя и с некоторыми нюансами ). Самое забавное, что это никто и не скрывает. Да-да, виртуальная машина итп. Всё это уже проходили в JS. В конечном счёте, условно-безопасным( и весьма тормозным ) оно было во времена чистого интерпретатора. С приходом норм скорости ввиду добавления JIT, появилась куча проблем, в т.ч едва ли разрешимых.
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от funny.falcon (?), 11-Июл-20, 10:27
	WASM - ни разу ни про JS. Это реально низкоуровневый байткод. Там нет "объектов, прототипов, массивов, уникодных строк, GC". Все, что там есть, это байтики и команды манипуляции байтиками. И это немного приправлено безопасностью. Ок, еще проковыряна дырка в js мир. Но она опциональна. Многие проекты задумываются о поддержке плагинов на WASM. В основном такие, которым нужна скорость в обработке бинарных данных: сетевых протоколов, музыки, графики.
	Ответить | Правка | Наверх | Cообщить модератору

	227. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Lex (??), 11-Июл-20, 13:06
	Ну я и говорю - супер-минифицированный JS с нюансами( нельзя напрямую работать с DOM-деревом итп - только через прослойку из «классического» JS + допданные для интерпретатора, которые могут помочь оптимизировать ему потребление ресурсов ) Если говорить о чем-то условно-универсальном и низкоуровневом, то почему это касается чего угодно, кроме того же LLVM с его байткодом, хотя много где даже сборка ПО так или иначе его реально касается ? Там не совсем про скорость обработки - там, скорее, про возможность изначально писать код на любом из языков, которые могут приводиться к wasm( насколько помню, это как минимум чуть ли все, которые норм приводятся к llvm ir ), а не только на пихоне.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Онаним (?), 10-Июл-20, 21:55
	> WASM в ядре пргодлась бы кроме всяких шутоок. Не надо. С BPF-то грабли на граблях, а уж WASM в kernel mode - это вообще только для камикадзе.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	67. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от б.б. (?), 10-Июл-20, 14:16
	> Наконец-то первая операционная система, поддерживающая многоязычное расширение. у netbsd lua в ядре уже много-много лет
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	83. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от муу (?), 10-Июл-20, 14:53
	visual basic - индусы мелкомягка с радостью помогут
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	88. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Xasd5 (?), 10-Июл-20, 15:20
	> Наконец-то первая операционная система, поддерживающая... тут в новость про ядро
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	95. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от anonymous (??), 10-Июл-20, 16:10
	Че мелочишься, давай сразу 1С диалект вкорячь. Интеллект программистов ядра Linux сразу деграднет на порядок.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

9. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
Сообщение от Аноним (9), 10-Июл-20, 13:06
Никто не вечен. Даже C.
Ответить | Правка | Наверх | Cообщить модератору

	17. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (17), 10-Июл-20, 13:16
	Ничего не может работать дольше цикла for(;;) на C
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Russter (?), 10-Июл-20, 13:47
	Taimer dumaet inache
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+7 +/–
	Сообщение от Аноним (94), 10-Июл-20, 15:57
	Забавно, что даже в этом коменте о Си закралось UB
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	226. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (225), 11-Июл-20, 13:05
	Почему?
	Ответить | Правка | Наверх | Cообщить модератору

	278. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (278), 12-Июл-20, 16:09
	Тело цикла не указано и не указано, что оно пустое. Может там следующей командой return 0; написано.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (239), 11-Июл-20, 19:00
	А вот в Golang как-то циклы подобные оптимизируют и они там за долю секунды выполняются, а потом спать уходят =)
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

10. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+14 +/–
Сообщение от А10 (?), 10-Июл-20, 13:06
Интересно как будут ментейнить ОС на разных языках? Мне кажется, что разработка ядра не упростится, а в разы усложнится.
Ответить | Правка | Наверх | Cообщить модератору

	27. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+5 +/–
	Сообщение от m.makhno (ok), 10-Июл-20, 13:25
	ну ОС в принципе вещь непростая, многокомпонентная - главное, что бы бинарно она работала как надо
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+8 +/–
	Сообщение от Аноним (14), 10-Июл-20, 13:33
	ОС - да, многоязычие оправдано. А тут ядро.
	Ответить | Правка | Наверх | Cообщить модератору

	244. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Gogi (??), 11-Июл-20, 19:36
	Причём тут "бинарно работала"? Сам-то понял, чё ляпнул? Речь идёт о том, что любой, кто попытается управлять разработкой ядра, сразу же получает граблями в виде "многоязычия". Ты сам-то много языков знаешь? Именно "знаешь" и понимаешь на 100%, а не как большинство лабухов - "писал однажды хелловорлд".
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	256. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от m.makhno (ok), 11-Июл-20, 20:57
	нет, немного; да, понял - ведь всё так или иначе сводится к машинному коду, верно? средство его создания может быть любым, главное - результат...
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (17), 10-Июл-20, 13:29
	Почему? Языки ведь не смешиваются в одном контексте. Одна система на одном языке предоставляет своего рода дополнение API для удобства разработки других систем на других языках. Никого же не волнует на чём именно написаны проприетарные драйвера. Да пусть хоть на питоне ("влинковав" туда всё начиная с libc) пишут если вызовы API, требования к зависимостям, ограничениям на используемые ресурсы и т.д не нарушаются. Проблема может возникать если только это межсистемное API будет часто меняться в угоду той или иной стороне. Ну так вроде и стой и другой стороны достаточно профи, чтобы держать его более или менее стабильным. А дальше уже как пойдёт, появится ли аппетит во время еды сразу или сначала будет количественное увеличение. Там уж видно будет
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	35. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+3 +/–
	Сообщение от m.makhno (ok), 10-Июл-20, 13:35
	меняющийся в угоду чему-либо системный API есть моветон; и как мне кажется, Вы путаете API и ABI
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+4 +/–
	Сообщение от Аноним (14), 10-Июл-20, 13:37
	>Никого же не волнует на чём именно написаны проприетарные драйвера. Людей, заботящихся о безопасности, волнует, чтобы драйвера были опенсорсными. А, следовательно, понятен ли им язык, на котором они написаны, им небезразлично.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	296. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (295), 13-Июл-20, 05:44
	> Людей, заботящихся о безопасности, волнует, чтобы драйвера были опенсорсными. > Людей, заботящихся о безопасности, Вы совершили очень много ошибок во фразе "Людей, поехавших на столмановских идеях". Ах ну да, студентов еще это волнует и прочих кому телефончики перешивать на кастомную прошивку. Я могу понять что вам там не всё равно, и религия обязывает, но не надо врать про безопасность. Сидите с Intel ME или аналогичными от AMD с кучей аппаратного DRM  в компе и смартфоне, в котором,, кстати проприетарный модем, до которого вы SoC-ком не достанете, а он вам код в системе выполнит да так, что не заметите. > А, следовательно, понятен ли им язык, на котором они написаны, им небезразлично. Летели два крокодила, один зелёный второй налево. Как зовут бабушку дворника? Ничерта не следовательно! Если студент аргументирует религиозное желание (небось, от преподов досталось) видеть код драйвера безопасностью, то это не значит что ему, вдруг, можно не учить язык. А то это удобненько получается "учить не хочу, код дай, и все бесплатно" и все это во имя "безопасности", о которой он и знать ничего не знает... ну кроме разве контрацепции, которая, как известно, у таких естественная.
	Ответить | Правка | Наверх | Cообщить модератору

	315. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (315), 14-Июл-20, 23:10
	Смартфончиками не пользуюсь принципиально. Поэтому и перепршивать нечего. И что с того, что мы вынуждены использовать процессоры с аппаратными уязвимостями? Это отнюдь не оправдывает наплевательское отношение к софту. При любой возможности количество уязвимостей нужно МИНИМИЗИРОВАТЬ. Нет у меня в компе модема. И смартфона нет.
	Ответить | Правка | Наверх | Cообщить модератору

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

11. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+3 +/–
Сообщение от Fracta1L (ok), 10-Июл-20, 13:10
Это круто, что ядро не держится за прошлое и продолжает эволюционировать
Ответить | Правка | Наверх | Cообщить модератору

	28. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+8 +/–
	Сообщение от Аноним (14), 10-Июл-20, 13:27
	Раз пошла такая пьянка, то пусть лучше Л. Торваальдс запилит свой специализированный kernel-lang для ядра. В прошлый раз, с системой управлениями версиями, у него круто вышло. Взлетело и далеко за пределами ядра.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+4 +/–
	Сообщение от Аноним ВВП (?), 10-Июл-20, 13:39
	Тогда ему нужен еще один срок молодости с обнулением.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от Аноним (14), 10-Июл-20, 13:46
	Ну Git он после 30-ти запилил, поэтому справится.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+3 +/–
	Сообщение от Аноним (80), 10-Июл-20, 14:47
	Готов отдать свою. Она все равно у меня в пустую потратится
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	105. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от proninyaroslav (ok), 10-Июл-20, 17:16
	Ему и си хватает.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	314. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (315), 14-Июл-20, 22:49
	Ему-то хватает. Но его окружают инклюзивные. И их всё больше и больше. Отбиваться становится всё сложнее. Поэтому, если возможность, то лучше возглавить, взять инициативу в свои руки.44
	Ответить | Правка | Наверх | Cообщить модератору

	316. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от proninyaroslav (ok), 14-Июл-20, 23:10
	И как это спасёт от запрета принятия других языков в ядро? Он и в текущей ситуации мог бы сказать "только си и ничего другого", но ведь не сказал.
	Ответить | Правка | Наверх | Cообщить модератору

	317. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (315), 14-Июл-20, 23:38
	Если сам придумает kernel-язык со всякими @safe и прочими шахматами, окружающие могут хайпануть на новинку. Нынешние модномолодёжные языки могут отодвинуться на второй план.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от OpenEcho (?), 11-Июл-20, 00:33
	Он совсем недавно говорил что вообще больше не програмирует, переписка, консультация, короче бюрократия засосала
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	236. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (236), 11-Июл-20, 16:36
	Это очень плохо что вместо замечательного, безопасного и удобного Си, будет дырявый, тормозной и убогий rust Rust нужно запретить
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	246. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Gogi (??), 11-Июл-20, 19:40
	Ну он не то, чтобы "убогий", но без ООП это г***вно не нужно вообще. И работа с объектами сложная - все эти "передачи владения". Никто этим заниматься не будет, а значит будут бесконечно наступать на грабли.
	Ответить | Правка | Наверх | Cообщить модератору

12. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–7 +/–
Сообщение от Аноним (12), 10-Июл-20, 13:10
А между тем чтобы собрать сам компилятор Rust стабильной версии, нужен бинарник предыдущего компилятора, возможно даже из бета-ветки. То есть чтобы собрать Rust без скачивания бинарников от Mozilla, надо... Какая там версия? Скомпилировать 43+ компилятора для Rust предыдущих версий, и проблема только разрастается со временем.
Ответить | Правка | Наверх | Cообщить модератору

	18. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (15), 10-Июл-20, 13:16
	кто тебе такую чушь сказал?
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
	Сообщение от Аноним (12), 10-Июл-20, 13:53
	Я с ней столкнулся, когда собирал, по документации: https://rustc-dev-guide.rust-lang.org/building/how-to-build-...
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+7 +/–
	Сообщение от lockywolf (ok), 10-Июл-20, 13:21
	> А между тем чтобы собрать сам компилятор Rust стабильной версии, нужен бинарник > предыдущего компилятора, возможно даже из бета-ветки. То есть чтобы собрать Rust > без скачивания бинарников от Mozilla, надо... Какая там версия? Скомпилировать 43+ > компилятора для Rust предыдущих версий, и проблема только разрастается со временем. Ну так gcc тоже собирается с помощью gcc.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	54. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
	Сообщение от Аноним (12), 10-Июл-20, 13:49
	Да, там эта проблема тоже есть, но не в таких масштабах, не 5-8 компиляторов в цепочке максимум для сборки последнего GCC
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+3 +/–
	Сообщение от Аноним (89), 10-Июл-20, 15:27
	gcc можно собрать используя clang. Сколько сторонних компиляторов есть для Rust?
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	120. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (120), 10-Июл-20, 19:41
	Эта проблема есть у любого языка, компилятор которого пишется на нем самом. Даже у typescript она есть, а уж с Rust-то компилятор на C выглядел бы совсем глупо :-)
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	127. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (127), 10-Июл-20, 19:50
	Зацени на досуге от куда берется компилятор gcc в LFS.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	132. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Какаянахренразница (ok), 10-Июл-20, 20:29
	С хостовой системы. Но он там собирается 3 раза, вроде: - host-gcc собирает target-gcc из сорцов - target-gcc, собранный при помощи host-gcc, собирает target-gcc - target-gcc, собранный при помощи target-gcc, собирает target-gcc
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (198), 11-Июл-20, 06:48
	да, в LFS оно берется из хост-системы. А вот Guix, например, работает над уменьшением количества доверенных бинарников до минимума, и там новые версии gcc собираются старыми, а одна из старых компилируется tcc (tiny c compiler), а tcc компилируется их самописным компилятором на лиспе, а в начале этой цепочки GNU Mes (маленький лисп и компилятор си, вроде даже на том же лиспе). Ну и в целом как-то оно неправильно, что каждый новый компилятор у Rust написан на новом языке, для которого нужен новый компилятор. Над минимализацией количества доверенных бинарников надо работать, а то закроется static.rust-lang.org, и как вы будете без бинарников собирать Rust? Да так и будете, версия за версией, начиная с той версии, которая не на Rust. у Gcc легче, там следующая версия зависит не от предыдущей, а от какой-нибудь пред-пред-предыдущей, то есть не пытаются сразу пихать в компилятор свистелки и тут же на них писать следующий компилятор, как это делается с Rust. Безусловно, это тоже проблема и ее тоже как-то нужно решать, потому что в перспективе это оборачивается слишком большим количеством source-зависимостей
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	228. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (225), 11-Июл-20, 13:09
	чтобы собрать компилятор rust нужен компилятор! Это фатальный недостаток языка!
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	260. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Ordu (ok), 11-Июл-20, 23:44
	> Скомпилировать 43+ компилятора для Rust предыдущих версий Нет, не 43. Я не скажу в точности сколько, последний раз я наблюдал активность по бутстрапу rust'а в блоге guix[1]. Там фишка в том, что на C++ написан mrust, который неполноценный раст, он исходит из того, что ему подсовывают корректный код, и на этом экономит кучу сложности. И этот mrust может сходу скомпилировать rust-1.19, то есть уже 43-19. Если пройтись по ссылке на github mrust'а[2], то там написано, что он аж rust-1.29 может собрать сейчас. То есть 43-29 версий придётся пересобирать. Но при этом сейчас ведь появились эдишны. Я не помню, как там разработчики rust'а сами отреагировали на своё нововведение: придерживаются ли они rust2018, когда пилят rustc, или продолжают налево и направо фишки из беты использовать. [1] https://guix.gnu.org/blog/2018/bootstrapping-rust/ [2] https://github.com/thepowersgang/mrustc
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

16. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+15 +/–
Сообщение от Аноним (25), 10-Июл-20, 13:15
Фанатизм. С++ в ядре им не нравится, хотя в виндовом ядре он неплохо себя чувствует в некоторых подсистемах, а инородный Rust, который не поддерживает и половины аппаратных платформ Linux, им непременно там зачем-то нужен.
Ответить | Правка | Наверх | Cообщить модератору

	46. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (46), 10-Июл-20, 13:43
	А в этом, "С++ в виндовом ядре" - есть RAII? а исключения есть?
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от n00by (ok), 10-Июл-20, 13:59
	> А в этом, "С++ в виндовом ядре" - есть RAII? RAII не требует поддержки времени выполнения, так что не понятно, о чём вопрос. Есть. Микрософт в своём коде (примерах) раньше не использовали. > а исключения есть? Если понимать, что такое arbitrary thread context и IRQL, то местами возможно использовать.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (70), 10-Июл-20, 14:22
	Конечно есть RAII. И есть шаблоны. Нет исключений и фишек, обечпечиваемых рантаймом.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	73. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (70), 10-Июл-20, 14:30
	Точнее даже исключения ограниченно присутствуют, как заметили выше.
	Ответить | Правка | Наверх | Cообщить модератору

	307. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (303), 14-Июл-20, 15:52
	Я вам больше скажу, что этот аноним, что n00by врут и не краснеют. Он в другой части треда мне пафосно воображает про С++ и драйверы. Начиная с Windows 8.1 старый API UMDFv1, который позволял писать драйверы пространства пользователя меняют на UMDFv2, где опять только С и нету С++ COM API. Вот код WRK. Ядро, которое RING 0 там на С. https://github.com/Zer0Mem0ry/ntoskrnl Это WRK, но недавно утекали полные сорцы десятки. Если интересуют прямо полные исходники сами их ищите, они есть. А вот примеры драйверов https://github.com/microsoft/Windows-driver-samples Те которые цепляются напрямую ядру без юзерспейсных прослоек тоже все на С и обязаны быть на С. Ядро NT не настолько монолитное, как Linux. Там есть куча подсистем, которые, строго говоря, не часть ядра, но ядро с ними взаимодействует. Всё ядро написано на С. Все что сидит в юзерспейсе преимущественно на С++, но оно, блин, в юзерспейсе. Это не драйверы а одно названием. Им выдано API и дальше него они не могут выскочить. Это кстати касается всех юзерспейсных драйверов в том числе тех подсистем, которые MS-ом написаны.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	53. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (53), 10-Июл-20, 13:47
	Си плюс-плюс вреден в ситемщине. Пусть Майкрософт пилит своё ядро на чём ему вздумается. На божественные Юниксы Си плюс-плюс не пускать!
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	56. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (14), 10-Июл-20, 13:52
	Ну таки здесь, вроде как, Linux не принято считать UNIX-ом?
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (70), 10-Июл-20, 14:25
	В ядре макоси C++ давно есть, а это самый натуралный юникс. Так что мимо.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	130. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (120), 10-Июл-20, 20:01
	В XNU подмножество C++ (Embedded C++) и специальные компиляторы с оптимизациями именно под ембедовку. Если изначально так ядро проектировать - это одно, а прикрутить нечто подобное к Linux kernel - задача если и решаемая, то трудозатраты будут огромными.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (192), 11-Июл-20, 04:10
	> В XNU подмножество C++ (Embedded C++) и специальные компиляторы с оптимизациями именно > под ембедовку. Только чего-то именно в эмбедовке этой XNU и нету как раз.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (193), 11-Июл-20, 05:15
	А apple watch - это не ембедовка что ли?
	Ответить | Правка | Наверх | Cообщить модератору

	266. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от anonimous (?), 12-Июл-20, 01:27
	Осей для микроконтроллеров на с++ написано много уже давно. Работают.
	Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

	234. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (234), 11-Июл-20, 15:30
	Ага, специальный clang с секретными оптимизациями, а до этого был особый аненербе-гцц. >Если изначально так ядро проектировать Изначально это антикварный MACH на С, тот же самый что и в хурде, к которому прикрутили подсистему для драйверов на плюсах.
	Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

	62. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от n00by (ok), 10-Июл-20, 14:06
	> Фанатизм. С++ в ядре им не нравится, хотя в виндовом ядре он > неплохо себя чувствует в некоторых подсистемах, а инородный Rust, который не > поддерживает и половины аппаратных платформ Linux, им непременно там зачем-то нужен. Всё таки сравнение не совсем корректно. Там ядро закрытое, потому драйвера пишут кто во что горазд. Здесь код открыт, и когда всё исполнено в одном духе и стиле -- воспринимать проще.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	64. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Sauron (??), 10-Июл-20, 14:07
	Ну так пусть пишут дайверы там где llvm работает.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	75. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (75), 10-Июл-20, 14:33
	Rust использует LLVM как бэкэнд, а LLVM поддерживает все основные платформы, на которых актуально текущее ядро Linux.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	86. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Xasd5 (?), 10-Июл-20, 15:09
	наверно не хватает ещё одной надписи, ато без неё будет разрыв в построении логической цепочки: "Rust поддерживает все те же платформы которые поддерживает его бэкэнд" (я этого НЕ знаю -- просто написал что этой фразы не хватет)
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от qetuo (?), 10-Июл-20, 15:44
	>я этого НЕ знаю -- просто написал что этой фразы не хватет Не волнуйтесь, здесь ни вы ничего не знаете, ни добрых три четверти остальных комментаторов. И ничего, нормально живут.
	Ответить | Правка | Наверх | Cообщить модератору

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

	123. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+4 +/–
	Сообщение от Аноним (120), 10-Июл-20, 19:44
	C++ без libstdc++ штука не особенно осмысленная, а какая может быть стандартная библиотека в ядре? Ну, да, классы - но и всё. "Си с классами" можно писать и на С, со структурами и указателями на функции - примерно то же самое получится (см. модули nginx как пример). А Rust именно как язык, безо всяких библиотек, дает преимущества.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	171. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (171), 10-Июл-20, 23:14
	Стандартная библиотека в ядре - не большая проблема: есть стандартные библиотеки C++ для микроконтроллеров.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (193), 11-Июл-20, 05:16
	В ядре, которое изначально пишется с использованием этой библиотеки - конечно, не проблема. А в линуксе... ну только если свою хедерную обертку вокруг уже имеющейся инфраструктуры написать
	Ответить | Правка | Наверх | Cообщить модератору

20. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+5 +/–
Сообщение от Аноним (14), 10-Июл-20, 13:18
Пока фронтенд для Rust не добавят в GCC, рано говорить об его применении в разработке ядра.
Ответить | Правка | Наверх | Cообщить модератору

	44. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним ВВП (?), 10-Июл-20, 13:40
	Такой проект уже есть для gcc. Мимо.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (14), 10-Июл-20, 13:50
	Да слышал. Вот только вяло он шевелится, даже попыток принятия-включения не видно.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от proninyaroslav (ok), 10-Июл-20, 17:17
	Думаю тянуть гигантский статический анализатор в gcc никто не будет. Если только анализатор не будет выделен в отдельный компонент, такая работа уже идёт вроде.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	182. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (180), 11-Июл-20, 01:51
	в здравом уме конечно никто не будет ... но не у всех ум здравый.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (120), 10-Июл-20, 19:45
	У gcc ворох архитектурных проблем с монолитностью, накопившихся за долгое время жизни проекта. Их понемногу решают, но это долгий путь.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

24. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+4 +/–
Сообщение от Аноним (24), 10-Июл-20, 13:21
Меня заставят учить раст чтобы собирать модули? Мои глаза не выдержат такого синтаксиса.
Ответить | Правка | Наверх | Cообщить модератору

	125. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (120), 10-Июл-20, 19:46
	_Собрать_ модуль можно не зная ни Раста, ни Си, ни даже Бейсика, в чем проблема?
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
	Сообщение от анон (?), 11-Июл-20, 10:44
	В том, что он соберется не так, как мне нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–3 +/–
	Сообщение от Fracta1L (ok), 10-Июл-20, 20:36
	Это ещё и плюсуют лол
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	142. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (139), 10-Июл-20, 21:27
	Что не так с синтаксисом? После C как глоток свежего воздуха на берегу океана, проще и понятнее, нет остатков многовековой совместимости
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	183. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (180), 11-Июл-20, 01:55
	иди и пиши свою ось, захер лезть в чужую и ломать её?
	Ответить | Правка | Наверх | Cообщить модератору

	231. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (-), 11-Июл-20, 13:57
	> иди и пиши свою ось, захер лезть в чужую и ломать её? Месье Торвальдс собственной персоной? Или очередной аноним, ничихуахуа ядерного вообще не написавший, зато в крутой маечке с пингвинчиком?
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от коржик (?), 11-Июл-20, 06:57
	И никакой конкретики
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

26. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
Сообщение от Анонолекс (?), 10-Июл-20, 13:25
Посмотрим что получится, а дальше будет видно. Может пора уже на GNU/HURD валить...
Ответить | Правка | Наверх | Cообщить модератору

	30. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
	Сообщение от Аноним (14), 10-Июл-20, 13:30
	Для начала его нужно допиливать/перепиливать, а потом валить.
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (180), 11-Июл-20, 01:57
	с растом почему-то не так
	Ответить | Правка | Наверх | Cообщить модератору

34. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
Сообщение от Аноним (34), 10-Июл-20, 13:35
Осталось изменить логотип Линукса на радугу, для полного счастья.
Ответить | Правка | Наверх | Cообщить модератору

	58. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (14), 10-Июл-20, 13:55
	Не, пингвина заменять не нужно. Вот только чёрный пингвин это неполиткорректно. Радужный пингвин - самое то!
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от Аноним (127), 10-Июл-20, 19:55
	>Вот только чёрный пингвин это неполиткорректно Нет, это ты расист.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Анонолекс (?), 11-Июл-20, 00:39
	Черный - это не цвет, это его отсутствие... Тоже применимо и к нашей бытовухе и то фигне, что сейчас творится в мире...
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	185. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (180), 11-Июл-20, 01:59
	не путайте цвет и свет.
	Ответить | Правка | Наверх | Cообщить модератору

	247. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Gogi (??), 11-Июл-20, 19:44
	Если ты проссал всю физику в школе, то объясню: это ОДНО И ТО ЖЕ.
	Ответить | Правка | Наверх | Cообщить модератору

36. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
Сообщение от Аноним (36), 10-Июл-20, 13:36
Стоп а разве rust не компилируемый язык ? (еще раз перечитал заголовок ... ничего не понятно)
Ответить | Правка | Наверх | Cообщить модератору

	92. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от lockywolf (ok), 10-Июл-20, 15:52
	> Стоп а разве rust не компилируемый язык ? > (еще раз перечитал заголовок ... ничего не понятно) Компилируемость тут ни при чём, имеет смысл говорить, "генерящие elf-объекты". (Интерпретируемые языки тоже могут генерить elf.) Но (а) нужно согласовывать линковочные символы. Для этого кое-какая работа нужна. И (б) вопрос ещё не только в том, чтобы писать объектники, а ещё в том, чтобы код на русте стали принимать в ядро.
	Ответить | Правка | Наверх | Cообщить модератору

38. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
Сообщение от Tronis (?), 10-Июл-20, 13:36
Ну да давайте весь мусор в ядро тащить...
Ответить | Правка | Наверх | Cообщить модератору

	59. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (14), 10-Июл-20, 13:58
	Да, палец у Линуса уже не тот...
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–4 +/–
	Сообщение от Аноним (139), 10-Июл-20, 21:28
	Мусор не надо, но действительно крутые вещи вроде Раста - стоит
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

42. Скрыто модератором	–3 +/–
Сообщение от malloc (?), 10-Июл-20, 13:39
Мальчики, почему все постоянно забывают, что у руста есть проблема с лицензией? Все произведения на русте автоматически принадлежат компании мозилла. Почему все игнорируют лицензионное соглашение, по которому распространяется rust? Лицензия руста несовместима с gpl v2. Кроме того, есть проблема: рустовые фанбои с пеной у рта и в конвульсиях в истерике кричат, что обязательно на русте надо писать safe-код. Но в случае ядра и его модулей это технически невозможно. И почему если поехавшим от руста срать в ядро можно, то любителям lisp, haskell и прочим это запрещено? Нужны биндинги для всех языков, а не только для тех, чьи представители отличаются диагнозом шизофрения или склонность к психозам и истерикам от обычных людей?
Ответить | Правка | Наверх | Cообщить модератору

	50. Скрыто модератором	+2 +/–
	Сообщение от Fracta1L (ok), 10-Июл-20, 13:45
	Прими таблетки
	Ответить | Правка | Наверх | Cообщить модератору

	65. Скрыто модератором	+2 +/–
	Сообщение от burjui (ok), 10-Июл-20, 14:10
	Иногда бывает так: читаешь комментарий и не понимаешь - то ли автор шутит, то ли со стационара сбежал.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	69. Скрыто модератором	+/–
	Сообщение от Аноним (69), 10-Июл-20, 14:17
	> Мальчики, почему все постоянно забывают, что у руста есть проблема с лицензией? Все произведения на русте автоматически принадлежат компании мозилла. https://github.com/rust-lang/rust/blob/master/COPYRIGHT Я извиняюсь, а о какой лицензии идет речь? > Кроме того, есть проблема: рустовые фанбои с пеной у рта и в конвульсиях в истерике кричат, что обязательно на русте надо писать safe-код. Но в случае ядра и его модулей это технически невозможно. https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html "Using unsafe to take one of the five actions (superpowers) just discussed isn’t wrong or even frowned upon. But it is trickier to get unsafe code correct because the compiler can’t help uphold memory safety. When you have a reason to use unsafe code, you can do so, and having the explicit unsafe annotation makes it easier to track down the source of problems when they occur." Примерный перевод: "Использование unsafe обсужденного ранее не является неправильным и не считается плохим." > И почему если поехавшим от руста срать в ядро можно, то любителям lisp, haskell и прочим это запрещено? Нужны биндинги для всех языков, а не только для тех, чьи представители отличаются диагнозом шизофрения или склонность к психозам и истерикам от обычных людей? Потому что создатель ядра и коммьюнити которое разрабатывает ядро видит смысл в добавлении поддержки rust и кто-то занимается имплементацией этой самой поддержки?
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	147. Скрыто модератором	–1 +/–
	Сообщение от Michael Shigorin (ok), 10-Июл-20, 21:36
	> И почему если поехавшим от руста срать в ядро можно, то любителям > lisp, haskell и прочим это запрещено? Потому что культура.  Впрочем, с ними айда к нам, будете в хорошей компании. :) http://altlinux.org/alterator http://altlinux.org/Haskell_Porting_Initiative
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

43. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
Сообщение от КО (?), 10-Июл-20, 13:40
Пускай занимается в гугл и дальше Зачем пихать и занимать место всяким ненужным компиляторам на ПК домохозяйки...
Ответить | Правка | Наверх | Cообщить модератору

49. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
Сообщение от Аноним (53), 10-Июл-20, 13:45
1. Небезопасный Раст - это чистый Си с проверками на безопастность. Никто, чистый Си без дополнительных инструментов не использует. 2. Я против, не потому-что Раст сложен. А потому-что, на какой-то стадии появится опасная возможность использования 2 компиляторов для компиляции ядра Линукса. 3. Для компиляции ядра Линукса не используются сишные библиотеки. А если Растаманы в каких-то компонентах пожелают использовать рантайм-библиотеки? 4. Пусть Растаманы пилят свой Redox и пусть Раст не выходит за пределы экосистем Redox и Servo.
Ответить | Правка | Наверх | Cообщить модератору

	74. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+3 +/–
	Сообщение от Аноним (75), 10-Июл-20, 14:30
	А то, что без perl ядро не соберется вас не пугает? Уже привыкли?
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Xasd5 (?), 10-Июл-20, 14:51
	а разве предлагают убрать perl (в случае появления rust)? (или ты один из тех кто думает что указав на какую-то проблему ты замаскируешь текуще обсуждаемую проблему? как это любят вещать в зомпоящиках в авторитарных странах)
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от анонн (ok), 10-Июл-20, 14:59
	> а разве предлагают убрать perl (в случае появления rust)? > (или ты один из тех кто думает что указав на какую-то проблему > ты замаскируешь текуще обсуждаемую проблему? как это любят вещать в зомпоящиках в авторитарных странах) То ли дело обозвать набор дикой чуши (см. хотя бы первый пункт с "небезопасностью" и третий пункс с бурной фантазией "если бабушка была бы дедушкой") "обсуждаемой проблемой"?
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
	Сообщение от Xasd5 (?), 10-Июл-20, 15:02
	> третий пункс с бурной фантазией "если бабушка была бы дедушкой" а как иначе? не ясно же что им в голову придёт теперь :-) .. им Rust разрешат и они на этой эфории понесут новые идеи
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Xasd5 (?), 10-Июл-20, 15:15
	> ... и они на этой эфории понесут новые идеи ... а потом как обычно говорят такие люди -- "ой! что-то мне Open Source надаел. теперь семья/дети/работа_грузчиком -- поддерживайте сами теперь это" (после внедрения эпических костылей, реализовывающих все их сокровенные влажные фантазии!)
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от DEV (?), 10-Июл-20, 19:07
	о каких костылях речь?
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Xasd5 (?), 10-Июл-20, 14:37
	всё верно. каждый пункт по делу
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	102. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
	Сообщение от Ordu (ok), 10-Июл-20, 17:01
	> 1. Небезопасный Раст - это чистый Си с проверками на безопастность. Никто, чистый Си без дополнительных инструментов не использует. Небезопасный раст если и безпаснее Си, то только потому, что там нет UB. А безопасный раст -- это не просто статический анализатор накручен сверху C, это когда задумка программиста описывается типами и алгоритмами. То есть в типах кодируются многие ограничения на то, что можно делать, а что нет. В случае C такие ограничения могут существовать только пока программист на C о них помнит. > 2. Я против, не потому-что Раст сложен. А потому-что, на какой-то стадии появится опасная возможность использования 2 компиляторов для компиляции ядра Линукса. Чем же она опасна, эта возможность? Может ты хотел сказать "неприятность, в виде необходимости использования двух компиляторов", а слово "опасность" просто ассоциацией к C выскочило? > 3. Для компиляции ядра Линукса не используются сишные библиотеки. А если Растаманы в каких-то компонентах пожелают использовать рантайм-библиотеки? Что значит "не используются"? В ядре куча всяких разных библиотек. И написаны они на C. > 4. Пусть Растаманы пилят свой Redox и пусть Раст не выходит за пределы экосистем Redox и Servo. Мечтай дальше. Твои хотелки нас не остановят.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	108. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от proninyaroslav (ok), 10-Июл-20, 17:23
	2. а про сборку ядра clangом уже забыли)? 3. в расте есть no_std. и пожелать использовать рантайм они не смогут при всём желании так как просто не скомпилируется 4. действительно, зачем этот раст вообще в продакшен пускать
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

63. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–3 +/–
Сообщение от Аноним (63), 10-Июл-20, 14:07
>нужно ли вообще добавлять такую поддержку Ни в коем случае. Rust-программисты - это те же вебмакаки. Cargo - это тот же npm, только для rust.  Даже простая сборка hello-world ядерного модуля тянет ворох зависимостей из crates. При этом для crates нет цифровых подписей, а система сборки при сборке может исполнять произвольный код, скачанный с crates в виде пакета. Большинство раст-пакетов требуют ночную версию раст, которой нет в дистрибутивах и которую предлагается ставить с помощью curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh . Добавление этого в ядро, а также подключение и включение вебмакак и их любимых подходов в разработку ядра, приведёт к тотальной и необратимой компрометации критической инфраструктуры.
Ответить | Правка | Наверх | Cообщить модератору

	78. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Xasd5 (?), 10-Июл-20, 14:43
	скачивание какого-то говна из интернетов для очередной компиляции ядра (при этом у каждого интернет разный -- и прилететь может разное) -- совсем не радует. поидее бы -- нужно запретить использование Cargo -- для целей компиляции ядра. но с другой стороны Растоманы зачастую считают что cargo это неотъемлимая часть Rust.. и всячески активно его используют (создавая огромные каскады зависимостей, также как js-программиты со своими сраным npm). это наверно как говорить "вот тебе пиши на C++ , но объектами пользоваться запрещаю!"
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от анонн (ok), 10-Июл-20, 14:49
	> Большинство раст-пакетов требуют > ночную версию раст, которой нет в дистрибутивах и которую предлагается ставить > с помощью curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh . % pkg search nightl                                                               rust-nightly-1.46.0.20200630   Language with a focus on memory safety and concurrency Че там у вас в WSL-like нет, никому особо не интересно.
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	145. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (139), 10-Июл-20, 21:34
	А C-программисты живут словно и 80ых, и поэтому не вебмакаки, да? И вообще, использование современных средств - плохо! Нужно, как и раньше, все расчеты проводить на калькуляторе! Нет, счетах, калькуляторы слишком современны. Как раз один из основных минусов C/C++ - отсутствие дефолт пакетного менеджера, который есть во всех современных актуальных языках. Это не в контексте ядра, разумеется, но факт остаётся фактом.
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	206. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от Анонолекс (?), 11-Июл-20, 10:12
	Дефолтный пакетный менеджер для Си/Си++ - это пакетный менеджер дистрибутива. Испокон веков всех всё устраивало, пока не народилось поколение воинствующих обезьянок.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
	Сообщение от Аноним (219), 11-Июл-20, 11:49
	Как раз таки никого и не устраивало, перенести приложение, а тем более проект тот ещё гемморой из НИЧЕГО. А как это сейчас. Пересобирать приложение для каждого дистрибутива, ну ок, бл*ть ещё и зависимости в другом месте лежат, ну ок, в evn наверное пути есть..нихера и началось. Тратишь время на решение никому ненужной проблемы. Пакетные менеджеры языков решают все эти проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

	301. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (63), 13-Июл-20, 12:09
	Не нужно. Портанутые alienом пакеты прекрасно работают на чужом дистре и на его либах. Для сборки есть pkg-config и CMake - дистрибутив-нейтральные и даже платформо-нейтральные способы поиска зависимостей в системе. Используй их и о геморрое можешь забыть. Не используй их, и огреби геморроя. Пакеты должны собираться авторами дистра. Они хоть какой-никакой аудит делают, в отличие от говна, качаемого из conan/pip/cargo/npm, которое не смотрит никто и никогда, потому что никому не надо: 1. Разраб пакета? Он либо себе доверяет, что он не вставлял бэкдор, либо вставляет бэкдор, и тогда ему не надо, чтобы его нашли. 2. Контрибьютор? Да он из гита для себя соберет, пакеты из репозиториев пересобирать ему не уперлось. 3. Пользователь либы? Так даже если там и есть бэкдор, и если он его найдёт, ему придётся тогда фиксить сам пакет, и зависящие от него. Если он его найдёт. А искать бэкдоры - это сложнее, чем искать уязвимости. А для поиска уязвимостей есть специализированная компания - Zerodium, которая платит рыночную цену (выше рыночной платить не имеет смысла, ниже - тоже). Соответственно, бесплатно искать бэкдоры тоже не имеет смысла. Поэтому: херак, херак - и в продакшн. Поимеют клиентов бэкдором - ну значит force majeure, c'est  la vie, вебмакака не виновата, это всё злой бэкдорер, агу-агу. Разумеется, реально серьёзные конторы так не работают.
	Ответить | Правка | Наверх | Cообщить модератору

66. Скрыто модератором	–1 +/–
Сообщение от Аноним (63), 10-Июл-20, 14:12
>Исследователи из Китайского университета в Гонконге развивают проект для обеспечения мирового доминирования Китайской Народной Республики
Ответить | Правка | Наверх | Cообщить модератору

77. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
Сообщение от richman1000000 (ok), 10-Июл-20, 14:40
зачем на RUST? Давайте сразу на Python+java... Если уж переплавлять ядро в ведро то сразу и основательно!
Ответить | Правка | Наверх | Cообщить модератору

	79. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Xasd5 (?), 10-Июл-20, 14:46
	причём надо не просто Java -- а также написать Генератор который исходники на C превратит в Java. то есть так чтобы при этом код (Java) оказался бы похож на говно, как оно и бывает после выхода всех этих Генераторов.. (а не только жрал бы дофига памяти).
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от Аноним (139), 10-Июл-20, 21:36
	Эм. Как можно сравнить язык по производительности на уровне C/C++ с Джавой и тем более тормознейшим Питоном? Что у вас вообще в головах, откуда такая чушь льется?
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	186. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (180), 11-Июл-20, 02:11
	ты застрял где-то в вин95
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (-), 12-Июл-20, 00:47
	а чё, в твоей персональной вселенной уже поди писюн без GIL да java без сборщика мусора, да? ;) прими таблетки и удались, стильный-модный-молодёжный.
	Ответить | Правка | Наверх | Cообщить модератору

93. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
Сообщение от leap42 (ok), 10-Июл-20, 15:52
> Возможность разработки драйверов на языке Rust позволила бы с минимальными усилиями создавать... Сразу видно, писал человек написавший ровно 0 реальных проектов на Rust (я писал если что, хоть и for fun) > безопасные и более качественные драйверы, избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера лол! буквально в этом году был баг пофикшен (уж не помню во фронтенде или в llvm), из-за которого borrow checker не работал как положено. т.е. никто за ним не проверял (зачем?)) а тот не работал xD
Ответить | Правка | Наверх | Cообщить модератору

	149. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от Аноним (139), 10-Июл-20, 21:39
	После некоторого порога входа, какие такие особые усилия необходимо прилагать? Пишешь и наслаждаешься А по поводу бага - суть в том, что в UB/UB++ это задокументированное стандартное поведение, а для Раста - лютый баг :)
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от leap42 (ok), 11-Июл-20, 03:08
	> После некоторого порога входа, какие такие особые усилия необходимо прилагать? это на borrow cheker и владение намек? так то - миф, его какие-то обезьяны-теоретики форсят. программисту, который понимает как работает память (т.е. писал профессионально на C/C++/Go) нет проблем разобраться. усилия на настоящем проекте надо прилагать огромные. именно поэтому в авангарде реального софта на Rust 7% Firefox и консольные утилиты 70-х годов > Пишешь и наслаждаешься для этого нужен простой, незамусоренный синтаксис, богатая стандартная библиотека (чтобы проект не вставал колом каждый раз, когда какая-то истеричка удаляет свой crate + чтобы не вникать в чужой код для его починки, в стандартной библиотеке код точно хорош, а вот в crate может быть только на словах) > А по поводу бага - суть в том, что в UB/UB++ это > задокументированное стандартное поведение, а для Раста - лютый баг :) если бы вы писали на Си, то пользовались бы несколькими тулами для отлова граблей. в Rust она такая одна, и она не работала. две большие разницы - стрелять себе в ногу, хотя тебя предупреждали, и стрелять себе в ногу, хотя тебя уверяли, что это вообще невозможно
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (234), 11-Июл-20, 16:08
	>для этого нужен простой, незамусоренный синтаксис, богатая стандартная библиотека И этого всего в Си нет, лол! >если бы вы писали на Си, то пользовались бы несколькими тулами для отлова граблей Вот с этого места пожалуйста подробнее.
	Ответить | Правка | Наверх | Cообщить модератору

	274. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от leap42 (ok), 12-Июл-20, 13:50
	>>для этого нужен простой, незамусоренный синтаксис, богатая стандартная библиотека > И этого всего в Си нет, лол! >>если бы вы писали на Си, то пользовались бы несколькими тулами для отлова граблей > Вот с этого места пожалуйста подробнее. анализатор clang, cppcheck, asan/ubsan ну и конечно "-Wall -Wextra -Wpedantic -Wshadow -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wconversion" для компилера - это современный стандартный набор
	Ответить | Правка | Наверх | Cообщить модератору

	272. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Anonn (?), 12-Июл-20, 12:52
	>буквально в этом году был баг пофикшен (уж не помню во фронтенде или в llvm), из-за которого borrow checker не работал как положено А можно поподробнее? Друг интересуется
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	288. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (288), 12-Июл-20, 20:18
	Всмысле не работал?:) Хрень пишете да?:) Он действительно некоторые ситуации допускал, а некоторые более простые ситуации запрещял. (при этом я не говорю что он не работал, он просто некоторые вещи допускал..) Его просто улучшили...
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

96. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
Сообщение от Аноним (96), 10-Июл-20, 16:17
Я против Rust в ядре, так как считаю что код в ядре не должен использовать каких-то встроенных в язык рантайм библиотек. Им не место в ядре. Если хотят писать модули для ядра - наверное это и сейчас можно, а в ядро пусть не лезут.
Ответить | Правка | Наверх | Cообщить модератору

	103. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Ordu (ok), 10-Июл-20, 17:03
	> считаю что код в ядре не должен использовать каких-то встроенных в язык рантайм библиотек. Ок, в этом есть определённый смысл. > Я против Rust в ядре Но при чём здесь раст?
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+4 +/–
	Сообщение от анонн (ok), 10-Июл-20, 17:24
	> Я против Rust в ядре, так как считаю что код в ядре не должен использовать каких-то встроенных в язык рантайм библиотек. Им не место в ядре. Очень, очень квалифицированное мнение! Держите нас и далее в курсе ваших расчетов! https://prev.rust-lang.org/en-US/faq.html = Does Rust have a runtime? Not in the typical sense used by languages such as Java, but parts of the Rust standard library can be considered a “runtime”, providing a heap, backtraces, unwinding, and stack guards. There is a small amount of initialization code that runs before the user’s main function. The Rust standard library additionally links to the C standard library, which does similar runtime initialization. Rust code can be compiled without the standard library, in which case the runtime is roughly equivalent to C’s. =
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	110. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от proninyaroslav (ok), 10-Июл-20, 17:26
	> не должен использовать каких-то встроенных в язык рантайм библиотек А про no_std не слышали?
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	116. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от VladSh (?), 10-Июл-20, 18:55
	> Я против Rust в ядре... Опа, а ребята из новости об этом не в курсе!
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

97. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
Сообщение от Аноним (96), 10-Июл-20, 16:20
Сначала добавят в ядро раст, через год С++, потом джаву, потом питон, и как вишенку на торте добавят джаваскрипт. Вот до чего это доведёт.
Ответить | Правка | Наверх | Cообщить модератору

	150. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (139), 10-Июл-20, 21:41
	C++ ладно, это хороший языке, но каким тут боком языки без zero cost abstraction?
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Анонолекс (?), 11-Июл-20, 10:15
	Так гугл джаваскрипт итак пытается воткнуть во всё, куда дотянется...
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	233. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Онаним (?), 11-Июл-20, 14:09
	Чессгря есть мысль что впилить duktape в ядро будет легче, чем хруст. И дешевле - собирается всё тем же GCC. Но зачем? :)
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

100. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
Сообщение от Аноним (99), 10-Июл-20, 16:43
Раст - небезопасный, сложный ни одной проблемы с++ он не решил. Тогда какой в нем смысл?
Ответить | Правка | Наверх | Cообщить модератору

	151. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (139), 10-Июл-20, 21:43
	На порядок безопаснее UB/UB++ И многие проблемы C++ решил Складывается ощущение, что вы вообще о расте на заборе что-то краем глаза читали
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от anonymous yet another (?), 11-Июл-20, 09:10
	> И многие проблемы C++ решил Тут, между прочим, очередь из решателей всех проблем C++. Вставайте, но передайте, чтобы больше не занимали.
	Ответить | Правка | Наверх | Cообщить модератору

	210. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (210), 11-Июл-20, 10:30
	То-то я смотрю везде где он есть он используется только с модулями unsafe.
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

111. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
Сообщение от anonymous yet another (?), 10-Июл-20, 18:22
Что-то подозрительно много шумихи вокруг этого чуда. Покажите компактный POC, можно было бы посмотреть. А так: давайте всем миром вложимся в немаленькую архитектуру, а когда окажется что она ну очень немаленькая, накладывает тучу ограничений, контролируется толстым игроком и завязана на его инфраструктуру, будет аргумент "нельзя же, чтобы такие усилия пропали, надо принимать". А там демократические выборы, ущемлённые права или "имеют значение" подтянут. Кёрниган с Ричи должны встать на колени и покаятся за сорок лет угнетения альтернативных языков в ядре.
Ответить | Правка | Наверх | Cообщить модератору

	114. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (114), 10-Июл-20, 18:43
	секта разрастается, пока ещё не поют на площадят, но уже скоро, ещё будут ходить по квартирам.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Анонолекс (?), 11-Июл-20, 10:18
	Свидетели ржавчины? P.S. Как представил таких в костюмах ржавых грибов, так сразу захотелось взять и уе... ну вы поняли... :-)
	Ответить | Правка | Наверх | Cообщить модератору

113. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
Сообщение от Аноним (113), 10-Июл-20, 18:30
Visual Studio в ядро добавьте пожалкуйста или хотя бы Visual Studio Code, IDEA и Qt Designer. А то я такой безрукий и без этих полезных вещей в ядре не могу apt install написать.
Ответить | Правка | Наверх | Cообщить модератору

	152. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (139), 10-Июл-20, 21:44
	При чем тут добавление поддержки хорошего языка?
	Ответить | Правка | Наверх | Cообщить модератору

115. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
Сообщение от Иваня (?), 10-Июл-20, 18:53
Я хочу писать на Golang. Добавьте плиз в ядро Linux средств для разработки на языке Golang!
Ответить | Правка | Наверх | Cообщить модератору

	153. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от Аноним (139), 10-Июл-20, 21:44
	У него ж сборщик мусора
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от leap42 (ok), 11-Июл-20, 05:36
	> У него ж сборщик мусора и? да, кое-где STW даже длинной <=0,1мс - непозволительная роскошь, но кое-где норм. я уже молчу о том, что выключать сборщик и запускать его вручную или вообще юзать malloc/free в Go можно и это поддерживается
	Ответить | Правка | Наверх | Cообщить модератору

	263. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (-), 12-Июл-20, 00:44
	Что "и"? Ты реально не понимаешь? Если не понимаешь - в ядро не смей соваться!
	Ответить | Правка | Наверх | Cообщить модератору

	269. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от leap42 (ok), 12-Июл-20, 11:47
	> Что "и"? Ты реально не понимаешь? Если не понимаешь - в ядро > не смей соваться! ну раз аноним запретил, то не буду xD (на Go если что уже есть драйвера, хоть и не для Linux, чудик)
	Ответить | Правка | Наверх | Cообщить модератору

	289. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (288), 12-Июл-20, 20:22
	И на javascript тоже драйвера писали и что?:))) Оно надо в ядре?:) (не суйте go...) И задержки не 0.1, а такие приличные в 1с при этом все приложение будет ожидать лишь очистки..
	Ответить | Правка | Наверх | Cообщить модератору

	294. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от leap42 (ok), 13-Июл-20, 04:29
	> И на javascript тоже драйвера писали и что?:))) Оно надо в ядре?:) (не суйте go...) это for fun, а драйвера на Go есть в промышленной (хоть и неготовой пока) Фуксии > И задержки не 0.1, а такие приличные в 1с при этом все приложение будет ожидать лишь очистки.. лоооооооооооол! ох уж эти мамкины эксперты! в общем случае задержка STW в Go меньше 0,1 мс (это как секунда, только нет, надеюсь, хоть это ты осилишь понять, друг анон?). статей с исследованием задержек полно (только ищи про новые версии). так вот, куча железа работает со значительно большей задержкой, поэтому никакой боли от GC не будет.
	Ответить | Правка | Наверх | Cообщить модератору

117. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+4 +/–
Сообщение от Ivan_83 (ok), 10-Июл-20, 19:03
Большая ошибка. Одно ядро - один язык, и чем проще язык - тем понятнее он остальным. Поэтому таже плюсы - это уже плохо. А раст - вообще катастрофа.
Ответить | Правка | Наверх | Cообщить модератору

	122. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Онаним (?), 10-Июл-20, 19:42
	Да ладно вам. Ну будет полтора модуля на этом извращении, кому убудет-то. Главное, чтобы интерфейс был минималистичным и сильно глубоко в плане правок не лез.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Ivan_83 (ok), 10-Июл-20, 21:35
	Смысл в том, что теперь для правок ошибок нужно будет знать два языка. Для сборки системы нужны будут два компилятора.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–3 +/–
	Сообщение от Онаним (?), 10-Июл-20, 21:48
	Зачем? Просто снимаются опции ядра для этого хлама в базовой поставке, и всё. Кому надо - пересобирают со своим хрустом сами.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Ivan_83 (ok), 11-Июл-20, 00:15
	Затем что долбоящеров с хрустом будет всё больше и больше, в конечном итоге он начнёт требоватся не только для сборки драйверов от маргиналов с их малонужным барахлом но и для того что реально массово используется.
	Ответить | Правка | Наверх | Cообщить модератору

	230. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Онаним (?), 11-Июл-20, 13:57
	Если так случится, значит оно действительно полезное, и заслуживает места быть. Но я скорее предполагаю путь staging -> small team support -> no support -> obsolete -> extinct.
	Ответить | Правка | Наверх | Cообщить модератору

	318. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (234), 15-Июл-20, 11:01
	С каких пор дополнительный слой илитности опеннетчикам стал мешать? Сложность это хорошо же, вебмакаки не пройдут.
	Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

119. Скрыто модератором	–1 +/–
Сообщение от Аноним (119), 10-Июл-20, 19:32
Судя по обилию комментариев, сектанты раста перешли из любительской лиги троллинга в профессиональную. Коллеги, делайте обратную хуцпу, смело вносите абсурдные предложения по улучшению раста на обсуждение.
Ответить | Правка | Наверх | Cообщить модератору

	161. Скрыто модератором	–1 +/–
	Сообщение от Аноним (139), 10-Июл-20, 21:50
	Тут скорее только неадекватные сектанты сишечки
	Ответить | Правка | Наверх | Cообщить модератору

121. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
Сообщение от Аноним (121), 10-Июл-20, 19:42
rust-sources грядет. Это чтобы ядрышко собрать надо будет не gcc, а clang, llvm, rust и это полдня целых минимум.Calculate Linux по-моему обретает особый смысл и очарование.
Ответить | Правка | Наверх | Cообщить модератору

	160. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Онаним (?), 10-Июл-20, 21:50
	Да ладно вам - ну хотят трахаться, пусть трахаются - если растоводы возьмутся это в ядре поддерживать, why not? Но они вряд ли возьмутся, там не тот уровень.
	Ответить | Правка | Наверх | Cообщить модератору

	298. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от anonymous yet another (?), 13-Июл-20, 10:51
	Я полагаю, здесь многоходовка с целью подмять под себя ядро. Сейчас растоборцев задействовали.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Онаним (?), 10-Июл-20, 21:51
	(имеется в виду, что по умолчанию это "N", желающие - велком "Y", и тогда уже в пререквизитах весь тулкит по правилам)
	Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

126. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
Сообщение от Аноним (126), 10-Июл-20, 19:48
Сколько ж дней оно с ним собираться будет? С временем компиляции у Раста всё плохо.
Ответить | Правка | Наверх | Cообщить модератору

	154. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (139), 10-Июл-20, 21:45
	Будто у C/C++ лучше
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Ordu (ok), 10-Июл-20, 23:59
	У C лучше. У C++, мне кажется, тоже лучше, хотя не писал на нём очень давно, а на чужом коде сложно оценивать тормознутость компилятора.
	Ответить | Правка | Наверх | Cообщить модератору

128. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
Сообщение от Аноним (121), 10-Июл-20, 19:54
Не зря этот хрен себе 32 ядра взял.(
Ответить | Правка | Наверх | Cообщить модератору

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

	156. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от Аноним (139), 10-Июл-20, 21:46
	> дегродов до написания драйверов нельзя допускать А при чем тут Раст?
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (135), 10-Июл-20, 22:28
	>> дегродов до написания драйверов нельзя допускать > А при чем тут Раст? А при том, что главное позиционирование его и причина внедрения это почва для расцвета дегродов, профи системные инженеры и на Сях нормально прогают, потому что основательно знают с чем имеют дело, и как только дозволительно становится набирать всяких олухов, которые могут себе позволить "не делать ошибок", потому что система им не даёт "прострелить ногу", то сразу же начинается ещё большее деграданство. По подобной же причине всякие скриптомакаки гомнокодят, потому что не надо можг напрягать. А в итоге мы получаем приложения на электроне, JS везде и всюду, даже в DE, и лютый жор ресурсов, а глюков не то что бы убавилось, их ещё в полку прибыло. Современных программистов вообще надо сажать за машины с 1 Гб ОЗУ и процом бюджетнопомоешным, чтобы за лимиты не вылазили. А по минусам к этому коменту мы узнаем сколько в тему забежало скриптомакак со своим суперважным протестом про инновации, развитие, на сях нельзя писать, чтобы не было решета, и прочее ко-ко-ко
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от anonymous (??), 11-Июл-20, 00:01
	> потому что не надо можг напрягать. Вообще у Rust порог вхождения намного выше, чем у Си. Он накладывает на тебя кучу ограничений, компенсируя экспрессивной системой типов и некоторыми другими zero-overhead feature-сами.
	Ответить | Правка | Наверх | Cообщить модератору

	229. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Аноним (229), 11-Июл-20, 13:12
	Да-да, надо всё на ассемблере писать.
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

137. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
Сообщение от Аноним (229), 10-Июл-20, 20:49
Читаю эти хейт-спичи (сейчас это так называется?) по поводу раста и вспоминаю бессмертное https://ru.wikipedia.org/wiki/Настоящие_программисты_не_используют_Паскаль Но там хоть в шутку это всё было.
Ответить | Правка | Наверх | Cообщить модератору

	141. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (114), 10-Июл-20, 21:24
	в принципе уместное сранение, но даже паскаль не был настолько ущербным как руст, а ада тем более. руст - это просто набор хаков для ллвм который выдаётся за "безопасность".
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (139), 10-Июл-20, 21:49
	C/C++ от ущербности Раста менее ущербными быть не перестанут.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (114), 10-Июл-20, 22:04
	руст от ущербности с++ менее ущербным тоже не станет. ну можешь на аде пописать если хочешь, тебе же никто не запрещает. там всё "очень безопасно" (на самом деле нет) и "проверено временем" (проверка провалилась), генерирует нативный код - вообще огонь. всё как ты хочешь, тебе совсем не обязательно изобретать очередной велосипед, его изобрели 40 лет назад, просто тебе забыли сказать об этом.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
	Сообщение от Аноним (139), 10-Июл-20, 21:48
	Просто пишущие на C/C++ боятся, что их знания потеряют цену, только и всего Этого не случится, конечно, даже если сейчас всем внезапно придется перейти на Раст, но некоторые слишком консервативны для принятия нового
	Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

	163. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Онаним (?), 10-Июл-20, 21:52
	К счастью, "всем внезапно придётся" невозможно - адекватных слишком много :)
	Ответить | Правка | Наверх | Cообщить модератору

	222. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от анон (?), 11-Июл-20, 12:14
	Все же резко перешли на кок. Хотя не я помню, чтобы код не принимали лишь потому, что человек *** или ***
	Ответить | Правка | Наверх | Cообщить модератору

	287. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Онаним (?), 12-Июл-20, 19:03
	На биг блэк кок.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (229), 10-Июл-20, 22:09
	Вот именно. Столько лет жили в своём уютном мирке, а тут внезапно появился годный язык общего назначения. НИБАМБИТ
	Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

	221. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от анон (?), 11-Июл-20, 12:07
	Мне то же самое говорили и про го.
	Ответить | Правка | Наверх | Cообщить модератору

	282. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Anonn (?), 12-Июл-20, 16:44
	Где появился? Ссылку, срочно!
	Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

	293. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (293), 12-Июл-20, 23:26
	где-то в мурзилке
	Ответить | Правка | Наверх | Cообщить модератору

155. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
Сообщение от user90 (?), 10-Июл-20, 21:46
> занимающийся в Google обеспечением поддержки сборки Что, никому не смешно? Какой-то х. с гор.. то есть из гуглеля! что-то там сказал.
Ответить | Правка | Наверх | Cообщить модератору

170. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
Сообщение от Страшный аноним (?), 10-Июл-20, 22:54
Rust пока себя особо не проявил, хотя языку уже много годков. Он уродлив и нечитабелен. Возможно, через определенной время он прекратит своё существование, дав жизнь, после переосмысления чему-то более юзабельному и красивому. Так зачем похабить ядро Linux? Я вообще считаю, что не C небезопасный, а что слишком много идиотов на нем программируют, не понимающих все плюсы и минусы языка.
Ответить | Правка | Наверх | Cообщить модератору

	175. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+4 +/–
	Сообщение от Аноним (175), 11-Июл-20, 00:24
	Но ведь полезно же иметь язык, предотвращающий как можно больше ошибок?
	Ответить | Правка | Наверх | Cообщить модератору

	268. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Xasd5 (?), 12-Июл-20, 11:18
	в ядре?
	Ответить | Правка | Наверх | Cообщить модератору

	292. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (293), 12-Июл-20, 23:22
	и как хруст может предотвратить ошибки работы с железом?
	Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

	299. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от anonymous yet another (?), 13-Июл-20, 10:56
	Вы историю с языками т.н. 4-го поколения (4th generation languages) не знаете?
	Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

179. Скрыто модератором	–1 +/–
Сообщение от Аноним (179), 11-Июл-20, 00:54
Прочитав комментарии тут, я задался простым вопросом: "Вы вообще программируете?". "Эта нинада" "руст нинужан" - такое ощущение, что отряды Путинa клоунский колпак не снимали и отправились на opennet. Любой ЯП достоин проявления себя и раст не исключение, только время и практика покажет его практичность. И да, если вы так много кодите на плюсах и Си, хоть оставляйте свои шедевры (собственноручно написанные) с проектами, мы заценим, как вы эффективно используете С/С++.
Ответить | Правка | Наверх | Cообщить модератору

201. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–3 +/–
Сообщение от Да (?), 11-Июл-20, 08:11
Если Rust сможет избавить мир от вечного бетатеста программ написанных индусами на Си - ++, то я за.
Ответить | Правка | Наверх | Cообщить модератору

204. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
Сообщение от asdasd (?), 11-Июл-20, 09:17
> занимающийся в Google Не, не, не, ни кому не в обиду, но когда крупные компании занимаются подобными вопросами, это тушите свет.
Ответить | Правка | Наверх | Cообщить модератору

205. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
Сообщение от asdasd (?), 11-Июл-20, 09:19
> поддержку GCC атрибутов inline, cold, alias, used и section А ничего, что inline появился аж в C99?
Ответить | Правка | Наверх | Cообщить модератору

237. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
Сообщение от Аноним (237), 11-Июл-20, 16:38
Каждый раз, когда читаю комментарии под новой статьей о Rust на opennet, в голове невольно вертится пословица "Собака лает, а караван идёт". Может уже бы сели спокойно на выходных, да изучили бы язык, помедитировали над его концепциями? Нет, конечно, это всегда морально проще с пеной у налитыми кровью глазами грудью защищать статус-кво, но чтобы двигаться вперед, увы, всегда нужно выходить из зоны комфорта и пересматривать традиции.
Ответить | Правка | Наверх | Cообщить модератору

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

	273. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–2 +/–
	Сообщение от Сишник (?), 12-Июл-20, 13:18
	Собрал хеллоуворд, оказалось 5мб весит, ну его нафиг. Те, кто такое сделал, хорошему не научат.
	Ответить | Правка | К родителю #237 | Наверх | Cообщить модератору

	276. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (-), 12-Июл-20, 15:05
	> Собрал хеллоуворд, оказалось 5мб весит, ну его нафиг. Те, кто такое сделал,  хорошему не научат. cat hello.rs &&  rustc -O  hello.rs && wc -c ./hello fn main() {   println!("Hello World!"); }   306552 ./hello % rustc -O  hello.rs -C link-args=-s && wc -c ./hello   232208 ./hello % rustc -O  hello.rs -C prefer-dynamic -C link-args=-s && wc -c ./hello            14856 ./hello Криворук и ламероват - это злобный раст все виноват!
	Ответить | Правка | Наверх | Cообщить модератору

	280. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	–1 +/–
	Сообщение от Сишник (?), 12-Июл-20, 16:23
	> Криворук и ламероват - это злобный раст все виноват! В оттенках коричневого разбираться нужным не считаю. Сделал как у растовиков рекомендуется пару лет назад, возможно за это время осилили уменьшить размер бинаря, но более нужным его это не делает.
	Ответить | Правка | Наверх | Cообщить модератору

	283. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Аноним (283), 12-Июл-20, 16:51
	>> Криворук и ламероват - это злобный раст все виноват! > В оттенках коричневого разбираться нужным не считаю. Т.е. что такое debug/release компиляция, флаги оптимизации, что такое дебаг-инфа, статическая и динамическая линковки, strip - и как оно влияет на размер бинаря, ламерье не в курсе, не разбирается и разбираться не хочет? Впрочем, на то оно и ламерье, пусть и со звучным именем. > Сделал как у растовиков рекомендуется пару лет назад, возможно за это время осилили уменьшить размер бинаря, но более нужным его это не делает. > возможно за это время осилили уменьшить размер бинаря, но более нужным его это не делает. Да-да, уже лет 8 как, причем тайком от местных знатоков-экспертов.
	Ответить | Правка | Наверх | Cообщить модератору

	285. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
	Сообщение от Сишник (?), 12-Июл-20, 17:40
	Чего злой такой? Мне нафиг не упало задрачивать ржавый тулсет для получения приемлимых результатов. У меня и так всё хорошо, а вот у тебя похоже что-то не задалось, раз кидаешься на посторонних людей🙂
	Ответить | Правка | Наверх | Cообщить модератору

	313. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Ordu (ok), 14-Июл-20, 20:25
	> Мне нафиг не упало задрачивать ржавый тулсет для получения приемлимых результатов. Да не задрачивай, ктож тебя заставляет? Но и ныть тогда не надо, что у тебя хеллоу-ворлд не получается приемлимо скомпилировать.
	Ответить | Правка | Наверх | Cообщить модератору

	286. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Онаним (?), 12-Июл-20, 17:47
	Не хватает ldd к этому выводу.
	Ответить | Правка | К родителю #276 | Наверх | Cообщить модератору

255. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
Сообщение от via (??), 11-Июл-20, 20:21
А кто им мешает-то, пусть делают, что хотят, только не под флагом kernel.org.
Ответить | Правка | Наверх | Cообщить модератору

	291. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+2 +/–
	Сообщение от Аноним (293), 12-Июл-20, 22:19
	они по другому не могут... они только под чужими флагами гадить умеют.
	Ответить | Правка | Наверх | Cообщить модератору

262. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
Сообщение от Аноним (-), 12-Июл-20, 00:42
>63), 14:12, 10/07/2020 Скрыто модератором [﹢﹢﹢] [ · · · ] >>Исследователи из Китайского университета в Гонконге развивают проект для >обеспечения мирового доминирования Китайской Народной Республики Сразу видим две вещи: 1) аноним реально в теме - там так и есть 2) модыратор реально куплен ККП
Ответить | Правка | Наверх | Cообщить модератору

265. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
Сообщение от Аноним (-), 12-Июл-20, 00:49
нет, он не куплен, всё гораздо печальнее... Он последователь этой идеологии, при чём промыты с раннего детства.
Ответить | Правка | Наверх | Cообщить модератору

275. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
Сообщение от Anonn (?), 12-Июл-20, 14:01
Справедливости ради, ядро написано не на Си. Большинство из следующих используемых в ядре конструкций отсутствуют в языке Си Вывод типов - typeof(x) Ассемблерные вставки - asm volatile("pxor %xmm5,%xmm5"); Диапазоны в свитче - case 1 ... 7: Массивы нулевой длины - some_variable_len data[0]; Адрес вызывающего - ptr = __builtin_return_address(0) Определение константности выражения - if __builtin_constant_p(c) Различные атрибуты функций - __attribute__((always_inline)) Подставляемые функции - inline void fun() Имя текущей функции - my_func_name = __func__ Инструкции-выражения - ({ int a = b + 1; a; }) Переменное число параметров в макросах - __VA_ARGS__ Арифметика с указателями на void - ++void_ptr Неконстантные инициализаторы - int arr[2] = { x, y }
Ответить | Правка | Наверх | Cообщить модератору

	277. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (-), 12-Июл-20, 15:43
	Спорно. И ты этим хочешь оправдать использование Раста? Глупенький.
	Ответить | Правка | Наверх | Cообщить модератору

	281. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Anonn (?), 12-Июл-20, 16:41
	Что тут спорного? Это объективный факт. Ядро написано не на Си, а на Си-с-расширениями. Компилятор, в котором нет этих расширений, такой код не соберет. Парсер, который написан в соответствии со стандартом, такой код может не распарсить. Человек, который учил Си по учебнику, конструкции не поймет, или подумает что это ошибка. До Раста мне дела нет, просто указываю на очевидную логическую неточность.
	Ответить | Правка | Наверх | Cообщить модератору

	284. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (-), 12-Июл-20, 17:32
	Так ядро же GNU-тое, все это знают. GCC - официальный компилятор, все это знают. Вот только ты решил подыграть растаманам. Расту нет места в ядре. Для экосистемы GNU/Linux язык Раст - это чужеродное образование.
	Ответить | Правка | Наверх | Cообщить модератору

279. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+1 +/–
Сообщение от Аноним (278), 12-Июл-20, 16:14
>> Предполагается, что подобный подход может оказаться востребован производителями оборудования, разрабатывающими проприетарные драйверы на скорую руку без проведения должного аудита. Надо ещё больше говнокода! А то текущее количество миллионов строк уже никого не впечатляет.
Ответить | Правка | Наверх | Cообщить модератору

	290. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Аноним (293), 12-Июл-20, 22:15
	дрова на скорую руку... проприетартные... жесть.
	Ответить | Правка | Наверх | Cообщить модератору

	310. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Анонолекс (?), 14-Июл-20, 20:02
	Так сжечь нах под корень... и в село делов...
	Ответить | Правка | Наверх | Cообщить модератору

	311. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
	Сообщение от Анонолекс (?), 14-Июл-20, 20:10
	Говно в говно! А то поразвели тут, понимаешь...
	Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

302. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
Сообщение от Аноним (302), 13-Июл-20, 18:06
ТО ли Линус постарел, то ли гики помолодели ...
Ответить | Правка | Наверх | Cообщить модератору

309. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
Сообщение от Анонолекс (?), 14-Июл-20, 19:48
Ты тут два раза подумали и я два раза сказал... Да в ж0пу ваш раст, в ж0пу...
Ответить | Правка | Наверх | Cообщить модератору

312. "Предложение по обсуждению вопроса добавления в ядро Linux ср..."	+/–
Сообщение от Анонолекс (?), 14-Июл-20, 20:12
И надо больше жечь людей. Криворуких программеров ваще пачками...
Ответить | Правка | Наверх | Cообщить модератору

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

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