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

"Lunatik - инструментарий для создания в ядре Linux обработчиков на языке Lua"	+/–
Сообщение от opennews (?), 22-Апр-24, 09:22
Проект Lunatik развивает инструментарий, позволяющий использовать язык Lua для расширения функциональности ядра Linux и быстрого написания скриптов-обработчиков, работающих на уровне ядра. Для выполнения кода задействован интерпретатор Lua, модифицированный для работы на уровне ядра. Код проекта написан на языке Си и распространяется под лицензией MIT... Подробнее: https://www.opennet.me/opennews/art.shtml?num=61040
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	–20 +/–
Сообщение от M (?), 22-Апр-24, 09:22
lua - непригодный язык. Лучше бы WASM-интерпретатор или jit в ядро засунули.
Ответить | Правка | Наверх | Cообщить модератору

	2. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+12 +/–
	Сообщение от Аноним (2), 22-Апр-24, 09:28
	> lua - непригодный язык. Лучше бы WASM-интерпретатор или jit в ядро засунули. Нормальный lua, просто не место в ядре всякой шляпе, ониб ещё JS туда затолкали!
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Аноним (155), 23-Апр-24, 01:48
	Ты не поверишь... https://github.com/mildsunrise/node_bpf
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 26-Апр-24, 21:30
	> Ты не поверишь... > https://github.com/mildsunrise/node_bpf - Новый продукт - Node WTF! - WPF?! - BPF!
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от YetAnotherOnanym (ok), 23-Апр-24, 21:51
	Извини, но разница между счётным множеством и континуумом - принципиальна и неустранима, поэтому язык, в котором изначально отсутствует целый тип (который позже примотали изолентой) не может считаться нормальным.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	193. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от n00by (ok), 24-Апр-24, 09:52
	В нормальных алгорифмах Маркова нет целого типа. Зато возможна длинная арифметика, которую к целым типам прикручивают изолентой.
	Ответить | Правка | Наверх | Cообщить модератору

	6. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+2 +/–
	Сообщение от Аноним (6), 22-Апр-24, 09:36
	Зато безопасный. Неизвестно что в твой васм запихнут, а Джит это дыра в безопасности бай дизайн.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	77. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от scriptkiddis (?), 22-Апр-24, 12:29
	Ну да ну да, а ebpf это нормально это можно.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 23-Апр-24, 11:34
	> Ну да ну да, а ebpf это нормально это можно. Ну так и сделай транслятор WASM -> EBPF, и хрен кто такой ход конем оспорит, прикинь? :))
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+6 +/–
	Сообщение от EULA (?), 22-Апр-24, 09:59
	Java, Java должна быть в ядре. И Qml
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	126. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (126), 22-Апр-24, 17:46
	Помню в 90х даже были пк-приставки к телеку-монитору на джаве И так то слышал что после разогрева джава в полтора раза медленнее нативного кода Думаю что оптимизаций там по более, чем в луа
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Я (??), 22-Апр-24, 21:51
	иногда даже быстрее, но памяти в любом случае больше кушает.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+2 +/–
	Сообщение от Ivan_83 (ok), 23-Апр-24, 00:13
	Это не так работает :) В том смысле что эволюционно так получилось что есть языки удобные для описания бизнесс логики и  есть языки для написания кода который молотит данные. Универсального языка для всего сразу как то не получается, в основном потому что ультимативная производительность предполагает ручное управление ресурсами и почти отсутствие абстракций над железом. В конце 90х-начале 2000х такое комбо было: Visual Basic (со встроенным автоформатером кода) + Visual C++. Первый был прекрасен чтобы по быстрому накидать простой гуй, второй был удобен чтобы по быстрому сделать dll с функциями для тяжёлых рассчётов. И это всё вместе относительно легко линковалось. Был ещё вариант всё в одном - дельфи, но там и скорость была чуть ниже чем в С++ и прогать было по сложнее чем в вижал бейсике. Сейчас такой прямо полноценной замены этой связки я не вижу. Вроде есть вала и питон, но питон ужасный, а валу я толком не пробовал. Есть луа, но с гуем там официально никак, а либы всякие я не искал. Да и в целом, я бы сказал что QT/GTK так себе тулкиты, если сравнивать их с виндовым, который по сути за 30+ сохранил совместимость, в отличии от линуксовых которые каждые лет 5 всё ломают и в принципе сложнее в использовании чем вендовый.
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	158. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	–1 +/–
	Сообщение от Аноним (158), 23-Апр-24, 04:03
	Ты устарел, Иван 83. Вроде версия большая, а реальности не понимаешь. Язык высокого уровня - питон, а низкого - tensorflow.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 23-Апр-24, 13:53
	> Ты устарел, Иван 83. Вроде версия большая, а реальности не понимаешь. > Язык высокого уровня - питон, а низкого - tensorflow. И как, хорошо на этом ядерные модули писать получается? Примеров дадите?! :)
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 23-Апр-24, 11:37
	> Универсального языка для всего сразу как то не получается, в основном потому что > ультимативная производительность предполагает ручное управление ресурсами и почти > отсутствие абстракций над железом. Ну вот хруст на горизонте нарисовался. Может в высокоуровневые конструкции, но при острой нужде позволяет и околосишные фокусы откалывать. И без окаменевших сишных глупостей типа "угадай какого вообще размера int и корректно ли на этой платформе вообще работает тот код?!"
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	187. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Ivan_83 (ok), 23-Апр-24, 17:02
	Гниль имеет слишком сложный синтаксис, и расвесистую систему зависимостей как у нодыжс, тяжёлый космпелятор не везде работающий. Это всё огромные минусы, а какого размера int мало кого интересует.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 26-Апр-24, 21:54
	> Гниль имеет слишком сложный синтаксис, и расвесистую систему зависимостей как у нодыжс, Ну вот как бы да. Но все остальные оказались еще хуже - а дожать сишку до кондиции "en masse" все же душновато. Комитет придурков никак прожать на нормальные изменения не получается. А прогать как будто на дворе 1989 что-то уже не хочется, ибо четверть века прошло. И за нее можно уже и сделать выводы из старых грабель. Ну и вот чего делать? Вулнов многовато, проблемы сборки и портабельности тоже поднадоели порядком. Я не хочу иметь дело с "int" неопределенного размера и всем бардаком который оттуда вытекает - вечно. > тяжёлый космпелятор не везде работающий. > Это всё огромные минусы, а какого размера int мало кого интересует. Пока это не выльется в крахи софта, сбои фирмвар, факапы сборки, дикие баги и вулны на ровном месте и тому подобное. Извините, но - надоело. С этим пора что-то сделать. По хорошему, или уж как получится. Слушать сказки про белого бычка все-же надоело.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (196), 26-Апр-24, 09:23
	Ок, а какие-то реальные достоинства будут? ООП там?
	Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

	27. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+9 +/–
	Сообщение от Ivan_83 (ok), 22-Апр-24, 10:19
	LUA очень даже годный. Там порядка 10к строк всего на С, без всяких лишних зависимостей.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	153. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (153), 23-Апр-24, 01:13
	Дело не в реализации, а в самом языке. Массивы с единицы и производительность улитки на списках. Разве что не пользоваться структурами Lua
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+2 +/–
	Сообщение от Ivan_83 (ok), 23-Апр-24, 04:22
	В Visual Basic были массивы с 1 по дефолту, и ничего :) От LUA не требуется большой производительности. Один из канонических примеров её использования это парсинг конфига. Когда конфиг по сути превращается в lua файл где переменным присваются значения, а бонусом можно накидать туда логику, типа если есть какой то файл то меняем дефолты, или если чего то там в /proc то пишем другие значения и тп. У меня дома prosody полностью (почти) написанный на луа, и проц он не жрёт. Сейчас я сел запилить свою софтину, там куча сишных биндингов для LUA будет, и LUA только дёргать их будет и перекладывать аргументы, немного бизнес логики - сомневаюсь что оно будет сколь нибудь ощутимо жрать проц. Пока я пробовал таймер каждую 1мс с принтом гонять и была нагрузка в районе 1-2% на одном ядре райзена. По моим прикидкам у меня эвенты будут реже случатся с одной стороны, с другой воркеров их разгребать будет больше одного.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (163), 23-Апр-24, 09:51
	>В Visual Basic были массивы с 1 по дефолту, и ... где теперь Visual Basic? Бывают языки, на которых удобно программировать. А бывают языки, вроде pascalя, visual basicа, lua, matlab/octave/julia и R, которые вставляют палки в колёса даже в самых элементарных вещах, вроде синтаксиса, индексации или станд. библиотеки, напр. в некоторых языках даже функции для парсинга целого числа из строки с этом целым числом в hex-виде в переменную целочисленного типа до недавнего времени не было, нужно было сторонний пакет подгружать. Зачем авторы языков так делают? В большей мере - из-за тараканов в головах. Такие языки обычно выкидываются целиком заменяются более удобными, напр. когда выяснилось, что для парсинга числа в hex нужно танцевать вприсядку, я просто выкинул тот язык целиком ффтопку и перешёл на питон, и не жалею.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от n00by (ok), 23-Апр-24, 15:49
	VB умер, поскольку MS его заменила на C#. И какие там проблемы перевести строковое представление шестнадцатеричного числа в целое, кроме неумения написать тривиальный цикл? На VBS наверняка и сейчас что-то пишут, просто потому что он есть в Windows из коробки и может больше чем JS в том же WSH.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Ivan_83 (ok), 23-Апр-24, 17:10
	VBA остался в оффисе неизменным, VBS это немного другое всё же.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от n00by (ok), 24-Апр-24, 10:06
	VBA это не VB, насколько понимаю. VBS действительно другое - по сути встроенный в Windows некий аналог bash. Правда, Гейтс немного просчитался, посчитав пользователей достаточно умными.
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+2 +/–
	Сообщение от Ivan_83 (ok), 23-Апр-24, 17:09
	VB закопали в пользу C# и Vb.net, не надо думать что VB умер сам из за каких то деффектов. Первой ласточкой было то что VB6 имел не встроенную справку а она какая то отдельная была, надо было найти и скачать, а особых профитов по сравнению с VB5 там не было. Что касается парсинга чисел - это ваше мнение. Для меня и в С такого парсинга нет, я свой наколхозил и забыл про такую проблему уже 20 лет как. Питон тоже обречён. Прототипировать в нём легко но эксплуатировать такое нельзя, оно просто не поддерживаемое. Тот же хом асистант почти не ставят отдельно, только в докере или сразу образ ОС, потому что это поделие работает только на машинах разрабов.
	Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

	195. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (195), 25-Апр-24, 01:06
	>Для меня и в С такого парсинга нет, я свой наколхозил strtol, C89.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от randomize (?), 26-Апр-24, 10:02
	> Питон тоже обречён. Прототипировать в нём легко но эксплуатировать такое нельзя, оно просто не поддерживаемое. А поподробнее?
	Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

	190. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (190), 23-Апр-24, 20:56
	> Массивы с единицы Как будто что-то плохое. > производительность улитки на списках. «Чи-гоо б…?!?» © На всякий, в Lua нет списков. Есть таблицы. И они ОЧЕНЬ шустрые. Особенно когда это не key-value, а  массив. Так что либо давай поподробнее (с чем сравнивать и что вообще сказать хотел) и с пруфами, либо балабол.
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	38. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+2 +/–
	Сообщение от Аноним (38), 22-Апр-24, 10:35
	>jit в ядро засунули Уже засунули. eBPF называется.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

	72. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	–1 +/–
	Сообщение от Бывалый Смузихлёб (ok), 22-Апр-24, 11:47
	многие лютейшие дыры начинаются именно с JIT Луа и сама по себе годится разве что для игровых скриптов, а уж с джитом да в линухоядре. Зачем так париться, проще уж один на всех логин-пароль для рута гвоздями прибить
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	82. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+3 +/–
	Сообщение от Аноним (82), 22-Апр-24, 12:59
	тебе же в новости написали: для создания кейлоггеров. чтобы битки твои тырить проще было
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+5 +/–
	Сообщение от _kp (ok), 22-Апр-24, 13:20
	Lua отличный язык как внутренний скниптовый движок, и для встраиваемых устройств, не тяжелый, и не совсем примитивный. В тоже время Lua имеет несовместимости, делающие его неудобным для обшего использования. Что же касается интерпритаторов в ядре, а не в системе, это наверное последстия легализации марихуаны, и иных нехороших излишеств. Как пример, где Lua похоронил весь проэкт, это Minetest, вроде бы быстрый движок на с++, что могло пойти не так.. А то что с самими играми, которые как раз на Lua, тормозит не по детски на топовом железе. Да и стабильность Lua смехотворная, именно из за несовместимости версий скриптов, о чем сказано в самом начале.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	113. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Аноним (113), 22-Апр-24, 16:11
	Вообще-то игры на lua в движке Minetest достаточно быстро работают (не все но многие). Я говорю как тот кто сам активно в них играет. В любом случае Lua точно не "похоронил" Minetest. Minetest хоть и не ориентрован на топовое оборудование но в последнее время эта ситуация улучшается.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (196), 26-Апр-24, 09:31
	Чтоб все так жили как Minetest "похоронили". Наверное в настоящий момент это open-source игра с самым большим и активным комьюнити. И про производительность чушь полная, нужно наверное сотню модов навешать чтобы кора дуба стала тормозить.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

8. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+15 +/–
Сообщение от Аноним (8), 22-Апр-24, 09:38
> после нажатия "↑ ↑ ↓ ↓ ← → ← → LCTRL LALT" ядро Сделает фаталити
Ответить | Правка | Наверх | Cообщить модератору

	11. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (11), 22-Апр-24, 09:41
	> Сделает фаталити так что это конами код, а не фаталити
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 23-Апр-24, 13:56
	>> после нажатия "↑ ↑ ↓ ↓ ← → ← → LCTRL LALT" ядро > Сделает фаталити А что, как раз - только представь себе что у тебя в самый интересный момент отвалилась клава в системе! Теперь попробуй угадать как ее включить назад без нажатия ресета! :)
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

10. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	–2 +/–
Сообщение от Fracta1L (ok), 22-Апр-24, 09:39
Видимо, с притоком свежих программистов на сишке всё очень плохо.
Ответить | Правка | Наверх | Cообщить модератору

	12. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	–1 +/–
	Сообщение от KroTozeR (ok), 22-Апр-24, 09:44
	Ну, это ж больно, это ж думать надо.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Аноним (20), 22-Апр-24, 10:09
	Как случайно очередное rce в ядро протащить?
	Ответить | Правка | Наверх | Cообщить модератору

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

	28. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Ivan_83 (ok), 22-Апр-24, 10:20
	Вот LUA можем. C+LUA и больше особо ничего не надо. Даже make системы есть на LUA. Так что у нас всё самодостаточно.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от KroTozeR (ok), 22-Апр-24, 10:25
	Можно просто отдать ЯП право управления компилятором и задачу прекомпилятора. Сейчас пока такое умеет только Zig, но это не значит, что им всё ограничится. Там вообще ничего кроме самого ЯП и его окружения не нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Ivan_83 (ok), 22-Апр-24, 10:55
	Не уверен что правильно понял "отдать ЯП право управления компилятором". Помнится quick basic, Visual Basic - вполне себе и ЯП и компилятор были в одном флаконе что называется. У последнего ещё и code style с принудительным автоформатером был, потому даже самые "одарённые" писали так что при чтении кровь из глаз не текла ручьём.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от KroTozeR (ok), 22-Апр-24, 11:31
	Все операции, вызываемые обычно через системы сборки, умещаются в исходник на Zig с применением конструкций языка. В такой ситуации CMake — попросту ненужный бесполезный громоздкий наворот.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от n00by (ok), 22-Апр-24, 11:19
	> Можно просто отдать ЯП право управления компилятором и задачу прекомпилятора. Сейчас пока > такое умеет только Zig В смысле, Nemerle помер?
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	61. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от KroTozeR (ok), 22-Апр-24, 11:28
	А он ещё жив? К тому же, .Net — это же никак не про фундаменталку.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от n00by (ok), 22-Апр-24, 11:39
	Не знаю, жив ли, но появился задолго до Zig. Ну и на .Net вполне написали совершенно безопасную Microsoft Singularity. Потом, правда, отправили в музей и теперь пишут другую безопасную ОС.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (65), 22-Апр-24, 13:45
	Mono в ядро? Зато сколько сразу языков!
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	168. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (168), 23-Апр-24, 12:35
	>> Можно просто отдать ЯП право управления компилятором и задачу прекомпилятора. Сейчас пока >> такое умеет только Zig > В смысле, Nemerle помер? Нельзя убить то что никогда не жило. Эта штука всегда была где-то рядом с singularity, микроядрами и прочими концепт-карами. Много вы концепт каров на улице видели?
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	183. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от n00by (ok), 23-Апр-24, 15:31
	>>> Можно просто отдать ЯП право управления компилятором и задачу прекомпилятора. Сейчас пока >>> такое умеет только Zig >> В смысле, Nemerle помер? > Нельзя убить то что никогда не жило. Эта штука всегда была где-то > рядом с singularity, микроядрами и прочими концепт-карами. Много вы концепт каров > на улице видели? Я не понял, к какому из языков это относится. Разработка языка Nemerle началась в 2003 году в университете Вроцлава (Польша). ... 12 марта 2010 года была выпущена первая бета-версия компилятора языка ... С июня 2012 года команда разработчиков Nemerle стала частью компании JetBrains, которая займётся дальнейшей разработкой и поддержкой языка. ... Выпуск     1.2.547.0 (01.09.2017) Zig Появился в     2015 Выпуск     0.11.0 (4 августа 2023)
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от KroTozeR (ok), 22-Апр-24, 10:31
	Зачем для задач Си применять что-то кроме него, если самого Си хватает с головой? Поделие, которое очень плохо вылизано под такие задачи не должно иметь приоритета только за счёт "новизны". Понятно, что у самого Си есть проблемы, которые в разной степени купируются проектами GoLang, Rust, Zig, Num  и т.п., но когда предлагают замещать Си Python-ом, это уже какой-то испанский стыд...
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	97. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Аноним (126), 22-Апр-24, 14:36
	>почему они не могут осилить ничего кроме сишки А зачем еще что-то кроме сижки? Си это идеальный язык, минималистичный Но с большой силой приходит и большая ответсвенность То что некоторые допускают уязвимости в своих программах, сугубо ответсвенность писарей этих самых программ Ей богу, надоело уже слушать эти все колкости в сторону языка
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	101. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 22-Апр-24, 14:48
	> А зачем еще что-то кроме сижки? Ну, от палки-копалки наши предки отказались, лопата осталась, но добавился еще экскаватор. Не все ж время использовать каменные топоры. > Си это идеальный язык, минималистичный Отвратительный язык. С кучей непродуманных мест сделаных "на отвались", т.е на "нам решать лениво, пусть там компилятор сам разберется". С кодом, который на разных версиях компиляторов выдает разные результаты. С просто ужасными компиляторами, ни один из открытых нереализует язык полностью. > Но с большой силой приходит и большая ответсвенность Иногда с возрастом приходит мудрость, иногда старость приходит сама. За 50 лет адепты так и не смогли не портить память. > То что некоторые допускают уязвимости в своих программах, сугубо ответсвенность писарей этих самых программ > Ей богу, надоело уже слушать эти все колкости в сторону языка Если у тебя в руках инструмент из которого торчат провода и шестерни, где изоляция это что-то из области фантастики, а про защитный кожух никто никогда не слышал - то такой инструмент просто плохой. И его надо выкинуть на помойку.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Аноним (105), 22-Апр-24, 15:11
	> С кучей непродуманных мест сделаных "на отвались", т.е на "нам решать лениво, пусть там компилятор сам разберется". Это ты точно про Си, а не про раст? > С кодом, который на разных версиях компиляторов выдает разные результаты. А язык тут причем? Все вопросы к автору компиляторов, почему md5 финального бинаря отличается > С просто ужасными компиляторами, ни один из открытых нереализует язык полностью. GCC, например, прекрасный оптимизирующий компилятор, генерящий код для почти всех платформ и архитектур > За 50 лет адепты так и не смогли не портить память. Растаманы тоже портят, просто из-под раста этого не видно, см. первую цитату про "лениво решать, пусть компилятор что-то там" > Если у тебя в руках инструмент из которого торчат провода и шестерни, где изоляция это что-то из области фантастики, а про защитный кожух никто никогда не слышал - то такой инструмент просто плохой. Си - это такой... как сказать... высокоуровненый ассемблер что ли. А асме тоже нету никакой защиты (но она может быть на уровне микрокода и/или архитектуры). Тебя не парит, что в asm нет никакой защиты? Ну вот и в Си так же
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (117), 22-Апр-24, 16:50
	> Это ты точно про Си, а не про раст? Конечно. Скажи спасибо комитету за UB и ID. > А язык тут причем? Все вопросы к автору компиляторов, почему md5 финального бинаря отличается Так разрабы компилятора все делали по "стандарту". Ну, т.е. по тому куску ###, которое по традиции называют стандартом. И если там написано - "а мы хз, делайте как хотите", то они делают как хотят. > GCC, например, прекрасный оптимизирующий компилятор, генерящий код для почти всех платформ и архитектур en.cppreference.com/w/c/compiler_support Покажи, пожалуйста, хоть один, который реализует стандарт полностью. Т.е. без "no" и "partial". Вот только не начинай что "это не такая важная штука", "они не обязаны" и тд > Си - это такой... как сказать... высокоуровненый ассемблер что ли. Абсолютно согласен. Вот только сейчас писать на асме больше пары страниц кода уже нет смысла - в 99% случаев компилятор оптимизирует лучше. А оставшийся 1% увидишь в профайлере и перепишешь ручками. А на сишке пишут проекты на миллионы строк кода. И понятно что оно будет как в асме - дыра на дыре.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (154), 23-Апр-24, 01:37
	> Скажи спасибо комитету за UB и ID. Спасибо им, что есть стандарт. У некоторых и такого нету, а потому там любое поведение потенциальное UB, если не сегодня, то при следущем обновлении. > Покажи, пожалуйста, хоть один, который реализует стандарт полностью. Покажи, пожалуйста, хоть одну кодовую базу, которая использует полностью все новейшие возможности языка. > Си - это такой... как сказать... высокоуровненый ассемблер что ли. C (API) - это дефакто стандарт совместимости между программами на любых языках, включая те, которым без году неделя, но нос до небес, ведь хозяин из M$ их похвалил и кость бросил.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (105), 22-Апр-24, 15:28
	> С кодом, который на разных версиях компиляторов выдает разные результаты. Можно пример?
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	116. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	–1 +/–
	Сообщение от Аноним (117), 22-Апр-24, 16:40
	Да легко - берешь любой код с сишным UB или implementation defined и приехали. int main() {     int i=7;     i = i++ * i++;     return i; } По ссылке godbolt.org/z/s3Kve4chY 6 компиляторов и целых 3 (ТРИ) разных результата. GCC 4.8 - 56, GCC 4.7 - 51. И ведь все по "стандарту" сделано, компиляторы только какие-то ворнинги сыпет, и то, не все компиляторы.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (105), 22-Апр-24, 17:15
	Ля, я думал там что-то настоящее, то что имеет место быть в реальном коде и даёт разный результат. Ну ты ж сам написал ответ - UB, а значит результат может быть любой, какие вопросы что он разный везде?  Лично кажется 56 - логичным, но это моё личное мнение int i = 7; i++ * i++; 1. пост-инкрементируем 7 2. умножаем 8 на 7 Но в любом случае это UB и так писать нельзя. Ты покажи нормальный код без UB и где результат разный на разных версиях компилятора
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	–1 +/–
	Сообщение от Аноним (-), 22-Апр-24, 17:32
	> Ля, я думал там что-то настоящее, то что имеет место быть в реальном коде и даёт разный результат. Вот тебе пример настоящего и вполне реального кода opennet.ru/opennews/art.shtml?num=58612 "устранена уязвимость, позволяющая поднять свои привилегии в системе бла-бла" Фикс выглядит так -        else +        else {              free(to->button->xkb_acts); +            to->button->xkb_acts = NULL; +        } gitlab.freedesktop.org/xorg/xserver/-/commit/0ba6d8c37071131a49790243cdac55392ecf71ec Это происходит по причине того, что в дыряшке очень любят пихать UB куда надо и не надо J.2: The behavior is undefined in the following circumstances: ... - The value of a pointer that refers to space deallocated by a call to the free or realloc function is used (7.20.3). > Но в любом случае это UB и так писать нельзя. Но пишут. Причем в реальном, много где используемом софте! > Ты покажи нормальный код без UB и где результат разный на разных версиях компилятора Ты лучше покажи мне программу на СИ без UB/IB/ID и тд)) Я уже молчу, что только в С99 как минимум 193 варианта UB.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Ivan_83 (ok), 22-Апр-24, 17:41
	То что вы показали это фикс для use-after-free, никак не UB.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 22-Апр-24, 18:02
	> какие вопросы что он разный везде? А... т.е. все ок, никаких проблем нет? Я правильно понял? > Но в любом случае это UB и так писать нельзя. Ахаха, а то что? Компилятор пальчиком погрозит? > Ты покажи нормальный код без UB и где результат разный на разных версиях компилятора Ты лучше покажи сишный код написанный без UB. Они же везде - в ядре, в иксах, в прикладном софте. Вот тебе пример их x11 CVE-2023-43787. Signed integer overflow. Которые тоже UB. Так что, так нельзя писать?)) И в ядре таких мест куча. Тут даже статейку написали lwn.net/Articles/511259 про то, что оптимизации ломают овнокод ядра, который опирается на поведение signed integer overflow.
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	132. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (105), 22-Апр-24, 18:09
	> Вот тебе пример их x11 CVE-2023-43787. Signed integer overflow. Которые тоже UB. > Так что, так нельзя писать?)) Я не понимаю что ты пытаешься сказать, сорри. То что в расте overflow проверяется всегда и нет возможности это отключить? Ну наверно, я хз. В Си нет - оверфлоу не проверяется самим языком, как и в ассемблере он не проверяется. Ну у тебя есть возможность его проверить самому. Хочешь - проверяй, хочешь - не проверяй.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 22-Апр-24, 18:22
	> Я не понимаю что ты пытаешься сказать, сорри. Проблема не в том, проверяется он или нет. А в том что поведение неопределенное. > То что в расте overflow проверяется всегда и нет возможности это отключить? Нет, в расте оно так: - в дебаге будут проверки и ошибка checks for integer overflow that cause your program to panic at runtime if this behavior occurs. - в релизе будет two’s complement wrapping. Но! Поведение будет всегда одно и тоже. doc.rust-lang.org/book/ch03-02-data-types.html Нет у них UB в этом вопросе. Как и в других. При этом если ты хочешь специфицировать другое поведение - то для этого есть функции wrapping_, overflowing_, saturating_ и checked_. А для си у тебя получаются код, которые просто выдает разный результат.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (105), 22-Апр-24, 18:27
	> А для си у тебя получаются код, которые просто выдает разный результат. потому что простота реализации и лаконичность :)
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 22-Апр-24, 18:34
	>> А для си у тебя получаются код, которые просто выдает разный результат. > потому что простота реализации и лаконичность :) Бот что-то лютует. Хз чего он скрыл твой коммент... "Простота реализации и лаконичность" это наверное круто. Но это было актуально когда компьютеры были очень медленными. А сейчас я бы предпочел cи2, с таким же синтаксисом, но с решением всех этих проблем, даже путем слома обратной совместимости. Пусть новый компилятор ругается на все эти места. Их тогда исправят при желании.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 22-Апр-24, 18:26
	> Я не понимаю что ты пытаешься сказать, сорри. 1. UB и прочие каки в 'стандарте' приводят к ошибкам 2. Такой код пишется в прод, включая ядро и кучу либ 3. Отслеживать и предотвращать такие ошибки не научились за пол века и повторяют их постоянно (новости можно читать каждые 2 недели) 4. Ошибки приводят к уязвимостям включая RCE 5. Без слома обратной совместимости исправить все недостатки невозможно, проще уже написать новый язык Мой вывод - СИ, как инструмент написания ядра не удовлетворяет условиям надежности, детерминированности и тд Если инструмент плохой - его нужно выкидывать.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	151. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (151), 22-Апр-24, 23:54
	Если бы был такой безопасный язык, который ломал обратную совместимость с Си ровно в необходимом объёме. А его нет, так что многие берут Си-с-расширениями, берут плюсы и называют их удовлетворительными инструментами. Хотя перспективы... Страуструп после заявления АНБ про memory-safety назвал ситуацию чрезвычайной (current “emergency”) и... перевёл разговор на тему, что бывает много других видов безопасности, мда. C++ будущего - это замороженный язык. Если назвать плюсы достаточно большим шагом вперёд, то всё равно Линус "C++ is a horrible language" Торвальдс и Бьёрн "C++ exceptions have been successfully used in [Linux] kernel code" Страуструп катастрофически расходятся во взглядах на ядро.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 22-Апр-24, 18:08
	Вот тебе без UB. int main() {     int i=-42;     i = i >> 5;     return i; } Right-shifting a signed integer value which is negative is implementation-dependent. Код, содержащий implementation-dependent - более чем валидный. godbolt.org/z/dGnfPj7ad GCC 11.3 - 254 MinGW GCC 11.3 - 4294967294 Вот такая вот прекрасная переносимость)) Причем по "стандарту" implementation-dependent может меняться от версии к версии.
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	141. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от n00by (ok), 22-Апр-24, 19:01
	Порадуете примером из жизни, где бы такое понадобилось? Что бы не считать за непонимание, как выполнять деление.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (196), 26-Апр-24, 09:44
	>Right-shifting a signed integer value which is negative is implementation-dependent. И что из написанного здесь тебе не понятно?
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	120. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Аноним (105), 22-Апр-24, 17:25
	> Да легко - берешь любой код с сишным UB или implementation defined и приехали. Ясно, ссылку можно даже не открывать > И ведь все по "стандарту" сделано, компиляторы только какие-то ворнинги сыпет, и то, не все компиляторы. Именно, что по стандарту и результат соответствует стандарту, то есть - ваще ЛЮБОЙ. А у меня тоже к тебе вопрос. Ты реально думаешь что вот этот пример выше это проблема? Ну просто когда ты инкрементируешь переменную и умножаешь ее на самому себя, еще раз инкрементируя. Какой результат ты сам то тут ожидаешь? И почему?
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	122. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 22-Апр-24, 17:41
	Я выше скинул ссылку на реальную уязвимость из ХОрга. > Именно, что по стандарту и результат соответствует стандарту, то есть - ваще ЛЮБОЙ. СТАНДАРТ 1. Образец, к-рому должно соответствовать, удовлетворять что-н. по своим признакам, свойствам, качествам, а также документ, содержащий в себе соответствующие сведения Если у тебя один и тот же код, дает разный результат просто при смене версии одного и того же компилятора, то это не стандарт. "Стандарт СИ" это почти как Гост на колбасу вида "колбаса делается из мяса, может содержать добавки в виде сала, туал.бумаги или овна, в зависимости от желания компилятора рецепта - повара" Не думаю что оно тебя бы сильно порадовало) > А у меня тоже к тебе вопрос. Ты реально думаешь что вот этот пример выше это проблема? Не, конкретно это не прроблема, хотя я допускаю что есть какой-то код в продакшене где такие грабли разбросали. > Какой результат ты сам то тут ожидаешь? И почему? Любой. Главное одинаковый! Но зависящий от компиялтора, его версии, фазы луны, погоді на марсе и тд. Потому что если твоя програма 99 раз считает верно, а в 100й отстреливает тебе пятую точку, то это просто какая-то фигня.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (105), 22-Апр-24, 17:47
	Ок, напиши такой же код на расте и проверим на разных версия раста. Хотя... давай я напишу на Си так, как ты бы написал на расте. int i = 7; i += 1; i = i * i; теперь везде одинаково? На всех версия gcc?
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Аноним (105), 22-Апр-24, 17:43
	Ага, а в расте ваще нету префикс/постфикс инкремента. То есть ваще нету Preincrement and postincrement (and the decrement equivalents), while convenient, are also fairly complex. They require knowledge of evaluation order, and often lead to subtle bugs and undefined behavior in C and C++. x = x + 1 or x += 1 is only slightly longer, but unambiguous. Понятно в общем. То есть в расте не решили эту проблему, а просто убрали фичу. Как говорится, нет кода - нет багов
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	133. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 22-Апр-24, 18:12
	> То есть в расте не решили эту проблему, а просто убрали фичу. А тут уже философский вопрос. Добавить "фичу" и заодно сделать UB, который в общем случае позволяет компилятору во время оптимизации делать вообще что хочет - выкинуть эту ветку напр. Или не добавлять фичу, зато сделать поведение однозначным.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (105), 22-Апр-24, 18:21
	Кстати, я что сказать то хотел. Спасибо, что не грубишь, как большинство тут :) Было приятно подискуттировать :)
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 23-Апр-24, 13:58
	> По ссылке godbolt.org/z/s3Kve4chY 6 компиляторов и целых 3 (ТРИ) разных результата. > GCC 4.8 - 56, GCC 4.7 - 51. > И ведь все по "стандарту" сделано, компиляторы только какие-то ворнинги сыпет, и > то, не все компиляторы. Как это - по стандарту? Если в стандарте сказано что эт UB и компилеря варнинингами сыпят? Это как раз пример покладания на стандарты програмером.
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	178. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 23-Апр-24, 14:14
	> Как это - по стандарту? Если в стандарте сказано что эт UB > и компилеря варнинингами сыпят? Это как раз пример покладания на стандарты > програмером. А если не сыплят? Потому что в стандарте про варнинги ничего не сказано?)) Если тебе норма называть стандартом, то что работает не стабильно, то ладно, не буду спорить.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 23-Апр-24, 14:48
	> А если не сыплят? "А если рельсу?!" (c) суровые сибирские мужики vs лесопилка. > Потому что в стандарте про варнинги ничего не сказано?)) Потому что господа стандартизаторы сделали проще - таки себе. Но остальные сделали себе и еще проще - вообще не релизя никакие стандарты, так что сравнивать тупо не с чем. > Если тебе норма называть стандартом, то что работает не стабильно, то ладно, > не буду спорить. Ну остальные даже и так не смогли - так что даже и сравнить то не с чем. Не, конечно есть ECMA для жаба скрипта. Но там вообще можно приравнять бананы к самосвалам, это нормалек и by design. Что сие означает и будет ли это корректно работать - ну, вы поняли. Но это тоже по стандарту. И дажэе варнинга может не быть, ибо не баг .
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 23-Апр-24, 15:37
	> "А если рельсу?!" (c) суровые сибирские мужики vs лесопилка. Ну так это просто еще одна проблема) > Потому что господа стандартизаторы сделали проще - таки себе. Но остальные сделали > себе и еще проще - вообще не релизя никакие стандарты, так что сравнивать тупо не с чем. ИСО стандраты (на который так неистово нафапывают сишники) есть для совсем небольшого кол-ва языков. Среди которых не только Ada, Fortran и COBOL, но и Pascal с BASIC'ом. И что-то я не видел такого кол-ва UB и прочего сделаго спустя рукава, в их стандартах. Так что стандарт стандарту рознь, на жаваскрипте ядро писать не будут (надеюсь)
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 26-Апр-24, 23:54
	>> "А если рельсу?!" (c) суровые сибирские мужики vs лесопилка. > Ну так это просто еще одна проблема) А что, я могу это хрустикам вернуть с gccrs который (пока еще) без боров-чекера. Вопросы полноты реализации - они такие. > ИСО стандраты (на который так неистово нафапывают сишники) есть для совсем небольшого > кол-ва языков. Зато есть таки ну вот реально - кондовые доки на которые можно равняться. И если это > Среди которых не только Ada, Fortran и COBOL, но и Pascal с BASIC'ом. Ну так первые три местами даже бывают. Нишевые штуки, но все же. Остальные два - ну, хз. Они просто дурацкие с самого начала были. И никакой стандарт в этом случае не поможет. Кто сказал что 100% стандартов - в ходу? > И что-то я не видел такого кол-ва UB и прочего сделаго спустя рукава, в их стандартах. Ну так их стандарты в основном появились сильно позже. Хотя на лично мое мнение я бы поимел вон тех господ без вазелина и заставил задефайнить все и вся. А noncompliant код - был бы явно маркирован более древней редакцией, было бы сразу видно - UNSAFE. > Так что стандарт стандарту рознь, на жаваскрипте ядро писать не будут (надеюсь) Да вообще для жыэса есть и довольно небольшие аккуратные движки. Порой даже таки - соответствующие ECMA какойнить.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 23-Апр-24, 12:54
	> Не все ж время использовать каменные топоры. Да вот блин, вскопать грядку большим экскаватором - можно, но дестроя многовато. Куб грунта за раз (меньше не получается, простите) - хренакс, и вообще не поймешь, грядка это или чего. А после пары таких сессий земледелия проще место жительства сменить, чтобы не жить на свалке, и дом как раз куда-то сползать начал. > С кучей непродуманных мест сделаных "на отвались", т.е на "нам решать лениво, > пусть там компилятор сам разберется". В C99 и далее частично починили - но увы, не хватило комитета тупарей на полный вариант того что надо было сделать. > С кодом, который на разных версиях компиляторов выдает разные результаты. > С просто ужасными компиляторами, ни один из открытых нереализует язык полностью. Маленькая пробема только в том что все остальные оказались еще ужаснее. Не, ассемблер мы рассматривать не будем, он еще ужаснее из-за полной неструктурированости и непортабельности. Да и в глобальных оптимизациях компилеры могут дать мастеркласс и ассемблерщику. А вот как раз педальность всяких указателей и проч - позволяет очень крутые оптимизации. Которые более продвинутые ЯП не могут себе позволить из-за даваемых гарантий.
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	174. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 23-Апр-24, 13:40
	> Да вот блин, вскопать грядку большим экскаватором - можно, но дестроя многовато. > Куб грунта за раз (меньше не получается, простите) - хренакс, и вообще не поймешь, грядка это или чего. Так копай маленьким) Они же тоже существуют. А еще есть мотоблоки. Тоже оптимизация. Но пример хороший. Когда код был размером с грядку то лопаты хватало. Утилитки на 10 LOC, которые можно писать принимая патчи по почте (хорошо хоть не голубиной). Кто в здравом уме будет 40 соток копать ручками? А теперь участок стал много гектаров. На нем закопаны каналы связи, неразорвавшиеся бомбы, трубы канализации... И его одновременно обрабатывают 100500 человек. Приходит такой васян с лопатой и фигак, разломал что-то важное. И даже не заметил. А потом через 10 лет, кто-то обнаружи утечку фекалий прямо юзеру запазуху. >  А после пары таких сессий земледелия проще место жительства сменить, чтобы не жить на свалке, > и дом как раз куда-то сползать начал. А типа ядро это сейчас не свалка?) > В C99 и далее частично починили - но увы, не хватило комитета тупарей на полный вариант того что надо было сделать. Т.е есть проблему решить не смогли. > Маленькая пробема только в том что все остальные оказались еще ужаснее. Не, ассемблер мы рассматривать не будем, он еще ужаснее из-за полной неструктурированости и непортабельности. Не думаю что остальные еще хуже, просто отказ от старого это всега тяжело. > Да и в глобальных оптимизациях компилеры могут дать мастеркласс и ассемблерщику. Согласен, компиляторы конечно по глобальным оптимизациям. Но мысль была о том, что ты можешь запилить компилятор, не реализовать половину свойст языка и все равно назвать его "компиялятор С", а не "компилятор половины СИ, худшей половины" > А вот как раз педальность всяких указателей и проч - позволяет очень > крутые оптимизации. Которые более продвинутые ЯП не могут себе позволить из-за > даваемых гарантий. Это было актуально, когда компы были медленные. И интернета не было) Ты готов поменять увеличение производительности на 5-10-15% в обмен на потенциальный бекдор? Сейчас я не готов на такие жертвы.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 23-Апр-24, 14:19
	> Так копай маленьким) Они же тоже существуют. > А еще есть мотоблоки. Тоже оптимизация. Ну, вот, хруст какой - может и имеет шансы вписаться в эту нишу. Время покажет. А остальные серебряные пули на поверку оказались из других материалов. Решая одни проблемы привносят более 9000 других. И вот уже дом съезжает в какую-то канаву, а во дворе бьет незапланированный фонтан, г-на по колено, а если фонтан и удается заделать - через месяц он пытается прорезаться в новом месте. > Кто в здравом уме будет 40 соток копать ручками? Да легко. Нанимают кучутаджиков и всем пофиг как. Это ж разово. > А теперь участок стал много гектаров. Ну и вот тут вопрос - а хотели ли мы быть помещиками-латифундистами? Или надо было вовремя остановиться и немного урезать осетра? Так что кернел это кернел. А не универсальное блин решение всех проблем человечества. > Приходит такой васян с лопатой и фигак, разломал что-то важное. И даже не заметил. То ли дело экскаваторщик. Копнул, взорвалось 2 бомбы, е...шит высоковольтный кабель, фигачит фонтан, а перепуганые жители спешно сдристывают из локации кто во что горазд, если было куда, чтобы не гадать прибьет их напряжением в паре с водичкой от фонтана - или таки осколками бомб? > А потом через 10 лет, кто-то обнаружи утечку фекалий прямо юзеру запазуху. По сравнению с вон тем это, возможно, не такая уж большая проблема была... > Т.е есть проблему решить не смогли. Т.е. решили половинчато. Но да, в целом - незачет. > Не думаю что остальные еще хуже, просто отказ от старого это всега тяжело. Ну как бы на этом дофейхоа кода и его за обозримое время никто не перепишет. Поэтому будут и проблемы лопат - а заодно и косты майнтенанса экскаваторов теперь заодно. Не сказать что дешевые. Но да, это не значит что лопаты пик совершенства и ничего лучше быть не может в принципе. > Но мысль была о том, что ты можешь запилить компилятор, не реализовать > половину свойст языка и все равно назвать его "компиялятор С", а > не "компилятор половины СИ, худшей половины" Ну как бы есть штуки типа C4. Это компилер если что, а не... - C in 4 functions :). А нечто типа tcc - даже и довольно полный C99 так то, с вполне обозримой кодовой базой. Много ли иных яп вообще таким похвастать могут? У сишки реально простое языковое core. Остальным на ЭТО талантов явно не хватило. Увы и ах. Какой-нибудь хруст например костылили, костылят и будут костылить. > Это было актуально, когда компы были медленные. И интернета не было) Да вот видите ли - в ядре сейчас рефакторов пачка, потому что с сверхскоростными SSD все упирается - в оверхед кода ядра. И если ваш сервак в разы медленнее того что железо могло бы из-за оверхеда в коде ядра - что вы скажете на такой рост костов?! Ну вон там народ и надрывается, а высококонцептуальные микроядра так никому и не надо, столько лет спустя. Потому что платить в разы больше за тот же результат всех почему-то дико душит жаба. > Ты готов поменять увеличение производительности на 5-10-15% в обмен на потенциальный бекдор? В ядре это и в разы может оказаться. Вооон там игогошики проверяли с драйвером FAT32 на го. Познали горя по полной програме. Пока занимались всем этим миндфаком - наступил кризис, гугл вообще проект задвинул. Ну что, накорябали концЭптуальный драйвер, джуны?! :) > Сейчас я не готов на такие жертвы. Можете юзать микроядра, редокс осы всякие и проч. Только вот что-то с перфомансом там не очень и дрова кодить никто не рвется. Потому что получается жесткий запрыг по граблям взявшимися изниоткуда. И вот уже перепуганые жители линяют из локации где хреначит высокое напряжение и разлетаются осколки.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Fracta1L (ok), 22-Апр-24, 13:46
	При программировании на сишке нужно выполнять уйму ручной работы. А уйма ручной работы как раз оставляет меньше времени на думанье.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	134. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+2 +/–
	Сообщение от Аноним (-), 22-Апр-24, 18:14
	> А уйма ручной работы как раз оставляет меньше времени на думанье. Проблема не только в думаньи. А во внимательности, которая тоже ресурс. Большая часть дыр в ядре, если отбросить теории заговора, это просто невнимательность. Но пока что не изобрели усилитель внимательности для мясных мешков (вещества не предлагать, такое ощущение что половина ядра под ними написана)
	Ответить | Правка | Наверх | Cообщить модератору

16. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+4 +/–
Сообщение от Аноним (16), 22-Апр-24, 09:52
Кто сказал NetBSD?
Ответить | Правка | Наверх | Cообщить модератору

	33. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (33), 22-Апр-24, 10:23
	В какой БЗДе используют Lua? В НетБЗДе? Там он навроде системный комфигуратор?
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+2 +/–
	Сообщение от Сообщество (?), 22-Апр-24, 10:40
	https://www.opennet.me/opennews/art.shtml?num=38203
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (105), 22-Апр-24, 11:25
	https://man.netbsd.org/intro.3lua
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	63. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от n00by (ok), 22-Апр-24, 11:32
	https://github.com/luainkernel/lua-netbsd
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	124. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Ivan_83 (ok), 22-Апр-24, 17:42
	В FreeBSD LUA используется в загрузчике, кажется вместо фортрана :)
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	142. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от n00by (ok), 22-Апр-24, 19:02
	Вроде бы там был Форт?
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	–1 +/–
	Сообщение от Аноним (105), 22-Апр-24, 19:52
	уже больше 10 лет как нету
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (146), 22-Апр-24, 20:40
	> уже больше 10 лет как нету Какой у вас там, в будущем, курс битка? https://github.com/lattera/freebsd/blob/master/sys/boot/fort... https://man.freebsd.org/cgi/man.cgi?loader(8)
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (105), 22-Апр-24, 21:23
	Хм... а я что-то помнил, что переписали загрузчик на Си и форт вообще выкинули из базовой системы. Ок, все по-прежнему значит :)
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (146), 22-Апр-24, 21:47
	> Хм... а я что-то помнил, что переписали загрузчик на Си и форт Ну, луа для скритухи (те же загрузочные менюшки) с 12 версии по умолчанию, а форт - легаси. Но пока жрать не просит, выносить не спешат (луддиты, что с них взять, вот лапч^W оголтел^W мировые продвигатели прогресса ради прогресса - выкинули сразу бы после встройки поддержки луа "Мне пофиг, что у тебя там сломалось! УМВР, а это устарело и окаменело!")
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (154), 23-Апр-24, 01:48
	> лапч Просто Линукс -- активно развиваемое ядро, а не погрызанный копролит. В таком положении, во-первых, всегда есть из чего выбирать и, во-вторых, банально необходимо выкидывать всё, на что не нашлось сопровождающего для починки перманентного стейбл-апи-нонсенса, в пользу того, что есть кому сопровождать и, возможно, развивать.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Ivan_83 (ok), 23-Апр-24, 04:13
	Не в этом дело, а в длительной поддержке. У вас это есть в редхэте за деньги.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 23-Апр-24, 13:05
	> Вроде бы там был Форт? Форт, фортран... некроманская языка - цука сложная, хрен прочухаешь, поразвели, понимаешь, названий!
	Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

	185. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от n00by (ok), 23-Апр-24, 15:39
	Оба эти языка классика. ВсеЗнают™ первый из курса истории ЯП, а второй из анекдота: Речи тайна Йоды магистра раскрыта - на Форте программист просто старый оказывается он.
	Ответить | Правка | Наверх | Cообщить модератору

17. Скрыто модератором	–3 +/–
Сообщение от Аноним (17), 22-Апр-24, 09:59
Бредовая хреновина, лучше допилите раст-инфраструктуру в ядре, чтобы модули было писать легко и приятно.
Ответить | Правка | Наверх | Cообщить модератору

	21. Скрыто модератором	+3 +/–
	Сообщение от Аноним (6), 22-Апр-24, 10:12
	Открою тебе тайну вся инфра для модулей на расте уже доступна легка и приятна. Только никто модули на расте так и не пишет.
	Ответить | Правка | Наверх | Cообщить модератору

	25. Скрыто модератором	+1 +/–
	Сообщение от ХрюХрю (?), 22-Апр-24, 10:16
	> Бредовая хреновина, лучше допилите раст-инфраструктуру в ядре, чтобы модули было писать легко и приятно. Как вообще с таким тяжелым синтаксисом могли пустить в ядро, мне не понятно.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	42. Скрыто модератором	+1 +/–
	Сообщение от Пряник (?), 22-Апр-24, 10:50
	Ты хоть думаешь, что пишешь? Чем тебя смутил expect(); вместо if (a = b()) == -1 {perror(); exit();}? Чем тебя смутили макросы в виде синтаксического дерева, а не сырой постановки текста, перечисления, поддерживающие любые значения (например, структура с результатом, если перечисление Ok()), структуры с методами? Жёсткий контроль жизни переменных, остутствие безпризорных данных в куче. Можно любой тип данных научить делать map(), collect(), into() всего одним методом! Такого даже питон не умеет.
	Ответить | Правка | Наверх | Cообщить модератору

	54. Скрыто модератором	+1 +/–
	Сообщение от n00by (ok), 22-Апр-24, 11:15
	> Ты хоть думаешь, что пишешь? > Чем тебя смутил expect(); вместо if (a = b()) == -1 {perror(); > exit();}? Очевидно тем, что в ядре нет exit().
	Ответить | Правка | Наверх | Cообщить модератору

	199. Скрыто модератором	+/–
	Сообщение от Аноним (196), 26-Апр-24, 09:54
	Ок, недостатки ты перечислил, а достоинства у Rust будут?
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	204. Скрыто модератором	+/–
	Сообщение от Пряник (?), 26-Апр-24, 11:50
	Если это недостатки, то представь какие у Rust тогда достоинства!
	Ответить | Правка | Наверх | Cообщить модератору

	96. Скрыто модератором	+/–
	Сообщение от Аноним (96), 22-Апр-24, 14:31
	Важна семантика, а не синтаксис. К любому синтаксису привыкаешь через 3 недели активного программирования на любом языке.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	100. Скрыто модератором	+1 +/–
	Сообщение от Аноним (105), 22-Апр-24, 14:47
	И семантика у раст, мягко говоря, не очень
	Ответить | Правка | Наверх | Cообщить модератору

	157. Скрыто модератором	+3 +/–
	Сообщение от Аноним (154), 23-Апр-24, 01:53
	Семантика у Раста - это эксперимент. Когда (через несколько лет) выяснится, что она переусложненная и бесполезная фигня, из неё возьмут лучшие идеи, а остальное выкинут на мороз. И что будут делать те, кто понатащил это неудачный эксперимент во всех октрытые проекты, M$ не волнует, наоборот, чем хуже вам, тем лучше им.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	192. Скрыто модератором	+/–
	Сообщение от Аноним (192), 23-Апр-24, 23:42
	Как с языка снял, только надо заменить Раст на C++. Кресты сейчас и выкидывают отовсюду на мороз, предварительно обкатав и забрав лучшее в rust.
	Ответить | Правка | Наверх | Cообщить модератору

	200. Скрыто модератором	+/–
	Сообщение от Аноним (196), 26-Апр-24, 09:57
	Интересная у вас там параллельная реальность.
	Ответить | Правка | Наверх | Cообщить модератору

	172. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 23-Апр-24, 13:10
	>> Бредовая хреновина, лучше допилите раст-инфраструктуру в ядре, чтобы модули было >> писать легко и приятно. > Как вообще с таким тяжелым синтаксисом могли пустить в ядро, мне не понятно. А его никто и не пускал - это самопальный сторонний проект если что. Если ты завтра накодишь какую-то хрень как ядерный модуль, скажем, интерпретатор брейнфака - тоже можешь новость запулить. Никого не спрашивая "а можно ли?". Примут ли это в майнлайн и будут ли этим пользоваться - совершенно другой вопрос уже.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	31. Скрыто модератором	+3 +/–
	Сообщение от Ivan_83 (ok), 22-Апр-24, 10:22
	Как вы собрались бустрапится? Эта поделка кресты кое как заменяет, никакой он не "системный", учитывая унылый компелятор.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	51. Скрыто модератором	+/–
	Сообщение от Аноним (17), 22-Апр-24, 11:05
	> Как вы собрались бустрапится? Так же, как и всегда. Напоминаю путь бутстрапинга сишки: hex0 -> hex1 -> hex2 -> cc_x86 -> M2-Planet -> mes -> tinycc -> tinycc -> tinycc -> tinycc -> gcc -> gcc. Первые версии раста написаны не на расте, так что далее дополним цепочку каким-нибудь ocaml -> rust -> rust -> rust.
	Ответить | Правка | Наверх | Cообщить модератору

	127. Скрыто модератором	+1 +/–
	Сообщение от Ivan_83 (ok), 22-Апр-24, 17:46
	Он и не будет написан на расте, потому что LLVM слишком большой чтобы растовики его переписали. И вопрос был в том, как вы со своим растом будете бустрапится, особенно на какой то железке где памяти меньше гига, и архитетура которой не поддерживается растом.
	Ответить | Правка | Наверх | Cообщить модератору

	143. Скрыто модератором	+/–
	Сообщение от morath (?), 22-Апр-24, 19:50
	> LLVM слишком большой чтобы растовики его переписали. LLVM уже потихоньку заменяют на чисто rust-овый cranelift. https://github.com/rust-lang/rustc_codegen_cranelift
	Ответить | Правка | Наверх | Cообщить модератору

	145. Скрыто модератором	+/–
	Сообщение от Аноним (105), 22-Апр-24, 19:55
	> $ git clone https://github.com/rust-lang/rustc_codegen_cranelift все еще сишные проги юзают, не щитово
	Ответить | Правка | Наверх | Cообщить модератору

	47. Скрыто модератором	+/–
	Сообщение от Пряник (?), 22-Апр-24, 10:58
	Это Open Source - всё, что не делается - всё к лучшему. А, если тебе не нравится - выкинь из своего ядра или используй подходящий дистрибутив.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	86. Скрыто модератором	+1 +/–
	Сообщение от Аноним (65), 22-Апр-24, 13:26
	Rust, писать легко и приятно - оксюморон.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	182. Скрыто модератором	+/–
	Сообщение от Аноним (182), 23-Апр-24, 15:17
	Лучше бы допилили сам раст, прежде чем его везде впихать.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

19. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+2 +/–
Сообщение от nonon (?), 22-Апр-24, 10:04
после нажатия "↑ ↑ ↓ ↓ ← → ← → LCTRL LALT" ядро перестаёт обрабатывать нажатия клавиш Это типа с любого места можно ввести? Геймеры негодуют
Ответить | Правка | Наверх | Cообщить модератору

	23. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (6), 22-Апр-24, 10:13
	Да.
	Ответить | Правка | Наверх | Cообщить модератору

24. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
Сообщение от Аноним (24), 22-Апр-24, 10:13
Залипание клавиш по удержанию шифт куда привычнее.
Ответить | Правка | Наверх | Cообщить модератору

26. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
Сообщение от Ivan_83 (ok), 22-Апр-24, 10:17
Годнота! Все ограничения - мелкие и не существенные по сравнению с тем что доступно.
Ответить | Правка | Наверх | Cообщить модератору

	43. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (6), 22-Апр-24, 10:50
	Где применишь такое добро, мне может тоже надо.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

44. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
Сообщение от Анонус (?), 22-Апр-24, 10:55
eBPF можно выкидывать?
Ответить | Правка | Наверх | Cообщить модератору

	68. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Аноним (65), 22-Апр-24, 11:40
	Зачем? Наоборот, надо добавлять интерпретаторов и JIT-компиляторов разных.
	Ответить | Правка | Наверх | Cообщить модератору

48. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+2 +/–
Сообщение от n00by (ok), 22-Апр-24, 11:00
> сетевого сниффера с возможностью ведения журнала с MAC-адресами > кейлоггера для ведения лога нажатых клавиш > блокировщика клавиатуры Зачёт. И название подходящее.
Ответить | Правка | Наверх | Cообщить модератору

	76. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (76), 22-Апр-24, 12:29
	Название прямо так намекает, что система по ночам будет вести себя как типичный санамбула.
	Ответить | Правка | Наверх | Cообщить модератору

53. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
Сообщение от Аноним (53), 22-Апр-24, 11:13
лучше б moonshine
Ответить | Правка | Наверх | Cообщить модератору

73. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
Сообщение от Аноним (65), 22-Апр-24, 11:51
Следующий шаг за Латиноамериканским отделением Фонда свободного ПО - добавление в полностью свободное ядро интерпретатора Guile.
Ответить | Правка | Наверх | Cообщить модератору

	94. Скрыто модератором	+/–
	Сообщение от Столлман был прав (-), 22-Апр-24, 14:11
	Аминь и пусть ещё MIG портанут.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 22-Апр-24, 16:00
	> Следующий шаг за Латиноамериканским отделением Фонда свободного ПО - добавление в полностью свободное ядро интерпретатора Guile. Разве они умеют что-то добавлять? Вроде все новости про них были про что-то выпилиное - софт, дрова, прошивки и тд А тут целый интерпретатор добавлять...
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

75. Скрыто модератором	+1 +/–
Сообщение от Аноним (75), 22-Апр-24, 12:13
Возникла бизнес-идея, надо дать возможность добавлять модули ядра на 1C. Безопасно, патриотично. И обязать дистрибутивы, которые хотят быть в реестре отечественного ПО иметь соответствующую поддержку и повышать уровень импортозамещенности год от года. Графики там нарисовать на десять лет вперед. И назвать этот язык "Первый С". Куда обратиться, чтобы получить финансирование под это дело.
Ответить | Правка | Наверх | Cообщить модератору

	85. Скрыто модератором	+/–
	Сообщение от _kp (ok), 22-Апр-24, 13:25
	На счет патриотично - сомнительно. Ибо тарабарский язык - не родной никому. А кириллмцей не только русский записывают.
	Ответить | Правка | Наверх | Cообщить модератору

	88. Скрыто модератором	+/–
	Сообщение от Аноним (65), 22-Апр-24, 13:37
	Кириллица, говорите? Интерпретаторы Шпага, Рапира, Робик, КуМир, Дракон в ядро!
	Ответить | Правка | Наверх | Cообщить модератору

	93. Скрыто модератором	+/–
	Сообщение от _kp (ok), 22-Апр-24, 13:49
	Уминая кириллицу, имел в виду обычные человеческие языки, а не абракадабру из сокращений. Эти то, антикварные недобейсики и нрдопаскали зачем поминать. Как языки они и на этапе проектирования ценности не представляли. Из задача заcpaть мозг школьника, но что бы он не мог применить полученные "знания". Кстати, в подобных русефецированных языках, например в бейсиках, сокращения были вызваны тем, что они не писались, а переводили "денисы поповы" краденное, и количество знакомест под буквы диктовалось исходным бинарником.
	Ответить | Правка | Наверх | Cообщить модератору

	92. Скрыто модератором	+/–
	Сообщение от Fracta1L (ok), 22-Апр-24, 13:48
	Рубрика "Айтишники шутят"
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

80. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	–1 +/–
Сообщение от topin89 (ok), 22-Апр-24, 12:45
Глянул мельком -- это же хороший инструмент для быстрого прототипирования. На домашние компы такое лучше не ставить, но разрабам модулей ядра вполне может пригодится
Ответить | Правка | Наверх | Cообщить модератору

	87. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (65), 22-Апр-24, 13:30
	Особенно в датацентрах пригодится ;)
	Ответить | Правка | Наверх | Cообщить модератору

81. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
Сообщение от Аноним (82), 22-Апр-24, 12:57
Быстро пишем, медленно работает.
Ответить | Правка | Наверх | Cообщить модератору

	83. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+2 +/–
	Сообщение от Аноним (24), 22-Апр-24, 13:11
	С Растом не прокатило,никто модулей не написал,а на этом может быть и очень даже напишут.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (89), 22-Апр-24, 13:39
	На раст же переписали же пару 100 строчных драйверов. Только, у меня правда ощущение, что это диверсия, чтобы слить конкурентов. Корпорации постоянно заявляют, будто они очень заинтересованы в расте и "используют" его повсюду, а на самом деле весь код на расте очень оперативно выкидывается и заменяется нормальным, т.е. не является сколько-нибудь ключевым.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от ck (?), 22-Апр-24, 14:27
	это один из которых хэдер переписали на растовский а реализация на сях осталась?
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от нах. (?), 23-Апр-24, 08:44
	она помечена как unsafe, поэтому ее использование стало - безопастным! Хруст пока не очень подходит для такой скучной и неинтересной работы как управление контактиками для светодиодика, понимать надоть!
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	–2 +/–
	Сообщение от А в это время (?), 22-Апр-24, 14:37
	А в это время параллельные новости, скажем, про Pingora помножают на ноль весь ваш комментарий.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	102. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Аноним (105), 22-Апр-24, 14:49
	Это твоя пингора в ядре что ли? Что ты тут на ноль помножил?
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Аноним (89), 22-Апр-24, 14:50
	Фреймворки и наколенные прокси это замечательно, но это не продукты и не ПО.
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	104. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Аноним (105), 22-Апр-24, 15:03
	Да это обычный хайп. Так было с джавой, с go, теперь с растом. Все это суета, всё это пройдет, а Си останется. Смирись и прими это
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	107. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (107), 22-Апр-24, 15:21
	Java тоже останется в банковском секторе, как замена бессмертного Кобола. Каждому своя ниша.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
	Сообщение от Аноним (65), 22-Апр-24, 15:17
	Вот как мы увидим практическую пользу этой Pingora, так только тогда она перестанет помножать ваш комментарий на ноль.
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	111. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (-), 22-Апр-24, 15:57
	> Вот как мы увидим практическую пользу этой Pingora, > так только тогда она перестанет помножать ваш комментарий на ноль. Так она отрабатывает каждый раз когда тебе показывают сообщение от клаудфари. Это же не тебе лично должна быть практическая польза.
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (196), 26-Апр-24, 10:06
	Вот именно, в Cloudflare могут писать хоть на Erlang (кстати неплохая мысль), их внутренняя кухня особо ни с чем не пересекается.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Ivan_83 (ok), 22-Апр-24, 17:49
	LUA хороший как glue язык, те когда на нём бизнесслогика а тяжёлая работа работается где то в биндингах. Некоторые и тяжёлую работу пытаются делать в LUA, иногда даже получается юзабельно - prosody джаббер сервер как пример.
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

99. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	–1 +/–
Сообщение от Аноним (126), 22-Апр-24, 14:39
Жесть, нафига интерпретатор в ядре? Итак уже интеловскими заплатками производительность херите, так еще и это Жесть, я в щокэ просто
Ответить | Правка | Наверх | Cообщить модератору

	108. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	–1 +/–
	Сообщение от Аноним (65), 22-Апр-24, 15:26
	Да не боись ты так. Это ж сторонний проект на ShitHub (Кто все эти люди?). Это ещё не значит, что им палец не покажут.
	Ответить | Правка | Наверх | Cообщить модератору

110. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
Сообщение от Минона (ok), 22-Апр-24, 15:37
REPL в ядре это вин!
Ответить | Правка | Наверх | Cообщить модератору

	114. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
	Сообщение от Аноним (114), 22-Апр-24, 16:17
	> REPL в ядре это вин! Читайте внимательнее "Среди возможностей утилиты командной строки можно отменить .... использование интерактивной оболочки REPL (Read–Eval–Print Loop)".
	Ответить | Правка | Наверх | Cообщить модератору

115. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
Сообщение от oditynet (?), 22-Апр-24, 16:37
Почему не собирается у меня он? то builds не создам в папке модуля,то циклическое залипания на сборку модуля. как вообще собрать его?
Ответить | Правка | Наверх | Cообщить модератору

150. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
Сообщение от Full Master (?), 22-Апр-24, 22:43
Уже пробовали в NetBSD, хз чем оно закончилось.
Ответить | Правка | Наверх | Cообщить модератору

164. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+1 +/–
Сообщение от qweo (?), 23-Апр-24, 11:23
Это не первый подобный проект. Во времена Linux 2.6 были патчи для Lua. А в NetBSD поддержка Lua-модулей - в основной ветке. Интересно, насколько кросплатформенный модуль ядра сложно сделать? В NetBSD же есть возможность запустить нужный код ядра в пространстве пользователя. Перспективная штука!
Ответить | Правка | Наверх | Cообщить модератору

203. "Lunatik - инструментарий для создания в ядре Linux обработчи..."	+/–
Сообщение от Аноним (196), 26-Апр-24, 10:19
Вот так тихо и незаметно Lua стала вторым после C языком в ядре Linux, сразу же обогнав Rust.
Ответить | Правка | Наверх | Cообщить модератору

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

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