The OpenNET Project / Index page

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

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


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

Оглавление

Lunatik - инструментарий для создания в ядре Linux обработчиков на языке Lua, opennews (?), 22-Апр-24, (0) [смотреть все]

Сообщения [Сортировка по времени | 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ообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру