1) хорошо
2) название не соотвествует содержимому — убого
3) цифры, графики. что за сервер, почему именно «производительный» — засчет того что сервер толстый или магия над линуксом/шейпером? — ничего нет, значит убого
4) это к вопросу об анализе. но можно.
5) а htb хуже чем cbq, то есть вы предложили заведомо худшее решение, не исслодовав вопроса и только потому, что htb проще настраивать. убого
6) где постановка задачи? убого
7) будем, так как вы сами пишете, что шейпер обслуживает абонентов. шейпинг со стороны оператора — зло, как для абонентов, так и для самого оператора. попытка ухода от вопроса — убого.
итого: чем ваша статья отличается от маленького кусочка Linux Advanced Routing and Traffic Control how-to? налчием мега-скриптика от румынского(!) админа?
вернемся к статье:
статья-то о чем? о конкретном маленьком скриптике, который генерит конфиг для htb? а почему названа «Linux под нагрзукой. Высокопроизводительный шейпер»? где тут нагрузка, высокая производительность, да и вообще какой-либо анализ? почему linux, а не juniper/cisco/netapp? почему htb, а не cbq? почему вообще-говоря шейпинг, а не полисинг? я вот точно могу сказать, что шейпинг со стороны оператора — полнейшее зло.
спрашиваю последний раз — вы дурак? я, именно я, написал, что «интерфейс для шейпера на php — это нормально». скрипт на php или страничка на php — всё это ИНТЕРФЕЙС. теперь ясно?
товарищ, а вы читаете что я пишу внимательно? сделаю упрощенку:
— смех-смехом, а позволить себе держать пхп на шейпере/роутере могут только недалекие линуксоеды
— нарисовать интерфейс для шейпера на php — это нормально
ну не скажите. нарисовать интерфейс для шейпера на php — это нормально, особой нагрузки не дает, то что раз в неделю кто-то попользуется этой страничкой, а таки удобнее чем каждый раз лазать в консоль.
но это не отменяет общей убогости самой статьи :) про htb все и так знают, плюсы/косяки его известны, а свою обвязку для него не писал разве что ленивый :)
2) название не соотвествует содержимому — убого
3) цифры, графики. что за сервер, почему именно «производительный» — засчет того что сервер толстый или магия над линуксом/шейпером? — ничего нет, значит убого
4) это к вопросу об анализе. но можно.
5) а htb хуже чем cbq, то есть вы предложили заведомо худшее решение, не исслодовав вопроса и только потому, что htb проще настраивать. убого
6) где постановка задачи? убого
7) будем, так как вы сами пишете, что шейпер обслуживает абонентов. шейпинг со стороны оператора — зло, как для абонентов, так и для самого оператора. попытка ухода от вопроса — убого.
итого: чем ваша статья отличается от маленького кусочка Linux Advanced Routing and Traffic Control how-to? налчием мега-скриптика от румынского(!) админа?
статья-то о чем? о конкретном маленьком скриптике, который генерит конфиг для htb? а почему названа «Linux под нагрзукой. Высокопроизводительный шейпер»? где тут нагрузка, высокая производительность, да и вообще какой-либо анализ? почему linux, а не juniper/cisco/netapp? почему htb, а не cbq? почему вообще-говоря шейпинг, а не полисинг? я вот точно могу сказать, что шейпинг со стороны оператора — полнейшее зло.
— смех-смехом, а позволить себе держать пхп на шейпере/роутере могут только недалекие линуксоеды
— нарисовать интерфейс для шейпера на php — это нормально
речь шла о наличии php на шейпере/роутере.
но это не отменяет общей убогости самой статьи :) про htb все и так знают, плюсы/косяки его известны, а свою обвязку для него не писал разве что ленивый :)