The OpenNET Project / Index page

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

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


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

Оглавление

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

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


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

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

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




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

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