>Говорил и буду говорить, все равно какой дистрибутив использовать для _сервера_ !

Ну, глупости говорили и ещё и грозитесь в том упорствовать.  Может, через пару-тройку лет пообтешется.

Hints:
- управляемость
- обновляемость (как updates, так и при необходимости -- обычно вследствие прекращения поддержки предыдущего выпуска -- между major releases)
- отчуждаемость и делегируемость управления
- надёжность

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

Вы там ошибки обрабатываете?

>Поскольку все програмные пакеты пересобираются из одних и тех же
>исходников.

Ерунда.  За этот "довод" держатся только чайники-слакваристы, какового Вы пока и напоминаете (ничего личного, сам когда-то курочил очень подобным образом четвёртый или пятый редхат; но при переезде на пятый или шестой вот и задумался -- а часто ли вообще тазик загружается и не лучше ли это время потратить более разумным и полезным образом).

Чтобы не быть голословным -- можете посмотреть спеки пакетов apache или xmms, которые в ALT поддерживаю:
http://sisyphus.ru/srpm/apache/spec
http://sisyphus.ru/srpm/xmms/spec

(уже молчу про glibc, rpm или apt)

>Если что то не нравится -- пересобери непонравившийся
>пакет сам, как это было описано в предыдущих статьях:
>http://www.dzti.edu.lv/isp-serv/index.php

Это осмысленно в двух случаях:
- сильно локальные изменения (это дорасти ещё надо);
- понимание, как улучшить пакет в используемом дистрибутиве, чтобы и свои изменения были "из коробки", и по возможности другим жизнь не испортить.  Для этого надо дорасти ещё довольно заметно.

> главное в статье то, чтобы _начинающий_ администратор
> имел ясное представление о загрузке системы

Если исходить при этом из важности времени загрузки или "в пять строк" -- ничего хорошего из такого "представления" не выйдет.  См. выше.

> по опыту проведения лабороторных занятий по Linux
"Кто не умеет -- учит"? ;-) (я-то и учить не умею, приходится учить, как учить -- в смысле методички квазаровские местами писал ;-)

> даже простая конструкция типа
> [ -x /usr/sbin/named ] || exit 1
Так разбирать скрипты надо начиная с Керниган-Пайка "UNIX: универсальная среда программирования" или там Bash conspect (гуглится).  Это раз.  Два -- нормальному (не претендующему) администратору вообще сиренево, что там в скриптах, постольку, поскольку их поведение соответствует документации.

Кусок разбора RH-like /etc/sysconfig/network-scripts/, который Вы привели, достаточно понятен (единственно что спросонья не соображу, что именно приходит на | sort, ну и LANG=C можно было в subshell воткнуть в одном экземпляре или просто выставить в начале скрипта и восстановить в конце/трапилке (явно напоролись на грабли с UTF-8 или порядком сортировки и фиксили на скорую руку)).

> у меня нет страха показатся некомпентным

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

> В заглавие статьи есть слово СЕРВЕР, ну какие могут быть сложности
> с обновлением для сервера,
Любые.

> В принципе, кто нибудь читал статью
Продиагоналил => "о, знакомо".

> PS В принципе, те у кого мало времени используют MS-Windows :)

"...и эту глупость я говорю и буду говорить!" (c)

PS: вот, почитайте лучше статью, написанную Вашим коллегой (на время написания) -- о том, как надо заниматься промышленными системами: http://www.linux.kiev.ua/ru/docs/articles/ideal-sysadm-rpm/

PPS: он же -- автор /etc/net (http://etcnet.org, http://wiki.sisyphus.ru/admin/etcnet/).  Думаю, многие здесь могут посмотреть на свои нетривиальные скрипты с активным использованием iproute2, посмотреть туда -- и оценить квалифицированную работу по обобщению.