Проект Lunatik развивает инструментарий, позволяющий использовать язык Lua для расширения функциональности ядра Linux и быстрого написания скриптов-обработчиков, работающих на уровне ядра. Для выполнения кода задействован интерпретатор Lua, модифицированный для работы на уровне ядра. Код проекта написан на языке Си и распространяется под лицензией MIT...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61040
lua - непригодный язык. Лучше бы WASM-интерпретатор или jit в ядро засунули.
> lua - непригодный язык. Лучше бы WASM-интерпретатор или jit в ядро засунули.Нормальный lua, просто не место в ядре всякой шляпе, ониб ещё JS туда затолкали!
Ты не поверишь...
https://github.com/mildsunrise/node_bpf
> Ты не поверишь...
> https://github.com/mildsunrise/node_bpf- Новый продукт - Node WTF!
- WPF?!
- BPF!
Извини, но разница между счётным множеством и континуумом - принципиальна и неустранима, поэтому язык, в котором изначально отсутствует целый тип (который позже примотали изолентой) не может считаться нормальным.
В нормальных алгорифмах Маркова нет целого типа. Зато возможна длинная арифметика, которую к целым типам прикручивают изолентой.
Зато безопасный. Неизвестно что в твой васм запихнут, а Джит это дыра в безопасности бай дизайн.
Ну да ну да, а ebpf это нормально это можно.
> Ну да ну да, а ebpf это нормально это можно.Ну так и сделай транслятор WASM -> EBPF, и хрен кто такой ход конем оспорит, прикинь? :))
Java, Java должна быть в ядре.
И Qml
Помню в 90х даже были пк-приставки к телеку-монитору на джавеИ так то слышал что после разогрева джава в полтора раза медленнее нативного кода
Думаю что оптимизаций там по более, чем в луа
иногда даже быстрее, но памяти в любом случае больше кушает.
Это не так работает :)В том смысле что эволюционно так получилось что есть языки удобные для описания бизнесс логики и есть языки для написания кода который молотит данные.
Универсального языка для всего сразу как то не получается, в основном потому что ультимативная производительность предполагает ручное управление ресурсами и почти отсутствие абстракций над железом.
В конце 90х-начале 2000х такое комбо было: Visual Basic (со встроенным автоформатером кода) + Visual C++.
Первый был прекрасен чтобы по быстрому накидать простой гуй, второй был удобен чтобы по быстрому сделать dll с функциями для тяжёлых рассчётов. И это всё вместе относительно легко линковалось.
Был ещё вариант всё в одном - дельфи, но там и скорость была чуть ниже чем в С++ и прогать было по сложнее чем в вижал бейсике.Сейчас такой прямо полноценной замены этой связки я не вижу.
Вроде есть вала и питон, но питон ужасный, а валу я толком не пробовал.
Есть луа, но с гуем там официально никак, а либы всякие я не искал.Да и в целом, я бы сказал что QT/GTK так себе тулкиты, если сравнивать их с виндовым, который по сути за 30+ сохранил совместимость, в отличии от линуксовых которые каждые лет 5 всё ломают и в принципе сложнее в использовании чем вендовый.
Ты устарел, Иван 83. Вроде версия большая, а реальности не понимаешь.Язык высокого уровня - питон, а низкого - tensorflow.
> Ты устарел, Иван 83. Вроде версия большая, а реальности не понимаешь.
> Язык высокого уровня - питон, а низкого - tensorflow.И как, хорошо на этом ядерные модули писать получается? Примеров дадите?! :)
> Универсального языка для всего сразу как то не получается, в основном потому что
> ультимативная производительность предполагает ручное управление ресурсами и почти
> отсутствие абстракций над железом.Ну вот хруст на горизонте нарисовался. Может в высокоуровневые конструкции, но при острой нужде позволяет и околосишные фокусы откалывать. И без окаменевших сишных глупостей типа "угадай какого вообще размера int и корректно ли на этой платформе вообще работает тот код?!"
Гниль имеет слишком сложный синтаксис, и расвесистую систему зависимостей как у нодыжс, тяжёлый космпелятор не везде работающий.
Это всё огромные минусы, а какого размера int мало кого интересует.
> Гниль имеет слишком сложный синтаксис, и расвесистую систему зависимостей как у нодыжс,Ну вот как бы да. Но все остальные оказались еще хуже - а дожать сишку до кондиции "en masse" все же душновато. Комитет придурков никак прожать на нормальные изменения не получается. А прогать как будто на дворе 1989 что-то уже не хочется, ибо четверть века прошло. И за нее можно уже и сделать выводы из старых грабель. Ну и вот чего делать? Вулнов многовато, проблемы сборки и портабельности тоже поднадоели порядком. Я не хочу иметь дело с "int" неопределенного размера и всем бардаком который оттуда вытекает - вечно.
> тяжёлый космпелятор не везде работающий.
> Это всё огромные минусы, а какого размера int мало кого интересует.Пока это не выльется в крахи софта, сбои фирмвар, факапы сборки, дикие баги и вулны на ровном месте и тому подобное. Извините, но - надоело. С этим пора что-то сделать. По хорошему, или уж как получится. Слушать сказки про белого бычка все-же надоело.
Ок, а какие-то реальные достоинства будут? ООП там?
LUA очень даже годный.
Там порядка 10к строк всего на С, без всяких лишних зависимостей.
Дело не в реализации, а в самом языке. Массивы с единицы и производительность улитки на списках.
Разве что не пользоваться структурами Lua
В Visual Basic были массивы с 1 по дефолту, и ничего :)
От LUA не требуется большой производительности.Один из канонических примеров её использования это парсинг конфига.
Когда конфиг по сути превращается в lua файл где переменным присваются значения, а бонусом можно накидать туда логику, типа если есть какой то файл то меняем дефолты, или если чего то там в /proc то пишем другие значения и тп.У меня дома prosody полностью (почти) написанный на луа, и проц он не жрёт.
Сейчас я сел запилить свою софтину, там куча сишных биндингов для LUA будет, и LUA только дёргать их будет и перекладывать аргументы, немного бизнес логики - сомневаюсь что оно будет сколь нибудь ощутимо жрать проц.
Пока я пробовал таймер каждую 1мс с принтом гонять и была нагрузка в районе 1-2% на одном ядре райзена. По моим прикидкам у меня эвенты будут реже случатся с одной стороны, с другой воркеров их разгребать будет больше одного.
>В Visual Basic были массивы с 1 по дефолту, и... где теперь Visual Basic?
Бывают языки, на которых удобно программировать. А бывают языки, вроде pascalя, visual basicа, lua, matlab/octave/julia и R, которые вставляют палки в колёса даже в самых элементарных вещах, вроде синтаксиса, индексации или станд. библиотеки, напр. в некоторых языках даже функции для парсинга целого числа из строки с этом целым числом в hex-виде в переменную целочисленного типа до недавнего времени не было, нужно было сторонний пакет подгружать. Зачем авторы языков так делают? В большей мере - из-за тараканов в головах. Такие языки обычно выкидываются целиком заменяются более удобными, напр. когда выяснилось, что для парсинга числа в hex нужно танцевать вприсядку, я просто выкинул тот язык целиком ффтопку и перешёл на питон, и не жалею.
VB умер, поскольку MS его заменила на C#. И какие там проблемы перевести строковое представление шестнадцатеричного числа в целое, кроме неумения написать тривиальный цикл? На VBS наверняка и сейчас что-то пишут, просто потому что он есть в Windows из коробки и может больше чем JS в том же WSH.
VBA остался в оффисе неизменным, VBS это немного другое всё же.
VBA это не VB, насколько понимаю. VBS действительно другое - по сути встроенный в Windows некий аналог bash. Правда, Гейтс немного просчитался, посчитав пользователей достаточно умными.
VB закопали в пользу C# и Vb.net, не надо думать что VB умер сам из за каких то деффектов.Первой ласточкой было то что VB6 имел не встроенную справку а она какая то отдельная была, надо было найти и скачать, а особых профитов по сравнению с VB5 там не было.
Что касается парсинга чисел - это ваше мнение.
Для меня и в С такого парсинга нет, я свой наколхозил и забыл про такую проблему уже 20 лет как.Питон тоже обречён.
Прототипировать в нём легко но эксплуатировать такое нельзя, оно просто не поддерживаемое.
Тот же хом асистант почти не ставят отдельно, только в докере или сразу образ ОС, потому что это поделие работает только на машинах разрабов.
>Для меня и в С такого парсинга нет, я свой наколхозилstrtol, C89.
> Питон тоже обречён.Прототипировать в нём легко но эксплуатировать такое нельзя, оно просто не поддерживаемое.
А поподробнее?
> Массивы с единицыКак будто что-то плохое.
> производительность улитки на списках.
«Чи-гоо б…?!?» ©
На всякий, в Lua нет списков. Есть таблицы. И они ОЧЕНЬ шустрые. Особенно когда это не key-value, а массив. Так что либо давай поподробнее (с чем сравнивать и что вообще сказать хотел) и с пруфами, либо балабол.
>jit в ядро засунулиУже засунули. eBPF называется.
И пакетный менеджер для NPM сразу в ядро, чтоб сам пакеты обновлял.
многие лютейшие дыры начинаются именно с JIT
Луа и сама по себе годится разве что для игровых скриптов, а уж с джитом да в линухоядре. Зачем так париться, проще уж один на всех логин-пароль для рута гвоздями прибить
тебе же в новости написали: для создания кейлоггеров. чтобы битки твои тырить проще было
Lua отличный язык как внутренний скниптовый движок, и для встраиваемых устройств, не тяжелый, и не совсем примитивный.
В тоже время Lua имеет несовместимости, делающие его неудобным для обшего использования.Что же касается интерпритаторов в ядре, а не в системе, это наверное последстия легализации марихуаны, и иных нехороших излишеств.
Как пример, где Lua похоронил весь проэкт, это Minetest, вроде бы быстрый движок на с++, что могло пойти не так.. А то что с самими играми, которые как раз на Lua, тормозит не по детски на топовом железе. Да и стабильность Lua смехотворная, именно из за несовместимости версий скриптов, о чем сказано в самом начале.
Вообще-то игры на lua в движке Minetest достаточно быстро работают (не все но многие). Я говорю как тот кто сам активно в них играет. В любом случае Lua точно не "похоронил" Minetest. Minetest хоть и не ориентрован на топовое оборудование но в последнее время эта ситуация улучшается.
Чтоб все так жили как Minetest "похоронили". Наверное в настоящий момент это open-source игра с самым большим и активным комьюнити. И про производительность чушь полная, нужно наверное сотню модов навешать чтобы кора дуба стала тормозить.
> после нажатия "↑ ↑ ↓ ↓ ← → ← → LCTRL LALT" ядроСделает фаталити
> Сделает фаталититак что это конами код, а не фаталити
>> после нажатия "↑ ↑ ↓ ↓ ← → ← → LCTRL LALT" ядро
> Сделает фаталитиА что, как раз - только представь себе что у тебя в самый интересный момент отвалилась клава в системе! Теперь попробуй угадать как ее включить назад без нажатия ресета! :)
Видимо, с притоком свежих программистов на сишке всё очень плохо.
Ну, это ж больно, это ж думать надо.
Как случайно очередное rce в ядро протащить?
Ну-ну.
Чтобы заставить работать любой нормальный язык в связке с сишкой, думать нужно на порядок больше, чем велосипедить очередной сплит строк на чистой сишке.
Тут скорее вопросы, хотя, это даже не вопросы, к сишникам - "почему они не могут осилить ничего кроме сишки" и "когда перестанут выходить за границы буфера"?
Вот LUA можем.
C+LUA и больше особо ничего не надо.
Даже make системы есть на LUA.
Так что у нас всё самодостаточно.
Можно просто отдать ЯП право управления компилятором и задачу прекомпилятора. Сейчас пока такое умеет только Zig, но это не значит, что им всё ограничится. Там вообще ничего кроме самого ЯП и его окружения не нужно.
Не уверен что правильно понял "отдать ЯП право управления компилятором".Помнится quick basic, Visual Basic - вполне себе и ЯП и компилятор были в одном флаконе что называется. У последнего ещё и code style с принудительным автоформатером был, потому даже самые "одарённые" писали так что при чтении кровь из глаз не текла ручьём.
Все операции, вызываемые обычно через системы сборки, умещаются в исходник на Zig с применением конструкций языка. В такой ситуации CMake — попросту ненужный бесполезный громоздкий наворот.
> Можно просто отдать ЯП право управления компилятором и задачу прекомпилятора. Сейчас пока
> такое умеет только ZigВ смысле, Nemerle помер?
А он ещё жив? К тому же, .Net — это же никак не про фундаменталку.
Не знаю, жив ли, но появился задолго до Zig. Ну и на .Net вполне написали совершенно безопасную Microsoft Singularity. Потом, правда, отправили в музей и теперь пишут другую безопасную ОС.
Mono в ядро? Зато сколько сразу языков!
>> Можно просто отдать ЯП право управления компилятором и задачу прекомпилятора. Сейчас пока
>> такое умеет только Zig
> В смысле, Nemerle помер?Нельзя убить то что никогда не жило. Эта штука всегда была где-то рядом с singularity, микроядрами и прочими концепт-карами. Много вы концепт каров на улице видели?
>>> Можно просто отдать ЯП право управления компилятором и задачу прекомпилятора. Сейчас пока
>>> такое умеет только Zig
>> В смысле, Nemerle помер?
> Нельзя убить то что никогда не жило. Эта штука всегда была где-то
> рядом с singularity, микроядрами и прочими концепт-карами. Много вы концепт каров
> на улице видели?Я не понял, к какому из языков это относится.
Разработка языка Nemerle началась в 2003 году в университете Вроцлава (Польша).
...
12 марта 2010 года была выпущена первая бета-версия компилятора языка
...
С июня 2012 года команда разработчиков Nemerle стала частью компании JetBrains, которая займётся дальнейшей разработкой и поддержкой языка.
...
Выпуск 1.2.547.0 (01.09.2017)
ZigПоявился в 2015
Выпуск 0.11.0 (4 августа 2023)
Зачем для задач Си применять что-то кроме него, если самого Си хватает с головой? Поделие, которое очень плохо вылизано под такие задачи не должно иметь приоритета только за счёт "новизны". Понятно, что у самого Си есть проблемы, которые в разной степени купируются проектами GoLang, Rust, Zig, Num и т.п., но когда предлагают замещать Си Python-ом, это уже какой-то испанский стыд...
>почему они не могут осилить ничего кроме сишкиА зачем еще что-то кроме сижки? Си это идеальный язык, минималистичный
Но с большой силой приходит и большая ответсвенность
То что некоторые допускают уязвимости в своих программах, сугубо ответсвенность писарей этих самых программ
Ей богу, надоело уже слушать эти все колкости в сторону языка
> А зачем еще что-то кроме сижки?Ну, от палки-копалки наши предки отказались, лопата осталась, но добавился еще экскаватор.
Не все ж время использовать каменные топоры.> Си это идеальный язык, минималистичный
Отвратительный язык.
С кучей непродуманных мест сделаных "на отвались", т.е на "нам решать лениво, пусть там компилятор сам разберется".
С кодом, который на разных версиях компиляторов выдает разные результаты.
С просто ужасными компиляторами, ни один из открытых нереализует язык полностью.> Но с большой силой приходит и большая ответсвенность
Иногда с возрастом приходит мудрость, иногда старость приходит сама.
За 50 лет адепты так и не смогли не портить память.> То что некоторые допускают уязвимости в своих программах, сугубо ответсвенность писарей этих самых программ
> Ей богу, надоело уже слушать эти все колкости в сторону языкаЕсли у тебя в руках инструмент из которого торчат провода и шестерни, где изоляция это что-то из области фантастики, а про защитный кожух никто никогда не слышал - то такой инструмент просто плохой.
И его надо выкинуть на помойку.
> С кучей непродуманных мест сделаных "на отвались", т.е на "нам решать лениво, пусть там компилятор сам разберется".Это ты точно про Си, а не про раст?
> С кодом, который на разных версиях компиляторов выдает разные результаты.
А язык тут причем? Все вопросы к автору компиляторов, почему md5 финального бинаря отличается
> С просто ужасными компиляторами, ни один из открытых нереализует язык полностью.
GCC, например, прекрасный оптимизирующий компилятор, генерящий код для почти всех платформ и архитектур
> За 50 лет адепты так и не смогли не портить память.
Растаманы тоже портят, просто из-под раста этого не видно, см. первую цитату про "лениво решать, пусть компилятор что-то там"
> Если у тебя в руках инструмент из которого торчат провода и шестерни, где изоляция это что-то из области фантастики, а про защитный кожух никто никогда не слышал - то такой инструмент просто плохой.
Си - это такой... как сказать... высокоуровненый ассемблер что ли. А асме тоже нету никакой защиты (но она может быть на уровне микрокода и/или архитектуры). Тебя не парит, что в asm нет никакой защиты? Ну вот и в Си так же
> Это ты точно про Си, а не про раст?Конечно. Скажи спасибо комитету за UB и ID.
> А язык тут причем? Все вопросы к автору компиляторов, почему md5 финального бинаря отличается
Так разрабы компилятора все делали по "стандарту". Ну, т.е. по тому куску ###, которое по традиции называют стандартом. И если там написано - "а мы хз, делайте как хотите", то они делают как хотят.
> GCC, например, прекрасный оптимизирующий компилятор, генерящий код для почти всех платформ и архитектур
en.cppreference.com/w/c/compiler_support
Покажи, пожалуйста, хоть один, который реализует стандарт полностью. Т.е. без "no" и "partial".
Вот только не начинай что "это не такая важная штука", "они не обязаны" и тд> Си - это такой... как сказать... высокоуровненый ассемблер что ли.
Абсолютно согласен. Вот только сейчас писать на асме больше пары страниц кода уже нет смысла - в 99% случаев компилятор оптимизирует лучше. А оставшийся 1% увидишь в профайлере и перепишешь ручками.
А на сишке пишут проекты на миллионы строк кода. И понятно что оно будет как в асме - дыра на дыре.
> Скажи спасибо комитету за UB и ID.Спасибо им, что есть стандарт. У некоторых и такого нету, а потому там любое поведение потенциальное UB, если не сегодня, то при следущем обновлении.
> Покажи, пожалуйста, хоть один, который реализует стандарт полностью.
Покажи, пожалуйста, хоть одну кодовую базу, которая использует полностью все новейшие возможности языка.
> Си - это такой... как сказать... высокоуровненый ассемблер что ли.
C (API) - это дефакто стандарт совместимости между программами на любых языках, включая те, которым без году неделя, но нос до небес, ведь хозяин из M$ их похвалил и кость бросил.
> С кодом, который на разных версиях компиляторов выдает разные результаты.Можно пример?
Да легко - берешь любой код с сишным 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.
И ведь все по "стандарту" сделано, компиляторы только какие-то ворнинги сыпет, и то, не все компиляторы.
Ля, я думал там что-то настоящее, то что имеет место быть в реальном коде и даёт разный результат.
Ну ты ж сам написал ответ - UB, а значит результат может быть любой, какие вопросы что он разный везде? Лично кажется 56 - логичным, но это моё личное мнениеint i = 7;
i++ * i++;
1. пост-инкрементируем 7
2. умножаем 8 на 7Но в любом случае это UB и так писать нельзя. Ты покажи нормальный код без UB и где результат разный на разных версиях компилятора
> Ля, я думал там что-то настоящее, то что имеет место быть в реальном коде и даёт разный результат.Вот тебе пример настоящего и вполне реального кода
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.
То что вы показали это фикс для use-after-free, никак не UB.
> какие вопросы что он разный везде?А... т.е. все ок, никаких проблем нет? Я правильно понял?
> Но в любом случае это UB и так писать нельзя.
Ахаха, а то что? Компилятор пальчиком погрозит?
> Ты покажи нормальный код без UB и где результат разный на разных версиях компилятора
Ты лучше покажи сишный код написанный без UB. Они же везде - в ядре, в иксах, в прикладном софте.
Вот тебе пример их x11 CVE-2023-43787. Signed integer overflow. Которые тоже UB.
Так что, так нельзя писать?))И в ядре таких мест куча. Тут даже статейку написали lwn.net/Articles/511259 про то, что оптимизации ломают овнокод ядра, который опирается на поведение signed integer overflow.
> Вот тебе пример их x11 CVE-2023-43787. Signed integer overflow. Которые тоже UB.
> Так что, так нельзя писать?))Я не понимаю что ты пытаешься сказать, сорри.
То что в расте overflow проверяется всегда и нет возможности это отключить? Ну наверно, я хз. В Си нет - оверфлоу не проверяется самим языком, как и в ассемблере он не проверяется. Ну у тебя есть возможность его проверить самому. Хочешь - проверяй, хочешь - не проверяй.
> Я не понимаю что ты пытаешься сказать, сорри.Проблема не в том, проверяется он или нет.
А в том что поведение неопределенное.> То что в расте 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и2, с таким же синтаксисом, но с решением всех этих проблем, даже путем слома обратной совместимости. Пусть новый компилятор ругается на все эти места. Их тогда исправят при желании.
> Я не понимаю что ты пытаешься сказать, сорри.1. UB и прочие каки в 'стандарте' приводят к ошибкам
2. Такой код пишется в прод, включая ядро и кучу либ
3. Отслеживать и предотвращать такие ошибки не научились за пол века и повторяют их постоянно (новости можно читать каждые 2 недели)
4. Ошибки приводят к уязвимостям включая RCE
5. Без слома обратной совместимости исправить все недостатки невозможно, проще уже написать новый языкМой вывод - СИ, как инструмент написания ядра не удовлетворяет условиям надежности, детерминированности и тд
Если инструмент плохой - его нужно выкидывать.
Если бы был такой безопасный язык, который ломал обратную совместимость с Си ровно в необходимом объёме. А его нет, так что многие берут Си-с-расширениями, берут плюсы и называют их удовлетворительными инструментами. Хотя перспективы... Страуструп после заявления АНБ про memory-safety назвал ситуацию чрезвычайной (current “emergency”) и... перевёл разговор на тему, что бывает много других видов безопасности, мда. C++ будущего - это замороженный язык.Если назвать плюсы достаточно большим шагом вперёд, то всё равно Линус "C++ is a horrible language" Торвальдс и Бьёрн "C++ exceptions have been successfully used in [Linux] kernel code" Страуструп катастрофически расходятся во взглядах на ядро.
Вот тебе без 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/dGnfPj7adGCC 11.3 - 254
MinGW GCC 11.3 - 4294967294Вот такая вот прекрасная переносимость))
Причем по "стандарту" implementation-dependent может меняться от версии к версии.
Порадуете примером из жизни, где бы такое понадобилось? Что бы не считать за непонимание, как выполнять деление.
>Right-shifting a signed integer value which is negative is implementation-dependent.И что из написанного здесь тебе не понятно?
> Да легко - берешь любой код с сишным UB или implementation defined и приехали.Ясно, ссылку можно даже не открывать
> И ведь все по "стандарту" сделано, компиляторы только какие-то ворнинги сыпет, и то, не все компиляторы.
Именно, что по стандарту и результат соответствует стандарту, то есть - ваще ЛЮБОЙ.
А у меня тоже к тебе вопрос. Ты реально думаешь что вот этот пример выше это проблема? Ну просто когда ты инкрементируешь переменную и умножаешь ее на самому себя, еще раз инкрементируя. Какой результат ты сам то тут ожидаешь? И почему?
Я выше скинул ссылку на реальную уязвимость из ХОрга.> Именно, что по стандарту и результат соответствует стандарту, то есть - ваще ЛЮБОЙ.
СТАНДАРТ 1. Образец, к-рому должно соответствовать, удовлетворять что-н. по своим признакам, свойствам, качествам, а также документ, содержащий в себе соответствующие сведения
Если у тебя один и тот же код, дает разный результат просто при смене версии одного и того же компилятора, то это не стандарт."Стандарт СИ" это почти как Гост на колбасу вида "колбаса делается из мяса, может содержать добавки в виде сала, туал.бумаги или овна, в зависимости от желания компилятора рецепта - повара"
Не думаю что оно тебя бы сильно порадовало)> А у меня тоже к тебе вопрос. Ты реально думаешь что вот этот пример выше это проблема?
Не, конкретно это не прроблема, хотя я допускаю что есть какой-то код в продакшене где такие грабли разбросали.
> Какой результат ты сам то тут ожидаешь? И почему?
Любой. Главное одинаковый! Но зависящий от компиялтора, его версии, фазы луны, погоді на марсе и тд.
Потому что если твоя програма 99 раз считает верно, а в 100й отстреливает тебе пятую точку, то это просто какая-то фигня.
Ок, напиши такой же код на расте и проверим на разных версия раста.Хотя... давай я напишу на Си так, как ты бы написал на расте.
int i = 7;
i += 1;
i = i * i;теперь везде одинаково? На всех версия gcc?
Ага, а в расте ваще нету префикс/постфикс инкремента. То есть ваще нету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.
Понятно в общем. То есть в расте не решили эту проблему, а просто убрали фичу. Как говорится, нет кода - нет багов
> То есть в расте не решили эту проблему, а просто убрали фичу.А тут уже философский вопрос.
Добавить "фичу" и заодно сделать UB, который в общем случае позволяет компилятору во время оптимизации делать вообще что хочет - выкинуть эту ветку напр.
Или не добавлять фичу, зато сделать поведение однозначным.
Кстати, я что сказать то хотел. Спасибо, что не грубишь, как большинство тут :) Было приятно подискуттировать :)
> По ссылке godbolt.org/z/s3Kve4chY 6 компиляторов и целых 3 (ТРИ) разных результата.
> GCC 4.8 - 56, GCC 4.7 - 51.
> И ведь все по "стандарту" сделано, компиляторы только какие-то ворнинги сыпет, и
> то, не все компиляторы.Как это - по стандарту? Если в стандарте сказано что эт UB и компилеря варнинингами сыпят? Это как раз пример покладания на стандарты програмером.
> Как это - по стандарту? Если в стандарте сказано что эт UB
> и компилеря варнинингами сыпят? Это как раз пример покладания на стандарты
> програмером.А если не сыплят? Потому что в стандарте про варнинги ничего не сказано?))
Если тебе норма называть стандартом, то что работает не стабильно, то ладно, не буду спорить.
> А если не сыплят?"А если рельсу?!" (c) суровые сибирские мужики vs лесопилка.
> Потому что в стандарте про варнинги ничего не сказано?))
Потому что господа стандартизаторы сделали проще - таки себе. Но остальные сделали себе и еще проще - вообще не релизя никакие стандарты, так что сравнивать тупо не с чем.
> Если тебе норма называть стандартом, то что работает не стабильно, то ладно,
> не буду спорить.Ну остальные даже и так не смогли - так что даже и сравнить то не с чем. Не, конечно есть ECMA для жаба скрипта. Но там вообще можно приравнять бананы к самосвалам, это нормалек и by design. Что сие означает и будет ли это корректно работать - ну, вы поняли. Но это тоже по стандарту. И дажэе варнинга может не быть, ибо не баг .
> "А если рельсу?!" (c) суровые сибирские мужики vs лесопилка.Ну так это просто еще одна проблема)
> Потому что господа стандартизаторы сделали проще - таки себе. Но остальные сделали
> себе и еще проще - вообще не релизя никакие стандарты, так что сравнивать тупо не с чем.ИСО стандраты (на который так неистово нафапывают сишники) есть для совсем небольшого кол-ва языков.
Среди которых не только Ada, Fortran и COBOL, но и Pascal с BASIC'ом.
И что-то я не видел такого кол-ва UB и прочего сделаго спустя рукава, в их стандартах.
Так что стандарт стандарту рознь, на жаваскрипте ядро писать не будут (надеюсь)
>> "А если рельсу?!" (c) суровые сибирские мужики vs лесопилка.
> Ну так это просто еще одна проблема)А что, я могу это хрустикам вернуть с gccrs который (пока еще) без боров-чекера. Вопросы полноты реализации - они такие.
> ИСО стандраты (на который так неистово нафапывают сишники) есть для совсем небольшого
> кол-ва языков.Зато есть таки ну вот реально - кондовые доки на которые можно равняться. И если это
> Среди которых не только Ada, Fortran и COBOL, но и Pascal с BASIC'ом.
Ну так первые три местами даже бывают. Нишевые штуки, но все же. Остальные два - ну, хз. Они просто дурацкие с самого начала были. И никакой стандарт в этом случае не поможет. Кто сказал что 100% стандартов - в ходу?
> И что-то я не видел такого кол-ва UB и прочего сделаго спустя рукава, в их стандартах.
Ну так их стандарты в основном появились сильно позже. Хотя на лично мое мнение я бы поимел вон тех господ без вазелина и заставил задефайнить все и вся. А noncompliant код - был бы явно маркирован более древней редакцией, было бы сразу видно - UNSAFE.
> Так что стандарт стандарту рознь, на жаваскрипте ядро писать не будут (надеюсь)
Да вообще для жыэса есть и довольно небольшие аккуратные движки. Порой даже таки - соответствующие ECMA какойнить.
> Не все ж время использовать каменные топоры.Да вот блин, вскопать грядку большим экскаватором - можно, но дестроя многовато. Куб грунта за раз (меньше не получается, простите) - хренакс, и вообще не поймешь, грядка это или чего. А после пары таких сессий земледелия проще место жительства сменить, чтобы не жить на свалке, и дом как раз куда-то сползать начал.
> С кучей непродуманных мест сделаных "на отвались", т.е на "нам решать лениво,
> пусть там компилятор сам разберется".В C99 и далее частично починили - но увы, не хватило комитета тупарей на полный вариант того что надо было сделать.
> С кодом, который на разных версиях компиляторов выдает разные результаты.
> С просто ужасными компиляторами, ни один из открытых нереализует язык полностью.Маленькая пробема только в том что все остальные оказались еще ужаснее. Не, ассемблер мы рассматривать не будем, он еще ужаснее из-за полной неструктурированости и непортабельности. Да и в глобальных оптимизациях компилеры могут дать мастеркласс и ассемблерщику.
А вот как раз педальность всяких указателей и проч - позволяет очень крутые оптимизации. Которые более продвинутые ЯП не могут себе позволить из-за даваемых гарантий.
> Да вот блин, вскопать грядку большим экскаватором - можно, но дестроя многовато.
> Куб грунта за раз (меньше не получается, простите) - хренакс, и вообще не поймешь, грядка это или чего.Так копай маленьким) Они же тоже существуют.
А еще есть мотоблоки. Тоже оптимизация.Но пример хороший.
Когда код был размером с грядку то лопаты хватало. Утилитки на 10 LOC, которые можно писать принимая патчи по почте (хорошо хоть не голубиной).
Кто в здравом уме будет 40 соток копать ручками?А теперь участок стал много гектаров.
На нем закопаны каналы связи, неразорвавшиеся бомбы, трубы канализации...
И его одновременно обрабатывают 100500 человек.
Приходит такой васян с лопатой и фигак, разломал что-то важное. И даже не заметил.
А потом через 10 лет, кто-то обнаружи утечку фекалий прямо юзеру запазуху.> А после пары таких сессий земледелия проще место жительства сменить, чтобы не жить на свалке,
> и дом как раз куда-то сползать начал.А типа ядро это сейчас не свалка?)
> В C99 и далее частично починили - но увы, не хватило комитета тупарей на полный вариант того что надо было сделать.
Т.е есть проблему решить не смогли.
> Маленькая пробема только в том что все остальные оказались еще ужаснее. Не, ассемблер мы рассматривать не будем, он еще ужаснее из-за полной неструктурированости и непортабельности.
Не думаю что остальные еще хуже, просто отказ от старого это всега тяжело.
> Да и в глобальных оптимизациях компилеры могут дать мастеркласс и ассемблерщику.
Согласен, компиляторы конечно по глобальным оптимизациям.
Но мысль была о том, что ты можешь запилить компилятор, не реализовать половину свойст языка и все равно назвать его "компиялятор С", а не "компилятор половины СИ, худшей половины"> А вот как раз педальность всяких указателей и проч - позволяет очень
> крутые оптимизации. Которые более продвинутые ЯП не могут себе позволить из-за
> даваемых гарантий.Это было актуально, когда компы были медленные. И интернета не было)
Ты готов поменять увеличение производительности на 5-10-15% в обмен на потенциальный бекдор?
Сейчас я не готов на такие жертвы.
> Так копай маленьким) Они же тоже существуют.
> А еще есть мотоблоки. Тоже оптимизация.Ну, вот, хруст какой - может и имеет шансы вписаться в эту нишу. Время покажет. А остальные серебряные пули на поверку оказались из других материалов. Решая одни проблемы привносят более 9000 других. И вот уже дом съезжает в какую-то канаву, а во дворе бьет незапланированный фонтан, г-на по колено, а если фонтан и удается заделать - через месяц он пытается прорезаться в новом месте.
> Кто в здравом уме будет 40 соток копать ручками?
Да легко. Нанимают кучутаджиков и всем пофиг как. Это ж разово.
> А теперь участок стал много гектаров.
Ну и вот тут вопрос - а хотели ли мы быть помещиками-латифундистами? Или надо было вовремя остановиться и немного урезать осетра? Так что кернел это кернел. А не универсальное блин решение всех проблем человечества.
> Приходит такой васян с лопатой и фигак, разломал что-то важное. И даже не заметил.
То ли дело экскаваторщик. Копнул, взорвалось 2 бомбы, е...шит высоковольтный кабель, фигачит фонтан, а перепуганые жители спешно сдристывают из локации кто во что горазд, если было куда, чтобы не гадать прибьет их напряжением в паре с водичкой от фонтана - или таки осколками бомб?
> А потом через 10 лет, кто-то обнаружи утечку фекалий прямо юзеру запазуху.
По сравнению с вон тем это, возможно, не такая уж большая проблема была...
> Т.е есть проблему решить не смогли.
Т.е. решили половинчато. Но да, в целом - незачет.
> Не думаю что остальные еще хуже, просто отказ от старого это всега тяжело.
Ну как бы на этом дофейхоа кода и его за обозримое время никто не перепишет. Поэтому будут и проблемы лопат - а заодно и косты майнтенанса экскаваторов теперь заодно. Не сказать что дешевые. Но да, это не значит что лопаты пик совершенства и ничего лучше быть не может в принципе.
> Но мысль была о том, что ты можешь запилить компилятор, не реализовать
> половину свойст языка и все равно назвать его "компиялятор С", а
> не "компилятор половины СИ, худшей половины"Ну как бы есть штуки типа C4. Это компилер если что, а не... - C in 4 functions :). А нечто типа tcc - даже и довольно полный C99 так то, с вполне обозримой кодовой базой. Много ли иных яп вообще таким похвастать могут? У сишки реально простое языковое core. Остальным на ЭТО талантов явно не хватило. Увы и ах. Какой-нибудь хруст например костылили, костылят и будут костылить.
> Это было актуально, когда компы были медленные. И интернета не было)
Да вот видите ли - в ядре сейчас рефакторов пачка, потому что с сверхскоростными SSD все упирается - в оверхед кода ядра. И если ваш сервак в разы медленнее того что железо могло бы из-за оверхеда в коде ядра - что вы скажете на такой рост костов?! Ну вон там народ и надрывается, а высококонцептуальные микроядра так никому и не надо, столько лет спустя. Потому что платить в разы больше за тот же результат всех почему-то дико душит жаба.
> Ты готов поменять увеличение производительности на 5-10-15% в обмен на потенциальный бекдор?
В ядре это и в разы может оказаться. Вооон там игогошики проверяли с драйвером FAT32 на го. Познали горя по полной програме. Пока занимались всем этим миндфаком - наступил кризис, гугл вообще проект задвинул. Ну что, накорябали концЭптуальный драйвер, джуны?! :)
> Сейчас я не готов на такие жертвы.
Можете юзать микроядра, редокс осы всякие и проч. Только вот что-то с перфомансом там не очень и дрова кодить никто не рвется. Потому что получается жесткий запрыг по граблям взявшимися изниоткуда. И вот уже перепуганые жители линяют из локации где хреначит высокое напряжение и разлетаются осколки.
При программировании на сишке нужно выполнять уйму ручной работы.А уйма ручной работы как раз оставляет меньше времени на думанье.
> А уйма ручной работы как раз оставляет меньше времени на думанье.Проблема не только в думаньи. А во внимательности, которая тоже ресурс.
Большая часть дыр в ядре, если отбросить теории заговора, это просто невнимательность.
Но пока что не изобрели усилитель внимательности для мясных мешков
(вещества не предлагать, такое ощущение что половина ядра под ними написана)
Кто сказал NetBSD?
В какой БЗДе используют Lua? В НетБЗДе? Там он навроде системный комфигуратор?
https://www.opennet.ru/opennews/art.shtml?num=38203
https://man.netbsd.org/intro.3lua
https://github.com/luainkernel/lua-netbsd
В FreeBSD LUA используется в загрузчике, кажется вместо фортрана :)
Вроде бы там был Форт?
уже больше 10 лет как нету
> уже больше 10 лет как нетуКакой у вас там, в будущем, курс битка?
https://github.com/lattera/freebsd/blob/master/sys/boot/fort...
https://man.freebsd.org/cgi/man.cgi?loader(8)
Хм... а я что-то помнил, что переписали загрузчик на Си и форт вообще выкинули из базовой системы. Ок, все по-прежнему значит :)
> Хм... а я что-то помнил, что переписали загрузчик на Си и фортНу, луа для скритухи (те же загрузочные менюшки) с 12 версии по умолчанию, а форт - легаси.
Но пока жрать не просит, выносить не спешат (луддиты, что с них взять, вот лапч^W оголтел^W мировые продвигатели прогресса ради прогресса - выкинули сразу бы после встройки поддержки луа "Мне пофиг, что у тебя там сломалось! УМВР, а это устарело и окаменело!")
> лапчПросто Линукс -- активно развиваемое ядро, а не погрызанный копролит. В таком положении, во-первых, всегда есть из чего выбирать и, во-вторых, банально необходимо выкидывать всё, на что не нашлось сопровождающего для починки перманентного стейбл-апи-нонсенса, в пользу того, что есть кому сопровождать и, возможно, развивать.
Не в этом дело, а в длительной поддержке.
У вас это есть в редхэте за деньги.
> Вроде бы там был Форт?Форт, фортран... некроманская языка - цука сложная, хрен прочухаешь, поразвели, понимаешь, названий!
Оба эти языка классика. ВсеЗнают™ первый из курса истории ЯП, а второй из анекдота:Речи тайна Йоды магистра раскрыта - на Форте программист просто старый оказывается он.
Бредовая хреновина, лучше допилите раст-инфраструктуру в ядре, чтобы модули было писать легко и приятно.
Открою тебе тайну вся инфра для модулей на расте уже доступна легка и приятна. Только никто модули на расте так и не пишет.
> Бредовая хреновина, лучше допилите раст-инфраструктуру в ядре, чтобы модули было писать легко и приятно.Как вообще с таким тяжелым синтаксисом могли пустить в ядро, мне не понятно.
Ты хоть думаешь, что пишешь?Чем тебя смутил expect(); вместо if (a = b()) == -1 {perror(); exit();}?
Чем тебя смутили макросы в виде синтаксического дерева, а не сырой постановки текста, перечисления, поддерживающие любые значения (например, структура с результатом, если перечисление Ok()), структуры с методами? Жёсткий контроль жизни переменных, остутствие безпризорных данных в куче. Можно любой тип данных научить делать map(), collect(), into() всего одним методом! Такого даже питон не умеет.
> Ты хоть думаешь, что пишешь?
> Чем тебя смутил expect(); вместо if (a = b()) == -1 {perror();
> exit();}?Очевидно тем, что в ядре нет exit().
Ок, недостатки ты перечислил, а достоинства у Rust будут?
Если это недостатки, то представь какие у Rust тогда достоинства!
Важна семантика, а не синтаксис.К любому синтаксису привыкаешь через 3 недели активного программирования на любом языке.
И семантика у раст, мягко говоря, не очень
Семантика у Раста - это эксперимент. Когда (через несколько лет) выяснится, что она переусложненная и бесполезная фигня, из неё возьмут лучшие идеи, а остальное выкинут на мороз. И что будут делать те, кто понатащил это неудачный эксперимент во всех октрытые проекты, M$ не волнует, наоборот, чем хуже вам, тем лучше им.
Как с языка снял, только надо заменить Раст на C++. Кресты сейчас и выкидывают отовсюду на мороз, предварительно обкатав и забрав лучшее в rust.
Интересная у вас там параллельная реальность.
>> Бредовая хреновина, лучше допилите раст-инфраструктуру в ядре, чтобы модули было
>> писать легко и приятно.
> Как вообще с таким тяжелым синтаксисом могли пустить в ядро, мне не понятно.А его никто и не пускал - это самопальный сторонний проект если что. Если ты завтра накодишь какую-то хрень как ядерный модуль, скажем, интерпретатор брейнфака - тоже можешь новость запулить. Никого не спрашивая "а можно ли?". Примут ли это в майнлайн и будут ли этим пользоваться - совершенно другой вопрос уже.
Как вы собрались бустрапится?
Эта поделка кресты кое как заменяет, никакой он не "системный", учитывая унылый компелятор.
> Как вы собрались бустрапится?Так же, как и всегда. Напоминаю путь бутстрапинга сишки: hex0 -> hex1 -> hex2 -> cc_x86 -> M2-Planet -> mes -> tinycc -> tinycc -> tinycc -> tinycc -> gcc -> gcc. Первые версии раста написаны не на расте, так что далее дополним цепочку каким-нибудь ocaml -> rust -> rust -> rust.
Он и не будет написан на расте, потому что LLVM слишком большой чтобы растовики его переписали.И вопрос был в том, как вы со своим растом будете бустрапится, особенно на какой то железке где памяти меньше гига, и архитетура которой не поддерживается растом.
> LLVM слишком большой чтобы растовики его переписали.LLVM уже потихоньку заменяют на чисто rust-овый cranelift.
https://github.com/rust-lang/rustc_codegen_cranelift
> $ git clone https://github.com/rust-lang/rustc_codegen_craneliftвсе еще сишные проги юзают, не щитово
Это Open Source - всё, что не делается - всё к лучшему. А, если тебе не нравится - выкинь из своего ядра или используй подходящий дистрибутив.
Rust, писать легко и приятно - оксюморон.
Лучше бы допилили сам раст, прежде чем его везде впихать.
после нажатия "↑ ↑ ↓ ↓ ← → ← → LCTRL LALT" ядро перестаёт обрабатывать нажатия клавишЭто типа с любого места можно ввести?
Геймеры негодуют
Да.
Залипание клавиш по удержанию шифт куда привычнее.
Годнота!
Все ограничения - мелкие и не существенные по сравнению с тем что доступно.
Где применишь такое добро, мне может тоже надо.
Пока ни где, я не пользователь линуха в явном виде.Но это будет серьёзый буст и для линуха и для луа, они оба от этого выиграют.
да, троянцев можно понаписать вагон и маленькую тележку.
(тем более что уже готовы в общем-то)
eBPF можно выкидывать?
Зачем? Наоборот, надо добавлять интерпретаторов и JIT-компиляторов разных.
> сетевого сниффера с возможностью ведения журнала с MAC-адресами
> кейлоггера для ведения лога нажатых клавиш
> блокировщика клавиатурыЗачёт.
И название подходящее.
Название прямо так намекает, что система по ночам будет вести себя как типичный санамбула.
лучше б moonshine
Следующий шаг за Латиноамериканским отделением Фонда свободного ПО - добавление в полностью свободное ядро интерпретатора Guile.
Аминь и пусть ещё MIG портанут.
> Следующий шаг за Латиноамериканским отделением Фонда свободного ПО - добавление в полностью свободное ядро интерпретатора Guile.Разве они умеют что-то добавлять?
Вроде все новости про них были про что-то выпилиное - софт, дрова, прошивки и тд
А тут целый интерпретатор добавлять...
Возникла бизнес-идея, надо дать возможность добавлять модули ядра на 1C. Безопасно, патриотично. И обязать дистрибутивы, которые хотят быть в реестре отечественного ПО иметь соответствующую поддержку и повышать уровень импортозамещенности год от года. Графики там нарисовать на десять лет вперед. И назвать этот язык "Первый С". Куда обратиться, чтобы получить финансирование под это дело.
На счет патриотично - сомнительно.
Ибо тарабарский язык - не родной никому.
А кириллмцей не только русский записывают.
Кириллица, говорите? Интерпретаторы Шпага, Рапира, Робик, КуМир, Дракон в ядро!
Уминая кириллицу, имел в виду обычные человеческие языки, а не абракадабру из сокращений.
Эти то, антикварные недобейсики и нрдопаскали зачем поминать.
Как языки они и на этапе проектирования ценности не представляли. Из задача заcpaть мозг школьника, но что бы он не мог применить полученные "знания".Кстати, в подобных русефецированных языках, например в бейсиках, сокращения были вызваны тем, что они не писались, а переводили "денисы поповы" краденное, и количество знакомест под буквы диктовалось исходным бинарником.
Рубрика "Айтишники шутят"
Глянул мельком -- это же хороший инструмент для быстрого прототипирования. На домашние компы такое лучше не ставить, но разрабам модулей ядра вполне может пригодится
Особенно в датацентрах пригодится ;)
Быстро пишем, медленно работает.
С Растом не прокатило,никто модулей не написал,а на этом может быть и очень даже напишут.
На раст же переписали же пару 100 строчных драйверов. Только, у меня правда ощущение, что это диверсия, чтобы слить конкурентов. Корпорации постоянно заявляют, будто они очень заинтересованы в расте и "используют" его повсюду, а на самом деле весь код на расте очень оперативно выкидывается и заменяется нормальным, т.е. не является сколько-нибудь ключевым.
это один из которых хэдер переписали на растовский а реализация на сях осталась?
она помечена как unsafe, поэтому ее использование стало - безопастным!Хруст пока не очень подходит для такой скучной и неинтересной работы как управление контактиками для светодиодика, понимать надоть!
А в это время параллельные новости, скажем, про Pingora помножают на ноль весь ваш комментарий.
Это твоя пингора в ядре что ли? Что ты тут на ноль помножил?
Фреймворки и наколенные прокси это замечательно, но это не продукты и не ПО.
Да это обычный хайп. Так было с джавой, с go, теперь с растом. Все это суета, всё это пройдет, а Си останется. Смирись и прими это
Java тоже останется в банковском секторе, как замена бессмертного Кобола. Каждому своя ниша.
Вот как мы увидим практическую пользу этой Pingora, так только тогда она перестанет помножать ваш комментарий на ноль.
> Вот как мы увидим практическую пользу этой Pingora,
> так только тогда она перестанет помножать ваш комментарий на ноль.Так она отрабатывает каждый раз когда тебе показывают сообщение от клаудфари.
Это же не тебе лично должна быть практическая польза.
Вот именно, в Cloudflare могут писать хоть на Erlang (кстати неплохая мысль), их внутренняя кухня особо ни с чем не пересекается.
LUA хороший как glue язык, те когда на нём бизнесслогика а тяжёлая работа работается где то в биндингах.
Некоторые и тяжёлую работу пытаются делать в LUA, иногда даже получается юзабельно - prosody джаббер сервер как пример.
Жесть, нафига интерпретатор в ядре? Итак уже интеловскими заплатками производительность херите, так еще и это
Жесть, я в щокэ просто
Да не боись ты так. Это ж сторонний проект на ShitHub (Кто все эти люди?). Это ещё не значит, что им палец не покажут.
REPL в ядре это вин!
> REPL в ядре это вин!Читайте внимательнее "Среди возможностей утилиты командной строки можно отменить .... использование интерактивной оболочки REPL (Read–Eval–Print Loop)".
Почему не собирается у меня он? то builds не создам в папке модуля,то циклическое залипания на сборку модуля. как вообще собрать его?
Уже пробовали в NetBSD, хз чем оно закончилось.
Это не первый подобный проект. Во времена Linux 2.6 были патчи для Lua.
А в NetBSD поддержка Lua-модулей - в основной ветке.
Интересно, насколько кросплатформенный модуль ядра сложно сделать?В NetBSD же есть возможность запустить нужный код ядра в пространстве пользователя. Перспективная штука!
Вот так тихо и незаметно Lua стала вторым после C языком в ядре Linux, сразу же обогнав Rust.