Joshua Tree

[vak]

Вернулись из поездки в Joshua Tree Park.  За три дня накатали 1140 миль: 500+500 туда-обратно, и сто сорок миль собственно по парку.



Ночевали в гостинице Best Western в городке Twentynine Palms. Это на самой границе парка, недалеко от северного въезда, очень удобно. Дорога в один конец на автомобиле занимает восемь часов. В целом не особо трудно, если предварительно хорошо выспаться.

Comments

[vak]

По делам конторы, но не этой (MIPS), а предыдущей (Элвис). Для многих применений хочется иметь встроенную ОС а-ля Юникс. Линукс не лезет просто по объемам памяти. Надо уложиться в 2-8 Мбайт ОЗУ, вместе с юзерским приложением. Даже uClinux с трудом помещается, а уж реальное ядро вообще никак. 4BSD могла бы работать на такой памяти, но ни один из известных потомков не годится.

[oboguev.livejournal.com]

В старые добрые времена на машине с 4 МБ памяти сидели 20+ пользователей, которые редактировали-компилировали-отлаживали счетные программы, плюс в background-е крутилось 4-6 пакетных заданий.

[vak]

Именно. Из 4BSD может получиться хорошая embedded-система. Например для космоса или для робототехники. Но для этого придется вернуться к 4.4BSD-Lite Release2 и начать новую ветку.

[oboguev.livejournal.com]

Я в своём комментарии имел в виду не 4BSD ;-)

[vak]

Я догадываюсь. :)
Просто с практической точки зрения не вижу других codebase, с которых можно было бы стартовать реальный проект.

[oboguev.livejournal.com]

Я разумеется не пытался делать какие-то метрики, но у меня сложилось впечатление, что значительная, если не бОльшая часть добавленной сложности в нынешней FreeBSD (сравнительно с 4.x) связяна с обеспечением scalability для SMP. Соответственно если отправиться от 4.4LR2 и пытаться добавлять scalable SMP, то получится примерно то же увеличение сложности и размеров. Его можно избежать, если жить в простой схеме с giant lock и со spinlock-ом для каждого spl-уровня, и для случая небольшого количества ядер это может наверное даже удовлетворительно работать (ну, жили же раньше с такой схемой), просто нужно с самого начала закладывать в спецификацию, что scalability на большое количество ядер или на высокий процент kernel-mode обработки априори целью не ставится.

Ты не пытался посмотреть footprint у старых версий BSD или старых (тоже с giant lock) версий Linux-а, до начала попыток вводить индивидуальные замки?
С уконфигурированием, естественно, по минимуму.

[vak]

Для мелких микроконтроллеров SMP вообще не нужно.

[oboguev.livejournal.com]

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

[oboguev.livejournal.com]

P.S. http://www.minix3.org

[vak]

Про Minix я в курсе. В теории все красиво. Но не может система, построенная на передаче сообщений, быть эффективной. QNX был весь такой красивый, но не смог решить эту проблему.

[oboguev.livejournal.com]

Ты же не сказал, что тебе еще и эффективная нужна.
Я думал, может для управления холодильником.

[vak]

Неэффективную можно и на джаве написать.

[oboguev.livejournal.com]

Для Unix-подобности каноничнее будет на JavaScript-е.

[oboguev.livejournal.com]

> QNX был весь такой красивый, но не смог решить эту проблему.

А в чем это проявляется? Разве есть куча людей жалующихся на производительность QNX и/или отказывающихся от использования QNX по причине недостаточной производительности?