- posted
17 years ago
USB --> RS232
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
Wed Jun 08 2005 02:14, Zahar Kiselev wrote to Kirill Frolov:
KF>> О да! Linux тут реализует русскую рулетку: прежде чем отстрелить KF>> твой процесс он ещё пол-системы завалит. (2.4.x) ZK> По-моему это уже довольно давно поправили. При наличии вменяемых настроек ZK> убивается не в меру прожорливый процесс. Во всяком случае где-то я об ZK> этом исправлении уже читал.
Исправление помогает тоже не во всех случаях. Windows, надо заметить, ведёт себя гораздо более пристойно -- зажравшийся процесс просто не получает памяти. А своп увеличивается автомагически, по мере потребности (тоже самое, что и swapd).
ZK> хватало свободной памяти для удовлетворения запросов Гимпа. А вот как ZK> сказать ядру не раздувать неумеренно дисковый кэш и всегда держать в ZK> резерве кусок памяти побольше - я не нашел. То есть в сети рецепт нашел, ZK> но к 2.4.24 он не подошел.
А казалось бы что проще -- укорачивать кеш. :-/
KF>> А зачем, всё-таки дос? ZK> Очевидно за тем, что он близок в данном случае по назначению к ZK> программам, которые раньше называли "мониторами". Помнишь в "Радио" ZK> статьи с описанием такой штуки для радиолюбительской восьмиразрядной ZK> машины? Совсем без программы-монитора - тоже плохо, и в том же время ZK> толстая развесистая полноценная многозадачная ОС в чем-нибудь типа ZK> бензоколонки не особенно и нужна, ибо требует обслуживания и снижает ZK> общую надежность.
Ну во-первых монитор из доса никакой. Формально, конечно: CP/M == control program / monitor. Но скорей только формально. Если говорить про мониторы, то я думаю использование более специализированного решения будет более предпочтительно.
Требует обслуживания? Обслуживания требует сервер или виндовс. Какое может быть обслуживание для установленной в romfs системы? И потом, это наверное самое важное, всё-таки какой никакой сервис прикладному ПО и мониторы и ОС предоставляют. И грань между мониторами времён "Радио-86РК" и современными встраиваемыми ОС весьма тонкая. А по качеству предоставляемого сервиса современные "микро-ОС" явно выигрывают. Может быть ещё один аспект -- надёжность. Развесистая ОС в этом плане конечно проигрывает. Но опять же, выигрывает отнюдь не ДОС, в котором за глюки в многочисленных dpmi-экстендерах, обёртках к ним (32-бит программа <-> 16 бит дос) вокруг функций доса, самого доса, qemm, himem и прочих драверов НИКТО НЕ ОТВЕЧАЕТ. Нужна файловая система? ДОС опять не на высоте. В том смысле что чего-то вроде сжатой romfs он не поддерживает, а использование устойчивой к сбоям БД без прослоек вроде FAT было бы более предпочтительным, IMHO. Остаётся ещё что? Существование готовых и доступных занахаляву средств разработки. Это, наверное, единственных плюс.
Паскалеподобный? По-моему так и близко не лежал.
ZK> хватает - то пожалуй имеет смысл с ним ознакомиться. Во всяком случае ни ZK> на убогий Бэйсик, ни на довольно заумный и явно "нестрогий" Перл он не ZK> похож.
Перл -- он слишком "practical". В него натащено всего чего только можно. Практически в нём есть всё что нужно, и не нужно. Последнее, может быть, и мешает. Бейсик действительно, будь он хоть Visual, если не убогий то (для меня) слишком сложный. Запутанные синтаксические правила и каша из несовместимых типов при невозможности сделать элементарные вещи. Популярный TCL действительно, без расширений, не позволяет писать сколько-нибудь большие программы. Отсутствие понятия тип вообще плодит глюки, отсутствие структур данных, отсутствие долгожданного dict (наконец введён, вроде как, в 8.5) отсутствие понятия нечисла (NaN)... Может быть в 9.0 будет лучше, но сейчас это действительно не более чем "клей". Причём не идеальный. Может быть концепция "низкоуровневого" программирования на C++ и склеивания частей чем-то вроде TCL не так уж и плоха, действительно. Чиста ООПщина в лице C++, OO-паскаля (delphi, ada?) порождает мегабайты невразумительных исходников позволяет закопать в запутанных соотношениях классов и объектов любой проект. Популяризуемые бородатыми гнушниками диалекты lisp практически никем не пользуются и нарастили вокруг себя необходимую инфраструктуру. Про разрекламированныe python, javascript и java ничего толком сказать не могу. Кроме того, что двух последних в инкарнации для ДОСа наверняка не существует.
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago
- posted
17 years ago