Lua в ядре, хмм, они здоровы?

[xserver]

Наткнулся тут на интересную инфу.
http://www.phoronix.com/scan.php?page=news...&px=MTMwMTU
В NetBSD хотят Lua в ядро впихнуть. Интересно какой потребуется на все это счастье процессор? В прочем название "Lunatik" project говорит само за себя (lunatic - душевнобольной, помешанный, сумасшедший).

[Bluetooth]

Интересно какой потребуется на все это счастье процессор?

Это смотря что этим языком будет делаться.
Вообще, идея скриптового языка в ядре мне, как человеку, далекому от разработки ядра, кажется странным, и аргументы, приведенные в статье, кажутся весьма спорными.
Впрочем, не случайно выбран LUA, а не питон или руби какой-нибудь - не будет хотя бы сумасшедшего потребления памяти.

Полезности для юзеров декларируются такие:
1) разобраться в скриптах проще, чем в сишном коде
2) легче модифицировать
3) легче изучать
Однако, мне не кажется, что если юзер решил что-то изучить и изменить в подсистеме ядра, то сишный код будет ему помехой.
Да и вообще не кажется, что пользователям (не разработчикам) это реально надо.

Ну а полезности для девелоперов сводятся к:
1) быстрая разработка
2) смена поведения ядра прямо в рилтайме
3) конфигурирование ядерных подсистем через скрипты

Что, конечно, уже интереснее и дает определенные плюсы на практике. Тем более, что в случае NetBSD не стоит бояться миллионов строк говнокода от людей, обладающих слабым набором знаний - таких людей среди разработчиков ядра NetBSD попросту не найдется.

Ну а что касается производительности, я думаю, с этим проблем не будет вообще - критичные к производительности места все равно на си будут.

[Bizdelnick]

не стоит бояться миллионов строк говнокода от людей, обладающих слабым набором знаний - таких людей среди разработчиков ядра NetBSD попросту не найдется.

Это сейчас...

[drBatty]

Наткнулся тут на интересную инфу.
http://www.phoronix.com/scan.php?page=news...&px=MTMwMTU
В NetBSD хотят Lua в ядро впихнуть. Интересно какой потребуется на все это счастье процессор? В прочем название "Lunatik" project говорит само за себя (lunatic - душевнобольной, помешанный, сумасшедший).

можно пруфлинк на то, что скрипты заведомо медленнее любого сишного кода?

[Bluetooth]

не стоит бояться миллионов строк говнокода от людей, обладающих слабым набором знаний - таких людей среди разработчиков ядра NetBSD попросту не найдется.

Это сейчас...

Думаешь, завтра все поменяется? Я что-то не думаю

[Aliech]

А я думаю, что фраза "Время покажет" актуальна как никогда. А то постановка вопроса "Куда-то что-то засунут, они что, очумели?" очень похожа на ЛОР. И прям приглашает аналитегов, которые должны предсказать смерть Windows/KDE/GNOME/ещё-чего-нибудь.

[xserver]

можно пруфлинк на то, что скрипты заведомо медленнее любого сишного кода?

Нет, сишный код где-то когда-то теоретически может быть медленнее скриптов, но значит ли это что большинство задач большую часть времени будут работать на равных или даже быстрее на скриптах? Вот в чем вопрос.

Смерть NetBSD в ближайшее время не планируется, но все равно идея странная.
Си не сложней LUA, для начала.
Потом, зачем пользователю лезть в кернелспейс?
Быстрая разработка? В ядре? Надежность/стабильность и скорость разработки всегда противоречили друг другу. Исключения бывают, но по дефолту: либо то, либо другое.

[Bizdelnick]

Думаешь, завтра все поменяется? Я что-то не думаю

Такие вещи вполне себе неплохо стимулируют активность быдлокодеров. Хотя, действительно, поживём - увидим.

[SLEDopit]

1) разобраться в скриптах проще, чем в сишном коде

если ты не знаешь ни то, ни другое, имхо, разницы нет.
а если знаешь хоть что-нибудь, то разница будет не такой уж и большой.
всё же читать и писать код - совершенно разные вещи.

2) смена поведения ядра прямо в рилтайме

для этого ж модули придумали, не?

[drBatty]

Нет, сишный код где-то когда-то теоретически может быть медленнее скриптов, но значит ли это что большинство задач большую часть времени будут работать на равных или даже быстрее на скриптах? Вот в чем вопрос.

зависит от задачи. Если скрипт - интерфейс к каким-то функциям ядра, то очевидно, что скриптовые обёртки будут работать примерно также, как и нативные вызовы. Особенно сетевые. Вот если-бы вы реализовали какой-нить внутренний обмен с ethernet картой - это конечно было-бы медленнее. Однако, об этом речи нет. Потому - не вижу ничего особенно страшного - просто одно из решений, у которого есть свои плюсы и минусы (из минусов наверное самый значимый - неприспособленность lua для сетевых обёрток. В первою ИМХО потому, что сетевые функции изначально точились для вызова из C кода). Плюсы - очевидны.

[Bluetooth]

Думаешь, завтра все поменяется? Я что-то не думаю

Такие вещи вполне себе неплохо стимулируют активность быдлокодеров. Хотя, действительно, поживём - увидим.

Согласен, однако представить интерес быдлокодеров к NetBSD лично мне довольно трудно. Что бы там внутри ни было.

если ты не знаешь ни то, ни другое, имхо, разницы нет.

Нет, разница есть. В вкриптах проще разобраться и знаний для этого нужно меньше.

для этого ж модули придумали, не?

Ну, теоретически, ты можешь пересобрать модуль, выгрузить старый, загрузить новый. Но это явно сложнее, чем в случае скриптов. О чем, собсно, и говорится.

Си не сложней LUA, для начала.

Это как язык. А реальный код на си сложнее будет.

Потом, зачем пользователю лезть в кернелспейс?

Вот и мне непонятно...

Быстрая разработка? В ядре? Надежность/стабильность и скорость разработки всегда противоречили друг другу. Исключения бывают, но по дефолту: либо то, либо другое.

Ну да. Но когда-то нужна и скорость разработки, а не стабильность. Даже в ядре.

зависит от задачи. Если скрипт - интерфейс к каким-то функциям ядра, то очевидно, что скриптовые обёртки будут работать примерно также, как и нативные вызовы. Особенно сетевые. Вот если-бы вы реализовали какой-нить внутренний обмен с ethernet картой - это конечно было-бы медленнее. Однако, об этом речи нет. Потому - не вижу ничего особенно страшного - просто одно из решений, у которого есть свои плюсы и минусы (из минусов наверное самый значимый - неприспособленность lua для сетевых обёрток. В первою ИМХО потому, что сетевые функции изначально точились для вызова из C кода). Плюсы - очевидны.

Все верно говоришь

[xserver]

Это как язык. А реальный код на си сложнее будет.

Это если скрипт на 2 строчки, а в большом коде думаю разницы не будет. И да, Си ведь тоже можно для скриптов использовать:

Код: Выделить всё

#! /usr/bin/tcc -run
#include <tcclib.h>

int main()
{
    printf("Hello World\n");
    return 0;
}

[Bluetooth]

Это как язык. А реальный код на си сложнее будет.

Это если скрипт на 2 строчки, а в большом коде думаю разницы не будет.

И аргументируете это, приведя "скрипт на 2 строчки"?

[Женя Подсыпальников]

Коли желаема логика погрузки/развёртки/функционала ядра,
не требующая его перестройки и отличная от ключей погрузчика,
то, наверное, нужен интерпретатор внешних скриптов, аля "Is_IPV6_wanted.lua" или "Is_IPV6_wanted.bash"...

Вот почему, наверное,
я был более при сравнении удобства lua- и shell- скриптов,
а не при сравнении удобства машинного кода для процессора и текстового кода для интерпретатора...

[SLEDopit]

В вкриптах проще разобраться и знаний для этого нужно меньше.

Ну-ну. Покажите форк бомбу на bash'e кому-нибудь, не шибко хорошо знающему оный. Посмотрим, как там знаний меньше нужно.

[Bluetooth]

В вкриптах проще разобраться и знаний для этого нужно меньше.

Ну-ну. Покажите форк бомбу на bash'e кому-нибудь, не шибко хорошо знающему оный. Посмотрим, как там знаний меньше нужно.

Вспомни еще "скриптик на перл". _Как правило_, в коде на скриптовых языках разобраться проще, чем в сишном. Просто многие вещи на скриптовых языках пишутся проще и короче, и, соотвественно, выглядят проще и понимаются легче.

[Aliech]

А теперь представьте себя разработчиком, которому вот именно в данный момент срочно нужно отдебажить и проконтролировать работу какого-нибудь ядерного модуля. И желательно с реакцией на возможные события. Да...

И что же проще, написать блекджек на C под конкретную задачу, или же воспользоваться специализированным скриптовым языком?

[SLEDopit]

Вспомни еще "скриптик на перл".

Да перл, это отдельная тема. Там и так можно такого понаписать, что сам через полгода даже с поллитрой не разберёшься. (:

[NickLion]

Да перл, это отдельная тема. Там и так можно такого понаписать, что сам через полгода даже с поллитрой не разберёшься. (:

Всякое бывает, особенно в регулярках, но опять же, зависит от того как писать. Можно и на C такое написать.

[drBatty]

Ну-ну. Покажите форк бомбу на bash'e кому-нибудь, не шибко хорошо знающему оный. Посмотрим, как там знаний меньше нужно.

ну-ну
цитата с бездны башорга:

drBatty> почему нет? C это очень простой язык.

anonymous> Ага. Чтобы написать на нём hello world нужно всего 2 строчки:
main(t,O){int _=main,m;return(m=strdup(",!((+hd3+6( eN")),O==_?((int(*)())O)(_,t+1),
17*4:t==_?(*(char*)O?*(char*)O^=((int(*)())t)(O,t):17),O:printf(((int(*)())_)(_,m));}

i-rinat> Да там память течёт! Вот исправленный вариант (убрал утечки и починил код выхода):
main(t,O){int _=main,m;return(O),O==_?((int(*)())O)(_,t+1),17*4:t==_?(*(char*)O?*(char*)O^=
((int(*)())t)(O,t):17),O:(printf(((int(*)())_)(_,m=strdup(",!((+hd3+6( eN"))),free(m),t-1);}

[ifibluenergy]

Не знаю, но все таки стоит им попробовать впихнуть. Да и идея оригинальная (по мне так в системных отделах ОСи еще Lua не использовали).

[SLEDopit]

Да и идея оригинальная (по мне так в системных отделах ОСи еще Lua не использовали).

Так давайте туда ещё и javascript ( лучше вместе с jquery ) и ещё парочку скриптовых языков. Это ж так оригинально.

[ifibluenergy]

Так давайте туда ещё и javascript ( лучше вместе с jquery ) и ещё парочку скриптовых языков. Это ж так оригинально.

Ну а что вы имеете против оригинальности?

[NickLion]

Ну а что вы имеете против оригинальности?

Здравый рассудок. Не всегда оригинальность ему соответствует.

[drBatty]

Так давайте туда ещё и javascript ( лучше вместе с jquery ) и ещё парочку скриптовых языков. Это ж так оригинально.

вообще-то тут дело не в оригинальности, а в функциональности. Функционал у JS заточен для веба, и он не годится. А вот в Lua я не вижу ничего плохого. Может у вас какие-то предрассудки? Фобии? Не?

[SLEDopit]

вообще-то тут дело не в оригинальности, а в функциональности.

ifibluenergy позиционировал оргинальность, как серьёзный аргумент в пользу добавления lua в ведро. так что дело в ней.

[DaemonTux]

Нужно быть оригинальным до конца и заменить lua ну например на Whitespace.

[drBatty]

ifibluenergy позиционировал оргинальность, как серьёзный аргумент

а... ну тогда сами разбирайтесь.