Со всем уважением к тяжелому каторжному труду разработчиков - для настоящего серверного ОТКАЗОУСТОЙЧИВОГО применения нужно:

1) Избавиться от тяжелых детских болезней ядра за авторством IBM (ненадёжная до конца поддержка RAID, ACPI, AHCI, SMP c истинным параллелизмом)

2) Сделанных на "как нибудь, но чтобы все же работало" драйверов КРИТИЧНОГО ДЛЯ ВЫБРАННОЙ ЗАДАЧИ ОБОРУДОВАНИЯ

3) НАДЕЖНОГО, РАБОТАЮЩЕГО В ЗАЩИЩЁННОЙ ОБЛАСТИ ПАМЯТИ СЕРВЕРНОГО ПО, отлаженного хотя бы до уровня серверного ПО в составе Novell Netware 6.X, причем стоит настоятельно ИЗБАВИТЬСЯ ОТ СЕРЕВЕРНОГО ПО, РАБОТАЮЩЕГО В РАСШИРЕННОМ РЕЖИМЕ МОДЕЛИ СЕРВЕР КАК ФОНОВЫЙ ПРОЦЕСС С ПОВЫШЕННЫМ ПРИОРИТЕТОМ (например, так к стыду и позору работает AMP/2, например, КОМПЛЕКС *ПОРТИРОВАННЫЙ ИЗ UNIX "В ЛОБ" БЕЗ УЧЕТА ВНУТРЕННИХ ОСОБЕННОСТЕЙ РАБОТЫ САМОЙ OS/2 | EComStation

4) Прикладного, полу-пользовательского, но все-же нужного ПО для P2P (DC++, BitTorrent - серверы/клиенты)

5) В дополнение ко всему, ну что, так невозможно пренести модель запуска сервисов/демонов из WinNT/*NIX, мы что слабее/криворукистее пользователей Windows/*NIX

6) Ввести систему поощрения/награждения разработчиков всеми доступными силами для достижения задачи, например - лицензия и бонусы/скидки на EComStation для авторизованных и заслуженных разработчиков серверного и низкоуровневого ПО (тут есть прогресс, но на уровне дрессированных черепах)

7) Ввести систему поощрений/бонусов за труд сообщества по отладке/внедрению/доработке(развитию !) Всего вышесказанного.

8) Profit ! ))

=====

1) Избавиться от тяжелых детских болезней ядра за авторством IBM (ненадёжная до конца поддержка RAID, ACPI, AHCI, SMP c истинным параллелизмом)

=====

Это в основном дрова, а не ядро. Кстати, а какие претензии к SMP?

=====

5) В дополнение ко всему, ну что, так невозможно пренести модель запуска сервисов/демонов из WinNT/*NIX, мы что слабее/криворукистее пользователей Windows/*NIX

=====

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

2 Slavik Gnatenko Конечно в никсах есть модели запуска сервисов. Как минимум это модели UNIX System V и BSD Всякие новомодные типа systemd я не рассматриваю, хотя они и набирают популярность.

Oxyd, дык, а я об чём? МоделИ есть. А единой нет по этой же самой причине. Точно так же можно сказать, что и в оси модели есть. Можно ещё десяток перенести из других систем, но неужели это такой важный показатель серверности?

С демоном демонов удобнее.

Вот тебе банальный пример: закрытие систем.

Как у нас это происходит сейчас: если нет XWP, то просто жмём Desktop->Shut down: система сохраняет инишки, синхронизирует файловые системы и просто останавливается -- с запущенными приложениями (серверными!) на ходу.

Если же есть XWP, то можно воспользоваться XWorkplace Extended Shutdown -- он будет по очереди закрывать каждое найденное окно. Но поскольку VIO-сессии он не закрывает, а каждый раз открвыает окно "что делать", то это выливается в геморрой прописать тайтлы ВСЕ VIO-окна, которые ОБЫЧНО запущенны (то есть, демоны), и следить, чтобы у них было именно прописанное название. Ну, ещё надо отключить предупреждение при закрытии VIO-сессии, но оно, надеюсь, у всех отключено.

Тогда действительно, процессу прилетает сигнал (уж не знаю, какой), и оно нормально завершается. Завершаться может по двадцать секунд -- XShutdown терпеливо ждёт -- это хорошо, но, во-первых, если процесс повиснет, вместо того, чтобы завершиться, то повиснет и шатдаун: нужна будет пользовательская реакция (нажать Skip) -- это весьма хреново. А во-вторых, XShutdown не начинает закрывать следующее окно, пока не закроется это, что глупая потеря времени.

Если же будет система запуска демонов: XShutdown говорит servicename stop для каждого servicename, а дальше идёт завершать пользовательские приложения как обычно. Плюсы очевидны, и один из них (который из моего поста неочевиден) -- сервисы начинают завершаться не по сигналу (а значит экстренно, как можно быстрее), а... э-э-э... gracefully, вот.

Это не говоря уже об общих плюсах, не про шатдаун. ЗЫ, если кто знает менее геморное решение -- поделитесь?

По поводу "каждый что хочет, то и делает": у нас демонов для полуоси-то раз-два и обчёлся -- не составит труда хоть все скрипты написать по-новой. Нам нужна мелкая, кустарная разработка, возможно с совместимостью с какими-нибудь, там init-скриптами. И с хорошим, осёвым гуЁм с интеграцией с WPS, REXX-интерфейсом и Java-апплетом! Как положено!

Вод! :D

Я думаю, что проблема больше надумана. У меня ось вполне себе сервер. ftp/http/smb/dns и ещё кой чего по мелочи. И даже без XWP. Никаких проблем с приложениями при шатдауне. Кому сильно надо, может себе батничек shutdown.cmd (типа обратный startup.cmd) для стопа своих демонов написать и откуда-то запускать.

Что нибудь типа:

=== service.cmd ====

@%_BOOT%:\SERVICES\%1 %2$

====================

а уж тем более гуй к этому - это совсем не принципиальные рюшечки. Более важно, кто будет эти самые %_BOOT%:\SERVICES\*.cmd писать.

Вендовая реализация, кстати, весьма примитивна. Вот у меня на работе используется самописная система поддержки сервисов в актуальном состоянии. Помимо кучи всего прочего, она периодически шлёт на сервисы запросы (есессно, на каждый сервис это надо делать своим образом) и, если не получен ответ, сервис считается залипшим и перезапускается. Венда так не умеет :)

Ну, всё тем и заканчивается, что каждый пишет свой велосипед.

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