А нефик тогда писать, что питон - мультиплаформенный язык. перл - еще может быть, с большой натяжкой, но не питон.

Эммм...

... Сперва, на первой странице, я подумал что внезапно наступило 01.04. Но теперь я точно понял — пятница! :))) Спасибо. Настроение подняли. :)

я точно понял — пятница!

Welcome to the real world, Neo.

Основные примитивы, существующие во всех ядрах (пусть даже во всех *nix) вполне можно внести на уровень языка. Скажем, порты, прерывания. А выше - пусть каждое ядро создаёт своё расширение базового языка. Они и так по факту это делают на уровне API.

Да даже взять более мощный язык - и то шаг вперёд. От сколького уберёг бы один RAII.

Вполне даже мультиплатформенный. Виндовс ведь не считают платформой, равно как и ДОС.

Тем более если дотнет называли кроссплатформенным ПО (несмотря на то что он виндовс-онли), то питону таковым называться сам бог велел.

http://s45.radikal.ru/i107/1206/76/2caf92b9039d.jpg

Lua в ядре NetBSD

Ждём Python в ядре Linux.

s/части системы//

Такие дела.

Нет, только перл!

Учитывая, что это правда, у тебя некислый такой йогурт :}

Ты бы ещё PHP предложил.

Мы пойдём другим путём. Напишем ЯП на XML и используем его в ядре.

Ну, тогда прошу прощения...

... за «наезд» с моей стороны. Чего-то совсем заработался до почти полной потери юмора. Да и новость такая что хоть стой, хоть падай. :)))

Не за что. Ничего из сказанного мной в этом топике не сказано под влиянием пятницы.

Путаешь теплое с длинным. .NET - это не язык программирования, в отличие от питона, который портирован на Windows, но использовать его там нормально нельзя. Интересно почему?

А выше - пусть каждое ядро создаёт своё расширение базового языка

Получится С, только в профиль.

А как ты отразишь указатели на структуры ядра, которые описаны в .h файлах, примитивы синхронизации и много еще чего на самом низком уровне, в котором можно использовать только С. Начнем с указателей, без которых программировать драйвер вообще невозможно?

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

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

Потому что у линукса пока ~1%. А широкой аудитории юзверей опенсорсным разработчикам тоже хочется, вот и хавают кактус, собирают все зависимости руками :)

Касательно Lua: язык довольно простой, быстрый, очень маленький и довольно легко встраиваемый. При небольшом размере имеет и свои regexp-ы, правда не совместимые со стандартными, но с довольно неплохой функциональностью. Если сравнивать по размерам исходников в несколько, а то и в десяток раз, меньше того-же guile.

Касательно списков в FreeBSD есть довольно удобная реализация списков и очередей для C на макросах живущая в /usr/include/sys/queue.h (в NetBSD есть немного отличающийся вариант) - как мне показалось гораздо более удобная, чем та, которая находится в ядре Linux.

Хотя, конечно, в общем - зачем Lua в ядре я так и не понял.

Я не о линуксе говорю а о любых POSIX-capable системах. БСД, линукс, соляра и прочие. 99% серваков, все не-х86 девайсы (планшеты, нетбуки, телефоны - либо ведроид, либо иос), предположим даже один процент десктопов. Плюс маки (там OS X). И доля венды в таком разнообразии устройств и осей - капля в море, у кого еще один процент получается ;).

Это круто!

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

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

Ага, динамическое выделение памяти в самый неподходящий момент....

Касательно списков в FreeBSD есть довольно удобная реализация списков и очередей для C на макросах живущая в /usr/include/sys/queue.h - как мне показалось гораздо более удобная, чем та, которая находится в ядре Linux.

А что, между ними есть заметные отличия?

Странно, в рассылке я этого не видел (возможно просто плохо просматривал). Интересно, а как они решили особенности писания драйверов под нетку для луа?

чтобы было?

вон в юзерспейсе оно уже давно, а ничего толком на lua-то и не сделали.

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

пойди погугли, что такое паттерн матчинг

От сколького уберёг бы один RAII.

В gcc есть костыль, который реализует некоторое подобие. Вполне удобно, кстати

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

Ага, динамическое выделение памяти в самый неподходящий момент....

Что заставляет тебя думать, будто высокоуровневые языки обязательно выделяют память в неподходящий момент?

В gcc есть костыль, который реализует некоторое подобие.

ссылку?

А теперь time prog.lua и time a.out встудио

Что заставляет тебя думать, будто высокоуровневые языки обязательно выделяют память в неподходящий момент?

райнтайм будет жрать заранее сотню метров? )

атрибут clean который

райнтайм будет жрать заранее сотню метров? )

А на эту мысль тебя что навело?

Ой, а можно на Ваше объяснение полюбоваться...

... а я пока в танчики поиграю? Я уроки сделал... Честное пионерское... :)))

Звучит комично. Хотел человек драйвер написать, смотрит, а там надо на С программировать. Да ну его к черту, подумалось ему, пойду дальше на html верстать.

Как мне показалось - в FreeBSD просто более удобно выстроено и оформлено. Плюс ко всему содержит так-же реализацию очередей. Вся работа идёт через макросы.

Давай пойдем другим путем. Ты знаешь, что паттерн матчинг и регулярные выражения - это не то что не одно и то же, даже рядом не валялось?

Ну давайте...

... Допустим, знаю. А не подскажете на кой пень Вам всенепременно и именно в ядре нужен паттерн-матчинг? Ну, пример задачи приведите? Более-менее реалистичной.

Эх, если бы я знал, когда покупал билет... Вот пингвины там в экспозиции у входа прикольные. Я минут 20 точно наблюдал как они в бесконечном цикле выстраиваются в стек, а потом первый прыгает в воду, проплывает на другую сторону платформы, и добавляется в конец очереди. Так и не понял, это их так тренируют, или они по собственному желанию... Может Linux виноват?

Kernel mode crysis

А смысл скртптовый язык в ядре размещать? Для настройки Lua вполне подходит. А вот драйвера писать или системные модули на ней не получится. В общем, получается что скрипты на Lua будут вместо конфигов?

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

Почему бы тогда не использовать Pawn, если есть привязанность к Си и необходимости в скриптовом языке?

Да хотя бы для быстрого прототипирования того, что потом будет переписано на Си.

А на эту мысль тебя что навело?

А какие есть альтернативы борьбы с писателями произвольного кода на яву без явного kmalloc, кроме как «выделить заранее» и «жрать в неподходящий момент»?

Я боюсь дожить до момента, когда появятся модули ядра и/или драйвера на питоне или яваскрипте.

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

Ух, вот это вещества были в те времена! Не то, что теперь...

Комментарий мой следующий, друг зелёный, прочти ты.