Первое впечатление, что они упоролись. Хотя, может статься, если начать разбираться, то станет понятно, что это действительно для чего-то полезно.

Меня терзают сомнения, что они серьёзно.

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

Выхлоп powertop с вашими питоноподелками

Моих питоноподелок ты не видел, но выхлоп powertop можешь направить прямо сюда.

Марка Балмера (Marc Balmer, разработчик NetBSD)

Да кто же не знает Марка Балмера...

Почему не яваскрипт? Так и представляю себе: вышел драйвер устройства ХХХ, написанный на jQuery.

Более низкий порог вхождения по сравнению с языком C позволит в будущем упростить разработку драйверов

Мне одному кажется что «более низкий порог вхождения» тут как раз вреден ?

Можно подумать, у iolanguage какие-то проблемы с зависимостями. Или у guile.

у guile таки куча зависимостей, сходу помню libgmp и boehm-weiser garbage collector

у луы только стандартная библиотека C

А почему еще никто не предложил Scheme в ядро впилить ? Например Guile ? Настоящий Emacs в ядре это ...

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

Да не трололо, нормальная идея. Подкинь вон разрабам HelenOS идею насчёт ерланга. :}

это который из зоопарка?

да

Lua в ядре NetBSD (комментарий)

boehm-weiser garbage collector

А, точно. У луы же костыли вместо управления памятью. Нормальный gc ей не нужен.

А как оно себя будет вести при ошибках рантайма, интересно?

QNX? ;D

Кстати, если для драйверов не нужно ничего кроме С, тогда почему существует биндинг libusb к python?

для тех кто забыл или не застал тред про зоопарк

Марк Балмер: OpenBSD в зоопарке

Какое облегчение может привнести тот же луа?

Портабельность например. Как и в любых скриптовых языках (перл, похапе, питон) единожды написанный код не требует модификаций при запуске на другой платформе. Напомню что в си/плюсах для этого используют горы костылей из конструкций #ifdef ... #endif

Нетбсд всегда славилась своей портабельностью (а значит грамотно спроектированным кодом, с поддержкой правильного стандарта - не GNU C а например ANSI C). Так что еще один - и весьма немалый - шаг к портабельности защитан.

Да хорош уже жечь-то...

... В ядре есть и связные списки http://isis.poly.edu/kulesh/stuff/src/klist/ , с 2005г. См. /usr/src/linux/include/linux. list.h — не оно?

Из остального «да что угодно». А с чего Вы взяли что на С невозможно применение методологии ООП, в т.ч. наследование? А что, на С нельзя реализовать «паттерн матчинг»? Я правда не вкуриваю на кой пень оно в ядре, но для С есть либо pcre, либо реализация в glibc — http://www.gnu.org/software/libc/manual/html_node/Regular-Expressions.html. С каррингом (в ядре) соизвольте уже пройти в жопу?

/* Ей-Богу достали скрипторылые криворукие неумехи, ни чего не желающие ни знать ни понимать из того, что не покрывается их синдромом утёнка и норовящие всё «заточить» под свой скудный умишко. */

Не, ничего хорошего в этой идее нет. Иначе сделали бы уже давно, оно же на поверхности лежит.

Чем сложнее устройство, тем сложнее к нему драйверы - формирование очередей, колец, деревьев и более сложных структур данных далеко не редкость.

Ну уж по сравнению с луа в ядре... :-D

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

Давно нужен dsl для написания драйверов, хотя бы привязанный к конкретному ядру. В си только один термин предметной области - память, и никаких средств создания абстракций сложнее чем «функция». Конечный автомат, типичный для драйвера, и то пишется вручную. Зато хватает приколов типа if(current->uid = 0).

скриптовых языках (перл, похапе, питон) единожды написанный код не требует модификаций при запуске на другой платформе

Да, вот особенно питон, который несовместим сам с собой даже в разных версиях. А про ад переноса программ на Windows, я даже писать не хочу. Может хватит уже так беззастенчиво врать?

Не, ничего хорошего в этой идее нет. Иначе сделали бы уже давно, оно же на поверхности лежит.

Так и сделали, если ты про микроядра. Винду, QNX, и еще кучу менее известных операционок.

... В ядре есть и связные списки http://isis.poly.edu/kulesh/stuff/src/klist/ , с 2005г. См. /usr/src/linux/include/linux. list.h — не оно?

Что «оно» - абстракция, хреново выражающаяся на Си? Тогда да, это оно.

А что, на С нельзя реализовать «паттерн матчинг»?

Попробуй реализвать и посмеши нас результатами.

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

Читать научись сначала, гений системного программирования.

Так я даже не сомневаюсь в этом, даже вангую смартфоны со стопицотядерными процами и терабайтами оперативы, тормозящие при отрисовке кнопочки на экране. У меня в начале нулевых QuickOffice на Palm'е с 33-мя(!) мегагерцовым процом летал и очень шустро работал с большими таблицами. Зато теперь тот-же, вроде, QuickOffice на планшете с Ондроедом настолько долго и мучительно перерисовывает элементарную табличку, что мне хочется планшет разбить о стену.

На самом деле, меня эта идея давно посещает. Сделать что-то вроде vm-ядро, способное beam файлы запускать, которые и были бы драйверами тех или иных подсистем. Но боюсь, без С и асма всё равно не обойтись. Даже не представляю, как железные регистры устройств из эрланга выставлять о_О. Да и в одиночку я не справлюсь, если быть объективным. Да и в эрланге я не более чем нуб чесслово…

Винду

С каких это пор оно микроядро? Не знал.

QNX, и еще кучу менее известных операционок.

Ну, не на эрланге же )) Хотя концепция таже, я по этому и говорю, что идея на поверхности лежит. Эрланг для message based систем и заточен же.

как железные регистры устройств из эрланга выставлять

дергать си с помощью портов)

В Windows ядро и драйвера в одном адресном пространстве, аналогично в Linux, Solaris, VMS и прочих *BSD. Расскажи, что такое microkernel в твоем понимании?

У Lisp должен быть еще легче.

На самом деле, проблема гораздо больше тем тебе кажется. Правильнее всего рассматривать ядро как библиотеку для доступа к железным ресурсам. И делается это через некий апи. Только апи это у каждого производителя свой. И внутрености этой библиотеки тоже свои соответсвенно. Концепции тоже могут быть разные (монолит/гибрид/микроядро). А ты хочешь сделать, что бы для дров тоже был стабильный апи, независящий от концепции. Это как раз то, от чего тов. Торвадс всех отговаривает, ибо это привязывает намертво ядро к одной концепции/технологии/etc и соответсвенно потере гибкости и багаже устаревших подходов, которые всё усложняют. Я уже не говорю о потере производительности.

BSD
хорошо

Не некрофильствуй.

В Windows ядро и драйвера в одном адресном пространстве, аналогично в Linux, Solaris, VMS и прочих *BSD

...и Mach.

Вот я и говорю, что без С и асма не обойтись. Да и к тому же сразу же всплывает вопрос об эффективности. Знаменитая проблема микроядер, которую очевидно просто не решить.

А вот лисп отлично подходит на роль языка для системного программирования. Пример тому - лисп-машины, где сама ОС была образом лиспа.

Даёшь лиспосрач в теме про NetBSD!

Вот гномеры то и сказали, к чёрту ваш C, будем писать GTK приложения на JS :3

Си там никуда не девается, просто добавляется дополнительное средство для выражения.

Ещё бы, куда он денется то. Переписать то весь стек на JS они уже не осилят.

Так и сделали, если ты про микроядра. Винду

А матчасть кто учить будет?

Никто и не планировал выкидывать Си и писать все на JS. JS - это расширение возможностей платформы Gnome, а не наоборот.

Это к слову, какое говно этот ваш С++, если даже JS лучше.

Винду

С каких это пор оно микроядро? Не знал.

Ну, почти: http://en.wikipedia.org/wiki/Hybrid_kernel

Что это за ересь?

А про ад переноса программ на Windows,

Вы бы еще под ДОС портировали программы. Скоро программисты переймут практику вебдизайнеров брать дополнительные деньги за поддержку семейства ишачьих. Тоже начнут брать деньги за поддержку семейства вендовых.

... Абстракция, хреново выражающаяся на С? А сами-то пробовали? Или по рассказам судить изволите? Дескать, деды заповедовали не выражаться абстракциями на С? :))) Вот по-всякому можно. А от абстракций увольте... Угу... :))) Пойду в классе расскажу... :)))

И что там должно быть не так, о уважаемый Гуру чего-то, что не С? Какие будут проблемы, подводные камни в реализации «паттерн матчинга» на С? Впрочем, Вы же изволили просить посмешить Вас? Ну извольте. Что смешного Вы можете увидеть здесь — http://wiztelsys.com/Article_iptables_bob2.html или, чтобы Вам не искать в каком модуле это реализовано, вот вам проще — http://www.linuxjournal.com/article/7184. Чтобы Вам долго не колупаться, я скажу сразу — это довольно старенький пример расширения для netfilter, строк в 60, в котором дропается любой пакет (как для TCP, так и для UDP), приходящий с определённого IP, заданного, как Вы можете догадаться в виде строки — static unsigned char *ip_address = «\xC0\xA8\x00\x01»;). Причём ещё задаются и static char *interface = «lo»; и unsigned char *port = «\x00\x17»; Чем не такой... лёгкий «паттерн матчинг»? И что здесь смешного в реализации?

Читать умею как могу. Вот было бы что прочесть. Вы бы писали так, чтобы ВАс прочесть и понять можно было однозначно?

The reason NT is not a micro-kernel system is that nearly all of the subsystems providing system services, including the entire Executive, run in kernel mode (in the same address space as the microkernel itself), rather than in user-mode server processes, as would be the case with a microkernel design.

Да и про message based я что-то там ничего не нашёл о_О

... Абстракция, хреново выражающаяся на С? А сами-то пробовали?

Да. Если ты не понял - я пишу (в том числе и) драйверы, и я использую ядерную реализацию списков.

Что смешного Вы можете увидеть здесь — http://wiztelsys.com/Article_iptables_bob2.html

Вы бы писали так, чтобы ВАс прочесть и понять можно было однозначно?

Анонимус не может в контекст, беда.

Ага, с тем же успехом, и макось - «микрокернел».

Логика гномера. Наглядная схема.

1. Группа X пишет десктопософт на C.
2. Группа X приходит к выводу, что писать десктопософт на C довольно-таки геморройно.
3. Группа X решает писать десктопософт на JS.
4. Наблюдающий за действом гномер строчит заметку в свой новостной блог: Группа X предпочла JS плюсам, ё!

Хотя на самом деле группа X предпочла JS их любимой сишечке.